durable-harness

Recovery may replay some tool calls that have already been executed, and if these calls are not idempotent (for example, writing files or sending requests repeatedly), side effects may occur.

Currently available public information focuses on the feature level; the actual recovery granularity, logging overhead and specific integration methods with each agent still require examining the code and documentation to judge.

Vercel's choice to open-source durable-harness rather than offer it as closed source suggests that durability for coding agents is shifting from a differentiating feature to infrastructure.

durable-harness's durability is made into an independent harness layer decoupled from specific agent logic; agents still initiate model calls and tool calls as before, and the harness intercepts and records these events in between.

durable-harness explicitly lists Pi, OpenCode, Claude Code and Codex as supported targets.

According to MarkTechPost, durable-harness is designed to cover three runtime environments: the Vercel platform, Postgres, and local laptops.

durable-harness's persistence layer must be embedded at the harness's loop boundaries, taking checkpoints before and after each round of model calls and tool execution.

Different harnesses have different state models and loop structures, so it is impossible to adapt a persistence layer once and for all through a unified interface.

The only public information is a single launch tweet from Vercel; durable-harness's pricing, technical documentation, state serialization mechanism, integration methods with various harnesses, and actual resource performance for months-long runs have all not been disclosed.

durable-harness writes to the World interface, so the same agent can migrate from one World to another without code changes: use Vercel World on Vercel, local files during development, and Postgres, MongoDB, Redis, or Turso when self-hosting.

In durable-harness, migrating an agent to Postgres only requires setting two environment variables, WORKFLOW_TARGET_WORLD and WORKFLOW_POSTGRES_URL.

A document in durable-harness is typed JSON that lives in the session log, survives crashes, and moves with the session; tools can edit documents via io.docs, and each edit is committed to the log together with the tool result.

durable-harness uses the same mechanism that powers the Workflow SDK to resist crashes and function timeouts.

The core design of durable-harness is "log and queue": record the intent before a model call or tool call runs, and record the result after the call completes; turns are backed by queue messages, and after a function dies, a new function reads the log and continues from the breakpoint.

durable-harness records the results of completed calls in the log and reads from the log upon recovery, so it does not repeatedly pay token costs for model calls that have already completed.

An interrupted tool that is marked `replay: 'safe'` will be re-run; other tools are returned to the model with a "possibly already ran" status, and the model decides whether to check.

durable-harness offers three filesystem options: virtual() (files are kept in the session log, with a bash-compatible shell, and no access to function files or the network), virtual({ durable: false }) (files are kept in memory and cleared at the end of each turn), and sandbox() (provides a separate Vercel Sandbox, with /workspace located on Drive).

For frameworks that keep their own session files (such as Claude Code's transcript, Codex's rollout, and OpenCode's event store), every record is mirrored into the log, from which new functions or Sandboxes can reconstruct them.

Claude Code and Codex always run in a Vercel Sandbox within durable-harness, because they need a real shell and filesystem and are not suited to multi-tenant use.

durable-harness places /workspace on Drive storage, which is more durable than the sandbox itself, so workspace files remain after a sandbox instance is reaped or rebuilt, and a new sandbox can mount the same Drive to continue working.