growthxai/output: A TypeScript Workflow Framework With Temporal and Claude Code in Mind
The open-source TypeScript framework for building AI workflows and agents. Designed for Claude Code describe what you want, Claude builds it, with all the best practices already in place.
At a glance
- What is it?
- Output bundles prompts, evals, tracing, cost tracking and credential storage into one Apache-2.0 TypeScript codebase, and puts Temporal underneath for durability. The design bet is that an AI coding agent, not a human, is the primary author of your workflows.
- Who is it for?
- Adopt Output if your team already writes TypeScript, you want prompts and evaluators versioned next to the code that calls them, and you accept running a Temporal server as part of your development environment. Do not adopt it if you need a Python path, if you cannot run Docker locally or in CI, or if your orchestration already lives in a managed platform you are not willing to move.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The fragmentation problem Output is aimed at
The README opens with a specific complaint: prompts live in one tool, traces in another, evals in a third, and cost tracking is spread across several dashboards that do not talk to each other. Whether or not you share that experience, the target user is clear. Output is for a team that writes TypeScript, ships LLM-backed features, and is tired of wiring a prompt store, an observability vendor and an eval runner together by hand. The README frames the alternative as one framework where prompts, evals, tracing, cost tracking, orchestration and credentials all sit in your repository. A second audience is named explicitly: people using Claude Code. The README states that every workflow is a folder holding code, prompts, tests, evals and traces, so an agent can read one directory and have full context. That is a real structural claim, not a slogan, because it constrains how you lay out a project.
Workflows, steps and evaluators: the three primitives
The framework exposes three constructs. A workflow is declared with workflow({ name, fn }) and the README describes it as deterministic coordination logic with no I/O. A step is declared with step({ name, fn }) and is where I/O happens: API calls, LLM requests, database queries. The README states that each step runs once and its result is cached for replay. That split is the same discipline Temporal imposes on its own users, and it is the part of Output most likely to trip up someone who has only written ordinary async TypeScript. If you put a fetch call directly inside a workflow function, you have broken the model the framework is built on. The third primitive is the evaluator, declared with evaluator({ name, fn }). The README example calls generateText with a prompt name and a Zod schema, then wraps the result in EvaluationBooleanResult with value, confidence and reasoning fields. The README distinguishes offline evaluators for dataset testing from inline evaluators for production retry loops, and mentions deterministic assertions alongside subjective judges.
Prompts as .prompt files with YAML frontmatter
Prompts are files, not database rows. The README shows a .prompt file with YAML frontmatter carrying provider, model and temperature, followed by Liquid-templated content using system and user tags. The example sets provider: anthropic and model: claude-sonnet-4-20250514 with temperature: 0. The README claims you can switch providers by changing one line, which follows from provider being a frontmatter key rather than something buried in application code. The practical consequence is that prompt changes land in pull requests and get reviewed like any other diff. The cost is that prompts stop being editable by non-engineers without a code checkout, which is a trade-off the README does not discuss. If your organization expects a product manager to tune prompts in a web console, this design will feel like a step backwards, and that is worth deciding before you migrate anything.
Getting a project running
The README lists three requirements: Node.js 20 or later, Docker Desktop, and an LLM API key. Scaffolding is npx @outputai/cli init, followed by cd into the generated project directory and adding ANTHROPIC_API_KEY to .env. The README states that npx output dev starts the full development environment: a Temporal server, an API server, a worker with hot reload, and the Temporal UI at http://localhost:8080. The README gives two further commands. npx output workflow run blog_evaluator paulgraham_hwh runs an example workflow by name and input. npx output workflow debug <workflow-id> inspects an execution. Tracing is described as zero config, with JSON written to logs/runs/ containing token counts, costs, latency and full prompt and response pairs. Credentials are encrypted with AES-256-GCM, scoped per environment and per workflow, and managed through the CLI. The README positions this as a way to keep secrets away from coding agents and away from shared .env files. The SDK is split into @outputai/core for workflow, step and evaluator primitives, @outputai/llm for multi-provider LLM access with prompt management, @outputai/http for a traced HTTP client, and @outputai/cli.
Temporal is the durability story and the adoption cost
The README states that Temporal runs under the hood, providing automatic retries with exponential backoff, workflow history, replay on failure, child workflows, and parallel execution with concurrency control. It also says you do not think about Temporal until you need it. That is partly true and partly marketing. The step-level caching the README describes only works if you respect the workflow/step boundary, so Temporal's constraints leak into your code whether or not you read its documentation. More concretely, Docker is a hard requirement, and the development command starts a Temporal server alongside your worker. Teams that cannot run Docker in their environment, or that have standardized on a managed orchestration service, are looking at real migration work rather than a library import. The README does not describe a serverless or Docker-free path, and no release notes were retrieved for this review, so I cannot confirm how the Temporal integration has changed across versions.
Provider coverage and the alternative you are choosing against
The README lists Anthropic, OpenAI, Azure, Vertex AI and Bedrock as supported providers behind one API, with structured outputs, streaming and tool calling behaving the same across them. The realistic alternative for a TypeScript team is the Vercel AI SDK, which Output itself depends on in spirit: the README's evaluator example imports generateText and Output.object from an AI SDK style API. The difference is scope, not model access. The AI SDK gives you a provider-agnostic client and leaves orchestration, retries, trace storage and eval running to you or to other packages. Output wraps that layer with workflows, steps, a CLI and a local trace directory. If you only need to call a model and stream tokens to a browser, the AI SDK is the smaller dependency and the better fit. Output earns its weight when you need replay, retries and a stored record of every run. For Python teams the comparison is different again: LangGraph and similar libraries occupy this space, and Output offers no Python path at all, so a polyglot team would be maintaining two orchestration stories.
Licence, maintenance and what to check before adopting
The repository is Apache-2.0, and the README carries a matching licence badge. That permits commercial use and modification, and it includes an explicit patent grant, which matters if you plan to build a product on top. It is not a copyleft licence, so it does not oblige you to publish your own workflow code. This is a description of the licence text, not legal advice; have counsel review it if the patent or notice provisions affect your distribution model. On maintenance, the material available here is thin. No releases were retrieved, so I cannot report a version number, a changelog or a support policy. The repository is not archived and the last push date is recent, but that alone tells you little about how quickly issues are answered. The upgrade cost you should budget for is the Temporal dependency: bumping Output means bumping the client library that talks to your Temporal server, and version skew there is the failure mode most likely to bite you. Before adopting, read the getting-started guide at docs/guides/start-here/getting-started.mdx in the repository, since the README defers to it for setup detail.
Editorial conclusion
Adopt Output if your team already writes TypeScript, you want prompts and evaluators versioned next to the code that calls them, and you accept running a Temporal server as part of your development environment. Do not adopt it if you need a Python path, if you cannot run Docker locally or in CI, or if your orchestration already lives in a managed platform you are not willing to move. Before committing, verify three things yourself: that npx output dev brings up the Temporal UI on port 8080 in your environment, that the provider list in your installed version of @outputai/llm still matches the README, and that the Apache-2.0 LICENSE file is present at the repository root as the badge claims.
Community notes