Si la máquina que mueve a tu agente de código se cae a mitad de turno, el trabajo de ese turno se pierde. durable-harness, de Vercel Labs, apunta cada llamada al modelo y a cada herramienta en un registro antes y después de ejecutarla, y retoma el turno en otra máquina sin volver a pagar lo que ya se hizo. El repositorio, creado el 16 de octubre de 2026, suma 299 estrellas y recibió commits el 9 de noviembre.
Qué es y cómo funciona
durable-harness envuelve "harnesses" de agentes de programación existentes (Claude Code, Codex, OpenCode, Pi y fx de libfx) y los ejecuta sobre un World del Workflow SDK de Vercel. Cada sesión es una ejecución de workflow: la conversación, el turno en curso y cada llamada al modelo y a herramientas quedan en el registro de eventos de esa ejecución.
El mecanismo, según el post de presentación del 19 de octubre de 2026:
- Antes de cada llamada se registra la intención, y al terminar, el resultado.
- Cada turno va respaldado por un mensaje en cola. Si la función muere, la cola entrega el turno a otra, que lee el registro y continúa.
- Las llamadas terminadas se leen del registro en lugar de repetirse, así que una respuesta del modelo ya generada no se cobra dos veces.
- Las herramientas interrumpidas marcadas con
replay: 'safe'se vuelven a ejecutar. Las marcadas conreplay: 'never'no: al modelo se le dice que la llamada pudo ocurrir para que lo compruebe antes. - En los harnesses con estado propio en disco (el transcript de Claude Code, el rollout de Codex, el event store de OpenCode), esos registros se reflejan en el log.
Está escrito en TypeScript, con licencia Apache-2.0, y se publica en npm; la última versión es la 0.0.2.
Cómo se usa
El README propone Pi con su harness durable dentro de una app Next.js:
npm install durable-harness @earendil-works/pi-durable @earendil-works/chord @earendil-works/pi-ai just-bashLuego se expone una ruta de chat con chatRoute({ open, agent, authorize }) y se envuelve la configuración de Next con withDurableHarness(nextConfig), que descubre los módulos que exportan agentes. En local usa el World local del Workflow SDK sin configurar nada. En Vercel, el almacenamiento, la cola y el escalado son gestionados, y cada sesión aparece en Agent Runs. Fuera de Vercel se puede usar Postgres, MongoDB, Redis o Turso; para Postgres bastan dos variables, WORKFLOW_TARGET_WORLD y WORKFLOW_POSTGRES_URL.
Dos detalles de seguridad importan en un despliegue real. Los agentes empiezan sin herramientas, y los comandos y ficheros que elige el modelo se ejecutan en un espacio de trabajo virtual (just-bash sobre un sistema de ficheros virtual) o en una Vercel Sandbox por sesión, nunca en la máquina que dirige la sesión. Y en producción, una ruta de chat sin authorize rechaza todas las peticiones con un 401: quien pueda usar la ruta ejecuta tu agente con tus créditos.
Lo que me convence y lo que no
Me convence que ataque el problema correcto. Un agente de código que trabaja horas en la nube falla por motivos aburridos (un timeout, un redeploy, un nodo que se recicla) y eso significa repetir el turno entero, con su coste en tokens. El modelo de intención y resultado, con la distinción entre herramientas repetibles y no repetibles, es el patrón de cualquier sistema de workflows durables aplicado a agentes. Y la documentación de seguridad es inusualmente honesta: dice que una Sandbox permite todo el tráfico saliente por defecto (hay que pasar network: 'deny-all' o una lista de hosts) y que Codex puede acabar ejecutando comandos con acceso completo dentro de su Sandbox si no puede arrancar la suya propia.
Lo que no: el propio README avisa de que es experimental, está en 0.0.x y su API puede cambiar entre versiones. Hay 24 issues abiertos. Y la portabilidad tiene un límite importante: Claude Code y Codex solo se ejecutan en una Vercel Sandbox, y durable-harness se niega a lanzarlos en cualquier otro sitio, incluido un servidor propio. El motivo es razonable (son CLI pensadas para un solo usuario que guardan estado en disco), pero significa que el autoalojamiento con Postgres solo cubre Pi, OpenCode y fx. Si quieres Claude Code durable, el cómputo es de Vercel.
durable-harness frente a un agente en una VM en la nube
No hay una herramienta abierta equivalente consolidada; lo habitual hasta ahora era sacar el agente del portátil a una máquina virtual en la nube. El post de Vercel explica por qué no basta: la VM no sabe qué llamadas al modelo y a herramientas terminaron ni retoma un turno interrumpido.
| durable-harness | Agente CLI en una VM | |
|---|---|---|
| Tras un crash | Retoma el turno desde el registro en otra máquina | Turno perdido, se repite entero |
| Llamadas al modelo ya hechas | Se leen del log, no se pagan dos veces | Se vuelven a pagar |
| Efectos secundarios | replay: 'never' evita repetirlos | Sin protección |
| Aislamiento | Workspace virtual o Sandbox por sesión | El de la VM, compartido |
| Despliegue | Vercel o World propio (Postgres, MongoDB, Redis, Turso) | Cualquier VM |
| Madurez | Experimental, 0.0.x | La del propio CLI |
Cuándo usar cada uno. Si estás construyendo un producto en el que agentes de código trabajan para varios usuarios a la vez, con turnos largos y herramientas que tocan sistemas reales (un PR, un pago, un correo), durable-harness resuelve la parte que nadie quiere escribir. Si solo necesitas que un agente trabaje sin tu portátil encendido, una VM sigue siendo más simple y no te ata a una API en 0.0.x.
Fuentes
- vercel-labs/durable-harness, GitHub.
- Making every harness durable, Vercel, 19 de octubre de 2026.
- Security for Durable Agent Harnesses, documentación de Vercel.
- durable-harness, npm.