Vercel Open-Sources durable-harness: Crash-Proof Coding Agent Sessions

The arms race in AI coding agents has quietly changed lanes. The first half of this year was about who writes code fastest and who ships the biggest context window. Now the fight is over something far less glamorous: whose agent stays up, whose session survives a crash, and who stops burning tokens on work that already finished. Around October 21, 2026 (Vercel's blog post carries no visible date stamp — the date is corroborated across multiple sources, detailed below), Vercel open-sourced durable-harness, a small package that bolts durability onto existing coding-agent harnesses.

One package, zero changes to your harness

The positioning is deliberately modest: durable-harness is neither a new agent nor a new framework. It is a set of adapters and utilities that, in Vercel's words, "extends that durability to any harness" — Pi, OpenCode, OpenAI Codex, Claude Code, plus Vercel's own eve (eve.dev) and fx (fx.sh) — "without changing the harness."

The launch lineup reads like a roll call of the mainstream cloud-agent orchestration layer. Pi and OpenCode have become the engines behind always-on agents built by independent developers — Vercel names OpenWork and HanaAgent as products built on open-source harnesses — while Claude Code and Codex were originally designed for a real local shell and are now pulled into the same durability scheme.

Notice the posture here. Vercel isn't trying to build yet another "ultimate agent" to compete for users. It's choosing to sell water and electricity — owning the "stays up" problem for everyone else's harness. That's the same logic as eve, the agent framework Vercel shipped earlier this month with durable execution built in: move down the stack toward infrastructure, and collect rent at the platform layer.

How it works: log every step, backstop the turn with a queue

The mechanism itself is unglamorous, and Vercel explains it with a concrete demo: an agent adds a pricing page to an existing app — reads the old page, writes the new one, opens a PR, waits for CI. What happens if the function times out while CI is still running?

The answer: every step of a turn is written to a durable log — the intent before a model or tool call runs, the outcome after it finishes — while the turn itself is backstopped by a queue message. If the function dies, the queue hands the turn to a fresh function, which reads the log and picks up where the last completed step left off. No manual restart. The agent keeps running even if your browser disconnects; reconnect, and it catches you up from the log.

After a crash, the log tells you exactly what finished, what was interrupted, and what never started. Three consequences follow:

• Finished calls never run again. In Vercel's words: "you're never billed twice for a finished model's tokens." For anyone running long tasks, this is the line that matters most. Previously, a timeout near the end of a turn meant the burned context and tokens were gone for good. Now the bill, at least, won't be charged twice.
• Tool replay is declared up front, in two tiers. Tools marked replay: 'safe' — file reads, CI status checks — re-run automatically after a crash. Tools marked replay: 'never' — issuing a refund, for instance — never run twice. The model is only told the call may have already happened, and it decides whether to verify before acting. The refund example is telling: idempotency isn't a patch applied after the fact, it's a first-class constraint declared in the tool definition.
• Each harness's own session files get mirrored into the log. Claude Code's transcript, Codex's rollout, OpenCode's event store — every record is mirrored into the durable log, so a new function or a rebuilt Sandbox can reconstruct them from it. This is the pragmatic move: instead of forcing a unified memory format, it backs up every harness's native memory into one shared ledger.

Three workspace tiers: virtual, sandbox, pick your poison

Where files and shells live is the other classic cloud-agent trap: a shared serverless function's filesystem doesn't persist between invocations. The package offers three tiers:

• virtual(): the file tree lives in the session's log, with a bash-compatible shell that can't reach your function's files or the network. Good for short tasks and small workspaces without spinning up a whole sandbox.
• virtual({ durable: false }): an in-memory scratch disk, wiped at the end of every turn.
• sandbox(): the session gets its own Vercel Sandbox, with /workspace mounted on a Drive that outlives every sandbox and every function. This is the tier for real projects and long-running work.

One hard rule stands out: Claude Code and Codex must run in a Sandbox, since they expect a real shell and filesystem and aren't safe for multi-tenant use. Translation: persisting a Claude Code session in the cloud always carries the cost of a Sandbox. "Free durability" doesn't exist.

Pluggable backends: two env vars to self-host on Postgres

Underneath it all sits the Workflow SDK's World interface — the durable backend that unifies the log, the queue backstop, and the stream for watchers behind one interface. The adapters only speak to this interface, so the same agent can move between Worlds without code changes:

• on Vercel, the Vercel World;
• in development, files on your machine;
• on your own servers, Postgres, MongoDB, Redis, or Turso. Moving an agent to Postgres takes exactly two environment variables: WORKFLOW_TARGET_WORLD="@workflow/world-postgres" and WORKFLOW_POSTGRES_URL.

There's also an easy-to-miss design worth flagging: Documents. State that belongs to a session but isn't part of the conversation — a to-do list, a plan, a form the agent is filling in — becomes typed JSON living in the session's log. Tools edit documents through io.docs, and each edit commits to the log alongside the tool's result, so document state stays consistent with the tool calls themselves. Vercel even notes that the virtual() workspace is built on documents. In other words, this package's "memory" isn't just chat history — it's workspace files plus structured state, a fuller session ledger.

The observability story is Vercel's Agent Runs panel: a trace for every session, covering each model call and tool call, with crash-resumed turns appearing in the same trace so you can see exactly where a turn stopped and picked back up. For debugging long tasks, that's table stakes — otherwise you can't tell whether the agent genuinely recovered or is just hallucinating continuity.

It's not the first to try to tame agent state

MarkTechPost's coverage includes a comparison table that deserves a closer look:

Option	What it is	Durability backend	Status
durable-harness	Durability adapters for existing coding harnesses	Workflow SDK World (Vercel, local, Postgres)	0.0.x, experimental
Temporal + OpenAI Agents SDK	Durable execution wrapper for OpenAI Agents SDK	Temporal server or Temporal Cloud	GA since March 2026
Inngest AgentKit	TypeScript multi-agent framework	Inngest orchestration engine	Not disclosed
Cloudflare Agents SDK	Stateful agents on Durable Objects	Durable Objects, Cloudflare Workflows	MIT licensed

The differentiator is clear: it doesn't build a new framework; it's a bolt-on for other people's frameworks. Temporal's approach is heavyweight — you move your whole workflow into its worldview. Cloudflare's is bound to Durable Objects. durable-harness says: keep your harness, let us handle the crashing. That non-invasive positioning is precisely why it has the best shot at real adoption — no agent rewrite required, just an adapter layer.

The price of that positioning is equally clear: Temporal has been GA for over half a year, Cloudflare's Durable Objects are a battle-tested storage primitive, and durable-harness is at 0.0.x with, as the table notes, no published benchmarks. Anyone reaching for it should read that row first.

Vercel's open play: from deployment platform to agent infrastructure

Zoom out and this release isn't isolated. At Vercel Ship 2026 on October 15, the company launched Drives — persistent file storage that survives sandbox shutdowns and can be mounted by new sandboxes or forked for parallel exploration — alongside Daemons with Python support, the eve agent framework, and the MCP Events beta. durable-harness is the least Vercel-bound piece of that lineup: it even lets you move an entire agent to self-hosted Postgres with two environment variables.

Don't let "portability" fool you, though. The World interface is open, but the best versions of the companion experience — the Agent Runs trace panel, Vercel Sandbox, Drive — will always grow fastest inside Vercel's own cloud. Self-hosted Postgres works, but the experience ceiling sits on Vercel's side. It's a shrewd platform play: open the core protocol, rent out the experience layer. Kubernetes won the same way.

At a deeper level, Vercel is betting that the agent "session" becomes a cloud resource — orchestrated, stored, and observed like containers and functions before it. The World interface is their proposed resource abstraction for it: log, queue, stream, all in one. If enough harnesses adopt it, Vercel becomes the state-layer vendor of the agent era. Consider what that position was worth for S3 in the object-storage era.

Practical guidance, in three tiers

Tier one: indie developers running always-on agents. If you already run Pi or OpenCode around the clock — auto-triaging issues, writing weekly reports — durable-harness is worth piloting on a non-critical task. Two caveats: it's experimental, so don't bet production on it; and Claude Code/Codex require a Sandbox, so model the cost before you start.

Tier two: teams building products on open-source harnesses (the OpenWorks and HanaAgents of the world). The adapter is a direct win: no need to build crash recovery yourself, and harness upgrades don't break you since the adapter is external. But budget for log growth — every step of every turn writes intent plus outcome, and long tasks will generate real storage and I/O costs on your World backend.

Tier three: everyone else. The most stealable thing here isn't the package, it's the design pattern: record intent before the call, outcome after; declare replay policy per tool; tell the model "may have run" instead of "didn't run." All three work in your own agent engineering today, with zero Vercel dependency.

The takeaway: infrastructure is going cloud-native, but don't ship prod on 0.0.x

Look at the arc of agent infrastructure this year: the first half was a hundred-model brawl over benchmarks, and the second half has Vercel, Cloudflare, and Temporal carving up the layers — state, execution, observability each growing their own middleware. durable-harness marks the moment "keeping agents alive" graduated from everyone's private dirty work into a capability you can adopt, or even get for free as open source.

That's good for the ecosystem: harness developers can go back to prompts, tools, and context engineering — the "intelligence" layer — instead of wrestling function timeouts and network jitter. But the honest caveat: a 0.0.x experimental package has a beautiful demo and a thin production story. The direction is right; the timing isn't. Study the design pattern now, adopt the package when it grows up.

Primary source: Vercel's official blog post "Making every harness durable" (https://vercel.com/blog/making-every-harness-durable). A note on dating: the blog page's fetched text shows no explicit publication timestamp. "October 21, 2026" is corroborated across multiple sources — the MarkTechPost article URL contains /2026/10/21/, Jeepney News labels it October 21, 2026, Wisevoter's text states "released the durable-harness package on October 21, 2026," Vercel's official LinkedIn posted about it roughly three days prior, and the TLDR AI October 21, 2026 edition included it. The reporting is consistent, so this article uses that date.