Daily Edition Sources +15

Vercel gives coding agents a life beyond one process

The new durable-harness package lets existing agents recover from a saved work record. Its most useful distinction is between work that finished, work that never started and work whose outcome needs checking.

repos vercel-labs/durable-harness + earendil-works/pi evidence
15 source signals 2 repos 2 linked commits
Evidence: 2 linked commits / October 21, 2026 / Daily Edition
Open Edition Evidence below

A coding agent has several parts. The model proposes what to do. Tools read files, run commands or contact other services. The harness manages the conversation and the loop between them. Vercel’s durable-harness adds a recovery layer around that machinery: storage remembers the session, and a queue arranges for another process to continue it.

Introduced in Vercel’s October 19 announcement, the open-source package supplies integrations for Pi, OpenCode, Claude Code and Codex. The attraction is practical: an application builder can keep an existing harness while making its work survive a function timeout or process crash. The browser connection can disappear without becoming the end of the assignment.

The underlying idea is larger than keeping a machine awake. Continuity becomes a record another machine can read. Inspecting the implementation also reveals two choices a builder still has to make: how uncertain actions are handled, and which parts of the system actually move when the storage backend changes.

The work record

A stopped process leaves three kinds of work.

Consider an agent that has prepared a review and started posting a comment on a pull request. Its process stops before the tool reports back. The comment might exist already. Starting the whole job again would discard useful work; blindly repeating the last action could post it twice.

The kernel’s recovery test captures that distinction. It creates a completed model step and an unfinished tool call, then opens the same storage through a new runtime. The test expects the recorded model step to retain a single attempt and the interrupted tool to be reported as uncertain. It uses a scripted harness, not a live model.

Follow one interrupted comment.

The saved log stays in place while the process changes. Select a moment to see what the next process can know.

The model result is saved. The comment tool has started, but its outcome has not reached the log.

Recorded resultThe review is prepared.

The completed model result is stored. Recovery can reuse that recorded work.

Recorded intentThe comment may have been posted.

The tool started, but no result is saved. With replay set to never, recovery reports uncertainty instead of automatically repeating this call.

Remaining workThe final answer has not begun.

The resumed model is instructed to check the pull request before repeating an action that may already have happened.

Schematic, not a recorded run. After recovery, the known result remains available, the comment’s outcome still needs checking, and the task can continue. Based on the recovery note and tool-call identity. The illustration does not establish that a model will make the correct next decision.

For process-based harnesses, the recovery code constructs a message from the log: which calls completed, which failed and which may have taken effect. It tells the model to inspect actual state before repeating uncertain actions. This is an explicit handoff of unfinished work.

The tool author chooses a replay policy. Under safe, repetition is permitted; Pi retries automatically, while the other three integrations tell the model it may repeat the call. Under never, the interrupted call is not automatically rerun. That protection belongs to the logged call’s identity. It does not prevent a later, newly requested call from attempting the same business operation.

That is why a comment, payment or deployment still needs its own way to identify duplicates or check results. Recovery supplies the missing context for that decision. It cannot infer what an external service did merely because the local process stopped.

Where the files live

Two workspaces make different promises.

The workspace implementation makes the storage boundary concrete. By default, a small virtual workspace keeps its files in the session log. Its changes commit alongside the tool result. A Vercel Sandbox instead supplies a real execution environment with a persistent Drive; an interrupted command can leave partial changes there.

Virtual workspace: files and result travel together.
Useful for small, bounded tasks. Its simulated shell cannot install packages, start real processes or reach the network. A crash before the commit leaves the durable file changes unapplied.
Sandbox Drive: the working directory persists.
Useful for real project commands. The next process inherits files that may reflect a partly completed action, so recovery must account for what the command already changed.

The repository includes a particularly revealing test: kill a child process after a document or virtual-file edit but before its outcome is recorded, then recover in a different process. The safe-write cases expect one committed revision. The never-replay case expects an interrupted result and no committed document edit. We inspected these tests without executing them; their atomic document behavior should not be extended to arbitrary external APIs or shell commands.

There is a similar boundary for model work. Preserving a recorded answer can avoid recomputing it. A response cut off during generation may have to be generated—and billed—again, as the process-harness implementation explicitly notes. Durability preserves committed progress; it does not make interruption free.

A choice of infrastructure

The log can move without the whole stack moving.

The backend abstraction is called a World. It supplies storage, queueing and streams. The selection code chooses Vercel’s backend on Vercel, local files elsewhere, or a configured alternative such as Postgres. For a local or custom backend, it registers the queue consumer, starts the backend and arranges recovery of sessions left unfinished.

This lets builders separate the choice of agent from the choice of where its continuity lives. It is a useful opening for applications that want an existing agent’s behavior without inventing another session-recovery system.

What changes when the session backend changes? Source checked October 21, 2026.
PartWhat the package separates
HarnessAdapters integrate existing agent loops with the durable session machinery.
Session backendThe World can use Vercel, local files or a configured backend such as Postgres.
Execution workspaceThe public Claude Code and Codex adapters still require Vercel Sandbox.
Model accessModel credentials and service dependencies remain separate from the session database.

The Sandbox restriction is enforced in the Codex adapter and documented for both Claude Code and Codex on self-hosted servers. Moving the log to your own Postgres database does not bring those execution environments in-house. The Postgres World also remains a reference implementation: its documentation assigns route protection and other production responsibilities to the operator.

For Vercel, this architecture makes its infrastructure useful to developers who choose several different harnesses. That is an inference from the integration design, not evidence that developers are migrating or that one hosting choice costs less.

The next useful trial

Test the handoff at the awkward moment.

This follows a concrete thread in our October 18 reporting on Pi: a task can save its next step and hand the wait to a host alarm. Vercel’s contribution here is an integration layer across existing harnesses. It does not establish that Vercel invented durable execution, or that all those harnesses now recover in identical ways.

The inspected package is version 0.0.1-beta.6, with an Apache-2.0 license and a Node.js 22 minimum. For an application builder evaluating it, a useful trial is one disposable task with a read, a write and an external action whose result can be queried. Stop execution once after a saved result and once while the external action is unresolved. Then inspect the resumed session and the external system separately.

That trial should ask whether finished work survives, whether uncertain work is described accurately and whether the application reconciles the external action before trying again. It is a proposed evaluation, not a benchmark we ran. Production recovery time, operating cost and model behavior remain to be measured.

The promising capability is visible already: a coding agent’s assignment can outlive its current process, carrying both completed work and a precise account of what is still unknown. That gives builders a better foundation for unattended work—and a concrete contract to test before depending on it.

Open the Diagram Punk poster
A durable log remains intact between a stopped process and a replacement process. Its entries distinguish a saved result, an unknown outcome and work not yet started.
Diagram Punka saved work record lets another process continue while preserving uncertainty about unfinished actions.

Ask about this article

Vercel gives coding agents a life beyond one process

Article link and summary included. Continue using your ChatGPT account; you may need to sign in.

If your question doesn’t appear in ChatGPT, copy it here and paste it there.

Your immediate reaction

How did this article land?

A thumb saves immediately. Notes stay private and are discussed with the editor before shaping future articles.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateOctober 21, 2026
LaneDaily Edition
Confidence91%
Sources15
Reposvercel-labs/durable-harness, earendil-works/pi

Primary Evidence

Evidence Limits

  • Repository inspected at fb056a3c, dated October 19; reporting and documentation checked October 21, 2026.
  • We inspected implementation and test definitions. We did not execute the upstream test suites, deploy a live agent, measure crash recovery, audit bills or reproduce production outcomes.
  • The interactive comment scenario is explanatory, not a captured run. It does not claim that a model will correctly reconcile an uncertain action.
  • Never-replay prevents automatic repetition of the logged call. It is not an exactly-once guarantee for an external operation or a restriction on all future calls.
  • Atomic virtual-file/document behavior does not describe real shell commands or external APIs.
  • A portable session backend does not establish full independence from Vercel services. The public Claude Code and Codex adapters require Vercel Sandbox.
  • The business implication is explicitly an architectural inference. Sources establish no adoption, market share, cost saving or reliability improvement measured by this publication.