Trigger.dev vs Temporal (2026): which orchestrator for your AI agents?

Two orchestrators, one problem: keeping AI agents alive between calls

An AI agent is not a request-response API. It is a long-lived loop where the agent reads context and calls an LLM, the LLM may ask for a tool call, the tool result feeds back into the next LLM call, and the agent decides whether to keep going. A non-trivial agent loop runs for minutes or hours, sometimes days if it is doing a long deep-research session or running a 50-step coding task.

The naive way to host this loop is a serverless function, and the naive way fails immediately. Serverless functions time out (Lambda caps at 15 minutes, Vercel functions at 5 to 15 minutes depending on tier). Long LLM calls (Claude Opus on a complex prompt, a slow Anthropic streaming response) can themselves take longer than that ceiling. The agent loop also needs to survive network blips, LLM-provider 503s, partial tool failures, and your laptop sleeping. The cost of restarting from scratch every time something fails is unacceptable on a 50-step run with $0.10 per step.

The category that solves this is called durable execution. The system writes every step of the agent loop to a persistent log, replays the loop from the last checkpoint on any failure, and gives you the primitives (retries, idempotency keys, long sleeps measured in days, cross-process resume) that turn a fragile script into something a regulated bank would run in production. Two products dominate the durable-execution conversation in 2026: Trigger.dev and Temporal. This article is the comparison.

Trigger.dev: the TypeScript-first challenger

Trigger.dev was founded in 2022 by Matt Aitken (CEO) and Eric Allam (CTO), based in London. The company is a YC W23 batch alum. The original product was a workflow + integration tool that competed with Zapier. The pivot to "durable background jobs done right" happened in 2023-2024, and the V4 release went GA on August 18, 2025. V4 is the version that turned Trigger.dev into a credible AI-agent orchestrator: Waitpoints for human-in-the-loop, the Realtime API for streaming LLM tokens to a browser, versioned AI Prompts, and idempotency keys on every trigger and wait.

Funding stack: roughly $20.3M raised total, with a $16M Series A in December 2025 led by Standard Capital with Y Combinator participating. Team size is between 9 and 18 people depending on source (YC shows 9, GetLatka 18, PitchBook 7). Headcount is small. License is Apache 2.0. The GitHub repo sits at 15.1k stars as of May 2026 and is 98.7% TypeScript.

The DX is the whole pitch. You write tasks as plain async TypeScript files, deploy them with one CLI command, and the dashboard shows you live runs, logs, retries, and replays. Self-hosting is a single docker-compose with Postgres + Redis (no Cassandra cluster, no Elasticsearch sidecar, none of the Go-service multi-tenant ceremony Temporal asks for). The AI-agents docs include an official Claude Agent SDK + Trigger.dev guide and a working claude-code-sdk-trigger-example repo. The whole project is built for engineers who want to ship an agent this afternoon.

Temporal: the polyglot incumbent

Temporal was founded by Maxim Fateev and Samar Abbas, the same engineering team that built Cadence at Uber. The company is Seattle-based. The first commercial product launched in 2019, and the project is now MIT-licensed. The server is a Go service (99.5% Go in the repo) backed by Cassandra, MySQL, or Postgres for the main database and Elasticsearch for visibility/search. Client SDKs ship for Go, Java, Python, TypeScript, .NET, PHP, and Ruby.

Funding stack: roughly $650M raised across multiple rounds, with a $300M Series D in February 2026 at a $5B post-money valuation (per GeekWire). Headcount sits in the 431 to 499 range depending on source. The public customer count is 2,500-plus. GitHub: 20.6k stars, latest server release v1.31.0 (April 29, 2026).

The model is event-sourced deterministic replay. Your workflow code runs as a Workflow (the deterministic part) that orchestrates Activities (the side-effecting parts). The system records every event in a history log. On any failure, Temporal replays the workflow code against the history to reconstruct exact state, then resumes from the failure point. This makes "the laptop went to sleep" and "the database fell over for 4 minutes" non-events. The trade is that you have to write workflow code that stays deterministic. Random numbers and inline UUID generation break the replay; so does calling Date.now() from inside the workflow), which is a learning curve.

OpenAI confirms publicly that Temporal powers ChatGPT Images and Codex. The OpenAI Agents SDK + Temporal integration went GA in April 2026, which is the cleanest signal of where Temporal sits in the AI-agent stack at the high end of scale.

How they actually differ (side-by-side)

The fastest way to read this comparison: most rows favor Temporal on raw capability and Trigger.dev on developer ergonomics. The price-versus-power trade is real.

A few rows are worth dwelling on. The 51,200-events ceiling on Temporal is a real workflow-execution limit that bites long agent loops. LLM calls, tool results, and timer fires all count as events on the workflow history. A long deep-research run can hit the ceiling and force a Continue-As-New (a Temporal pattern where you split the workflow into chunks and pass state forward). Trigger.dev does not have an equivalent ceiling; an agent loop just runs.

The determinism rules in Temporal are the most-quoted gotcha for new users. Workflow code cannot generate random numbers, read the system clock, or call any non-deterministic function inline. Side effects go through Activities. This is the architecturally correct way to do this, and Temporal is correct that it produces more reliable workflows in the long run, and it is also the reason a brand-new Temporal team takes a week to ship their first workflow versus an afternoon on Trigger.dev. The "first task running" gap in the table is real.

The Claude / Codex / Cursor / Roo Code question (use cases)

Both orchestrators host the same AI-agent brains. The "what runs inside the workflow" choice is the same on either side: you pick a coding agent or LLM SDK and the orchestrator handles the durability around it. The interesting question is which orchestrator each brain currently has the most production traction on.

Claude Agent SDK (Anthropic)

The Claude Agent SDK is Anthropic's framework for building autonomous agents that loop tool calls, write files, run shell commands, and continue until a task is done. The SDK ships under both a TypeScript and a Python interface and is the canonical "brain" for Claude-powered agent workflows.

On Trigger.dev: there is an official Claude Agent SDK guide in the docs and a working claude-code-sdk-trigger-example repo. The integration is first-class because Trigger.dev is TypeScript and so is the most-shipped Claude Agent SDK runtime. The pattern is: wrap the Claude SDK call inside a Trigger.dev task, set a high maxDuration (hours), use Waitpoints for any human-in-the-loop confirmation, and the orchestrator handles every retry and resume for you.

On Temporal: community tutorials exist (notably from the Claude Lab team) showing Claude Agent SDK running inside Temporal Workflows with the same activity/workflow split as any other long-running process. Anthropic is also listed publicly as a Temporal AI customer, though not specifically for Claude Agent SDK orchestration. The TS SDK on Temporal works; the polyglot story matters only if you need Python or Go workers in the same workflow.

OpenAI Codex

OpenAI Codex is OpenAI's coding-specific agent (separate from the ChatGPT app). The Codex CLI and the OpenAI Agents SDK are the two surfaces engineers wire into orchestrators.

On Temporal: this is the strongest first-party story in the comparison. OpenAI confirmed publicly that Temporal powers ChatGPT Images and Codex inside OpenAI itself, and the OpenAI Agents SDK + Temporal integration went GA in April 2026. If you are building anything that should mirror the production architecture OpenAI uses internally for its own agents, Temporal is the default answer.

On Trigger.dev: the OpenAI Agents SDK works fine inside a Trigger.dev task, but you do not get the same first-party endorsement Temporal has. For most teams that does not matter. For teams trying to convince a procurement team that "this is what OpenAI uses internally" matters, Temporal is the easier story.

Cursor background agents

Cursor's background agents are a different shape: they run inside Cursor's own cloud, not your orchestrator. You point Cursor at a task ("rewrite this module to use the new API, run the tests, open a PR") and the agent works in a remote environment with your codebase mounted. There is no "host Cursor inside your orchestrator" question because Cursor handles the runtime itself.

Where both Trigger.dev and Temporal come in: the workflows that feed Cursor agents (queue up a backlog of refactors, gate PRs through a Slack approval, run downstream test suites and merges) are exactly the durable-execution use case both orchestrators are built for. The pattern: your orchestrator triggers a Cursor agent run via Cursor's API, then waits (durably) on the webhook callback when the agent finishes. Trigger.dev's Waitpoints make this elegant; Temporal's signals do the same thing with more ceremony.

Roo Code (and Cline)

Roo Code (formerly Roo Cline, a fork of Cline) is a coding agent that runs inside VS Code, handles tool calls, file edits, and shell execution. It is more "in your editor" than "in your backend," so the orchestration use case is narrower than Claude Agent SDK or Codex. Most teams that want Roo Code in a workflow are scripting a CI-style pipeline (lint, refactor, commit) where Roo Code is one step.

On either orchestrator: you treat Roo Code as a subprocess called from a task, capture its output, and pipe the result into the next step. There is no first-party integration in either direction. Neutral on which orchestrator you pick for Roo Code.

Pricing and total cost of ownership

Sticker-price comparison is a trap because the two products bill on different axes. Trigger.dev bills per-task plus compute-seconds. Temporal bills per-Action (a workflow start, signal, timer, activity, or heartbeat is each one Action). Below is a like-for-like read on a hypothetical AI-agent workload of 50,000 agent runs per month, each running roughly 30 LLM/tool steps to completion.

Three things to know about the pricing math. First, Trigger.dev publishes every number; Temporal publishes the per-Action floor but Enterprise is "contact us" territory (Vendr-style negotiation). Second, the self-host math swings hard in Temporal's favor at scale and against Temporal at small scale because the Cassandra cluster has a fixed cost that you pay whether you have 100 workflows or 100 million. Third, Trigger.dev's compute-second model can run cheaper than Temporal Cloud at low-to-mid volume but crosses over once you have enough Actions to amortize the cluster.

Who is actually using each (named)

Temporal publishes the longest list. Netflix is on it for next-gen CI/CD, Stripe for financial workflows, Snap for cross-org orchestration, and Datadog has reported more than 100 internal teams using it. HashiCorp, Coinbase, OpenAI (ChatGPT Images and Codex), Replit, Lovable, Abridge, and Anthropic also appear on the public AI customer page. The "powers the infrastructure other startups depend on" framing is real.

Trigger.dev has fewer named flagship customers in public sources, which is the usual story for a younger company that has not yet run the case-study marketing playbook at scale. The community examples in the docs reference customers running roughly 6,000 docs per month and one orchestrating 10,000-plus government sources, neither of which is named. The visible adoption signals are GitHub stars (15.1K, growing fast), the npm download trajectory on @trigger.dev/sdk, the size of the YC W23 cohort that has shipped on it, and the velocity of the team's changelog. None of those are a Netflix-grade customer logo, but the trajectory is steep.

When to pick Trigger.dev

You are a TypeScript-first team. Your AI agent is the primary thing you are building, not one of fifty backend services. You want to ship something this afternoon. You do not have (and do not want to hire) a platform engineer whose job is "keep the durable-execution cluster healthy." You like opinionated tools that include the AI-agent patterns out of the box (Waitpoints, Realtime, AI Prompts) rather than tools that give you primitives and trust you to assemble the patterns yourself.

Honest concession: at very large scale, you will outgrow Trigger.dev's opinionated model. The TS-only constraint will eventually be a wall (the day you need a Python worker for some ML pipeline that sits inside the same workflow). The 9-to-18-person team will be a procurement red flag for a Fortune 500 vendor-risk review. If either of those is in your foreseeable future, look at Temporal up front rather than migrating later.

When to pick Temporal

You have a polyglot codebase already (Go + Python + TS + something else). You are in a regulated industry where the audit trail and exactly-once semantics matter. You are running workflows that exercise saga patterns (compensating actions across multiple services). You have already paid the operational price for a Cassandra cluster or you can afford a dedicated platform team. You want the AI-agent integration that mirrors what OpenAI uses internally for its own products.

Honest concession: if you are a two-person startup building one AI agent, Temporal is overkill. The determinism rules in workflows take a week to internalize. The Cassandra-plus-Elasticsearch self-host is a real ops burden. The pricing transparency is worse than Trigger.dev's. None of these are dealbreakers, but you should know what you are signing up for.

The two-tier reality

A pattern I keep seeing: AI startups under 25 engineers ship on Trigger.dev. AI startups over 100 engineers ship on Temporal. The crossover happens somewhere around the time you hire your first platform engineer. The reason is not religious; it is that Trigger.dev's strength (opinionated, narrow, fast-to-ship) becomes a weakness when you have enough workflows that they need polyglot workers and the team large enough that "we will just keep using the same orchestrator for everything" is the wrong answer.

If you are planning to be one of those companies that crosses the boundary in 24 to 36 months, the honest move is to start with Trigger.dev and migrate when you cross the line. The cost of starting with Temporal too early is roughly 4 to 8 weeks of platform-engineering time you do not have, versus the cost of migrating later which is roughly 6 to 12 weeks of refactoring you will have the team to absorb.

For the specific case of building AI agents (Claude Agent SDK, Codex via OpenAI Agents SDK, Cursor background-agent workflows): start with Trigger.dev unless one of the four "pick Temporal" boxes above is checked. Wire your agent loop inside a task, use Waitpoints for human-in-the-loop, and lean on the AI Prompts feature for prompt versioning. Move to Temporal when you cross the boundary, not before. See our broader take on Wispr Flow review (2026) for the voice-input side of the same agent stack, and the GTM Engineer role in 2026 for who is actually building this in revenue teams.

Common myths about Trigger.dev vs Temporal

Frequently asked questions

Which one has better AI-agent support?

Trigger.dev ships the most opinionated AI-agent toolkit out of the box (Waitpoints for human-in-loop, Realtime for streaming LLM tokens, AI Prompts versioning, idempotency on every trigger). Temporal has the best production-scale AI customer references (OpenAI uses Temporal for ChatGPT Images and Codex; Anthropic is a Temporal customer). For a team building their first AI agent: Trigger.dev. For a team building the next OpenAI: Temporal.

Can I switch from one to the other?

Not without rewriting your workflows. The execution models are different enough that the workflow code itself is not portable. Switching usually means: re-implement each workflow in the new tool's SDK, run both systems in parallel during the cutover, migrate state for in-flight workflows by either draining them or writing a one-time bridge. Realistic migration time for a small team: 4-8 weeks. For a team with hundreds of workflows: months.

What about Inngest? Hatchet? Restate? Wundergraph?

They exist and are credible. Inngest is the closest competitor to Trigger.dev in spirit (TypeScript-first, AI-agent-friendly). Hatchet is positioned similarly with a Python emphasis. Restate is the newest entrant with an interesting "durable handlers" model. None of them have Trigger.dev's YC-cohort traction or Temporal's enterprise depth yet. For this article I focused on the two products that come up in nine out of ten "which orchestrator" conversations I have with engineering teams. See Matthieu Mordrel's ultimate guide for a wider survey if you want to evaluate the long tail.

Will my AI agent get faster on one vs the other?

No. The orchestrator is not on the hot path for any individual LLM call or tool execution. The 95th-percentile latency of your agent is dominated by the LLM's response time and your tool calls. Both orchestrators add roughly 10 to 50 milliseconds of overhead per step, which is invisible next to a 2-second Claude Opus call. Pick on developer experience, ops burden, and price, not on per-step latency.

Does self-hosting save real money?

Trigger.dev: yes, almost immediately. The self-host stack is Postgres plus Redis plus their containers, which runs on a single small VPS or in a managed-DB setup for roughly $50/mo at small prod volume. Compare that to $50-100/mo on Trigger.dev Cloud and the math favors self-host the moment you have any volume. Temporal: yes, but only at scale. The Cassandra cluster has a fixed cost ($2,500-4,500/mo on conservative AWS sizing) that you pay whether you have 100 workflows or 100 million. Self-host pays off above roughly $10-15K/mo of Temporal Cloud spend; below that, the cluster cost dominates.

What is the actual learning curve gap?

A TypeScript engineer who has never seen either tool: roughly 1 day to ship a working task on Trigger.dev, roughly 1 week to ship a working workflow on Temporal. The Temporal gap is dominated by internalizing the determinism rules (no Date.now() inside workflows, no random numbers, side effects go through Activities). Both tools have good docs. Trigger.dev's are friendlier; Temporal's are more complete. Trigger.dev rewards "just ship it"; Temporal rewards "read the manual first."

Are there any horror stories?

Both products are mature enough that the public horror stories are rare and usually self-inflicted. The most common Temporal pain: hitting the 51,200-event history limit on a long agent loop without setting up Continue-As-New, which causes the workflow to fail unexpectedly. The most common Trigger.dev pain: under-budgeting compute for a long agent loop and hitting concurrency limits on the free tier. Both are configuration issues, not product bugs. The deeper failure modes (Cassandra split-brain on self-hosted Temporal, queue backlog on Trigger.dev during a deploy) require ops attention but are well-documented.

What is Temporal worth at $5B?

Probably high but not unreasonable. Temporal has 2,500-plus customers, OpenAI runs ChatGPT Images on it, and durable execution is one of the few categories where the cost of switching once you are in production is high enough to support real enterprise pricing. The bear case is that a chunk of that valuation prices in being the default for "AI agents at scale" specifically, and OS-vendor (AWS Step Functions is improving, Cloudflare Durable Objects keeps eating market) plus open-source competition (Restate, Inngest, Trigger.dev) keep the lid on growth. Whether $5B is the right number depends on whether durable execution is a tier-one infrastructure category long-term. I think it is.

Sources and methodology

This article synthesizes a parallel research brief commissioned in May 2026 plus first-hand experience shipping AI-agent workflows on both Trigger.dev and Temporal during the past nine months. Pricing verified May 2026. Re-verification cadence: quarterly on Trigger.dev pricing (changes occasionally), twice yearly on Temporal pricing (more stable). Where a number came from a single source, the source is linked inline. No first-party "we audited" claims appear without verification.

Primary sources, linked above and re-listed for traceability:

• Trigger.dev, V4 GA changelog (Aug 18, 2025)
• Trigger.dev, Series A announcement ($16M, Dec 2025)
• Trigger.dev, pricing page
• Trigger.dev, AI agents overview docs
• Trigger.dev, Claude Agent SDK guide
• Trigger.dev, claude-code-sdk-trigger-example repo
• Trigger.dev, concurrency + queues docs
• Trigger.dev, YC W23 page
• Trigger.dev, official vs Temporal comparison page
• GeekWire, Temporal raises $300M at $5B valuation (Feb 2026)
• Temporal, Cloud pricing docs
• Temporal, workflow execution limits (51,200 events)
• Temporal, OpenAI Agents SDK integration announcement
• Temporal, AI solutions page
• Temporal, customer logos page
• Temporal, self-host deployment guide
• Anthropic, Claude Agent SDK overview
• OpenAI, Codex landing
• Cursor, background agent docs
• Roo Code
• Matthieu Mordrel, TypeScript orchestration ultimate guide
• Claude Lab, Claude Agent SDK + Temporal production guide
• HN discussion, Trigger.dev V2 as Temporal alternative
• Temporal Cloud vs Self-Hosted 2026 cost analysis