Fork subagents en Claude Code: cuándo heredar el contexto

Un fork subagent en Claude Code es un subagente que, al lanzarse, hereda la conversación entera de la sesión principal: el mismo system prompt, las mismas herramientas, el mismo modelo y todo el historial. Trabaja aparte y solo devuelve su resultado final, así que no tienes que explicarle la tarea desde cero y tu contexto principal no se llena con sus llamadas a herramientas.

La pregunta práctica que te toca responder esta semana es cuándo te conviene que Claude delegue con un fork y cuándo con un subagente limpio. Desde la versión 2.1.302, publicada el 16/10/2026, los forks vienen activados por defecto en claude -p, el Agent SDK, la app de escritorio y VS Code, además de la terminal interactiva, donde ya lo estaban. Es decir, Claude puede elegir hacer forks sin que se lo pidas, y eso cambia el coste, el aislamiento y lo que puedes deshacer.

Qué hereda un fork y qué hereda un subagente normal

La diferencia de fondo es una sola: el fork renuncia al aislamiento de entrada. Un subagente normal empieza con un contexto nuevo, construido a partir de su archivo de definición y del mensaje de delegación que Claude le escribe. No ve tu conversación, ni los archivos que Claude ya ha leído, ni las skills que ya se han invocado. El fork, en cambio, ve todo eso tal y como estaba en el momento de lanzarse.

La documentación oficial lo resume en esta comparación, que aquí se amplía con las consecuencias prácticas:

Dos detalles que se escapan con facilidad. Primero, el fork no admite el parámetro effort por invocación que sí pueden recibir los subagentes no fork, según la referencia de subagentes. Segundo, si quieres que una tarea secundaria corra con un modelo más barato, un fork no te sirve: siempre usa el modelo de la sesión.

Cuatro cosas distintas que se llaman "fork"

Antes de decidir nada, separa los nombres, porque Claude Code usa la palabra "fork" para mecanismos con comportamientos opuestos. Confundirlos es la forma más rápida de escribir una skill que no funciona.

La trampa más común es la segunda fila. La propia documentación de skills avisa de que, pese al nombre, una skill con context: fork no ve tu historial, así que sus instrucciones tienen que ser autosuficientes. Si la tarea depende de lo que habéis hablado, lo que necesitas es un fork de la conversación. El comportamiento de /fork también depende de la vista de agentes: con agent view desactivado, /fork lanza un fork subagent y /subtask deja de estar disponible.

Por qué un fork arranca barato y puede acabar saliendo caro

Un fork es barato al empezar y caro si dura muchos turnos. El motivo está en cómo funciona la caché de prompt. La API cachea por coincidencia exacta del prefijo de cada petición. Como el fork tiene un system prompt, unas herramientas y un historial idénticos a los de la sesión principal, su primera petición lee la caché del padre. Un subagente nuevo, en cambio, tiene otro prefijo y tiene que escribir su propia caché.

Los multiplicadores publicados en la documentación de prompt caching son estos: escribir en caché con TTL de 5 minutos cuesta 1,25 veces el precio base de input, y leer de caché, 0,1 veces. En Opus 5.5 y Sonnet 5.5 la lectura baja a 0,05 veces. El problema es que ese prefijo heredado no se paga una sola vez. Cada turno del fork vuelve a enviar toda la conversación del padre más lo que el fork haya añadido.

Supongamos una sesión en Sonnet 5.5 con 100.000 tokens de historial. Este cálculo es simplificado e hipotético, no una medición, y expresa el coste en "tokens de input equivalentes":

• Fork: cada turno lee al menos 100.000 tokens de caché a 0,05x, unos 5.000 equivalentes por turno.
• Subagente nuevo: si su contexto ronda los 20.000 tokens (system prompt, CLAUDE.md, delegación y los archivos que vuelve a leer), escribir esa caché cuesta unos 25.000 equivalentes, y después cada turno lee unos 20.000 a 0,05x, unos 1.000 equivalentes.

Con estas cifras, el fork sale más barato en tareas de pocos turnos y el subagente nuevo empieza a compensar a partir de unos seis turnos. Tómalo como referencia práctica, no como dato: la cifra exacta depende de cuánto crezca cada contexto. Ten en cuenta también que los forks caen en el grupo de peticiones que, por defecto, usan TTL de 5 minutos incluso con suscripción. Si usas suscripción en lugar de API key, no ves estos números en una factura, pero sí en lo rápido que consumes tu límite de uso.

El coste que no sale en tokens: independencia y deshacer

Un fork hereda también tus errores. Si la conversación principal ha dado por buena una hipótesis falsa, por ejemplo que un test falla por una condición de carrera, el fork parte de esa misma creencia. Para tareas que continúan tu línea de trabajo, eso es justo lo que quieres. Para una revisión o una segunda opinión, es lo contrario: un subagente limpio, con un prompt que describa el cambio sin tus conclusiones, revisa con más independencia.

El segundo coste está en /rewind. Según la documentación de checkpointing, las ediciones de un subagente que no sea una skill forkeada en primer plano no quedan capturadas en tus checkpoints. Al rebobinar solo se restauran los archivos que Claude ya había editado en tu conversación, y el resto de cambios del subagente se queda en disco. Un fork en background entra en esa categoría. La documentación indica que, al lanzar un fork con la herramienta Agent, Claude puede pasar isolation: "worktree" para que sus ediciones se escriban en un worktree de git separado. Si el fork va a tocar archivos, pide explícitamente ese aislamiento o, como mínimo, haz commit antes.

Árbol de decisión para delegar con o sin fork

Con el mecanismo claro, la decisión se reduce a pocas preguntas. Úsalo tal cual o pégalo en tu CLAUDE.md como criterio de delegación:

¿La tarea necesita lo que se ha hablado en esta sesión?
├─ No → subagente nuevo (o skill con context: fork)
└─ Sí
   ├─ ¿Buscas una opinión independiente (review, auditoría)?
   │   └─ Sí → subagente nuevo con un prompt neutral
   ├─ ¿Quieres un modelo o un effort distinto al de la sesión?
   │   └─ Sí → subagente nuevo con model en su definición
   ├─ ¿Durará muchos turnos y la sesión ya es larga?
   │   └─ Sí → subagente nuevo, o /compact antes de delegar
   └─ En otro caso → fork (/subtask ...)
       └─ ¿Edita archivos? → worktree o commit previo

Los casos donde el fork encaja sin discusión son tareas cortas que dependen del estado de la sesión. Por ejemplo, redactar los tests de los cambios que acabas de hacer mientras sigues implementando, que es el ejemplo de la documentación:

/subtask draft unit tests for the parser changes so far

Otro caso es probar dos enfoques en paralelo desde el mismo punto de partida. Al principio de una sesión, con poco historial, el fork no aporta nada frente a un subagente nuevo, porque apenas hay contexto que reaprovechar.

Cómo limitar o desactivar los forks

Tienes dos niveles de control, según la sección Turn fork mode off de la documentación. El primero impide que Claude lance forks por su cuenta, pero mantiene el resto del comportamiento. Para eso, añade una regla de denegación en tu settings.json:

{
  "permissions": {
    "deny": ["Agent(fork)"]
  }
}

El segundo apaga el modo fork por completo con una variable de entorno. Después tienes que relanzar claude o abrir una conversación nueva en VS Code:

{
  "env": {
    "CLAUDE_CODE_FORK_SUBAGENT": "0"
  }
}

Apagarlo tiene un efecto secundario que conviene conocer. Mientras el modo fork está activo, en las sesiones interactivas de terminal, VS Code y escritorio Claude no puede esperar a un subagente: los subagentes que lanza desde la conversación principal arrancan en background. Si tu flujo necesita que Claude espere el resultado antes de seguir, desactivar el modo fork es la vía documentada. Aunque lo desactives, /subtask sigue funcionando, así que conservas los forks manuales.

En scripts con claude -p o con el Agent SDK, la 2.1.302 cambió el valor por defecto. Si un pipeline dependía de que cada delegación partiera de un contexto limpio y con el modelo de su definición, fija CLAUDE_CODE_FORK_SUBAGENT=0 en el entorno de ejecución para que el comportamiento no dependa de la versión instalada.

Preguntas frecuentes

¿Un fork ve los mensajes que envío después de lanzarlo?

No. Hereda la conversación tal y como estaba al lanzarse. Para darle instrucciones nuevas, selecciona su fila en el panel con las flechas, ábrela con Enter y escríbele desde su transcripción.

¿Un fork puede delegar a su vez en otros subagentes?

No puede lanzar más forks. En el límite de profundidad conserva la herramienta Agent en su lista heredada, pero según la documentación esa herramienta devuelve un error en lugar de crear un subagente.

¿Desactivar los forks rompe mis skills con context: fork?

No. Esas skills lanzan un subagente nuevo del tipo indicado en agent y no dependen del modo fork. Sí conviene revisar su modo de ejecución: en background usan el conjunto reducido de herramientas de los subagentes en segundo plano, y con background: false conservan el conjunto completo.