Subagentes Forked en Claude Code: Por Qué Dejé de Usar los Normales

Subagentes Forked en Claude Code: Por Qué Dejé de Usar los Normales

Eran las 1:47 AM cuando me di cuenta de que había estado depurando el problema equivocado durante cuatro horas.

Estaba metido hasta el fondo en una larga sesión de Claude Code — tal vez con 180.000 tokens — implementando un flujo de pagos para el SaaS de un cliente. Inicié un subagente normal para que revisara un controlador específico y me dijera si mi lógica de validación realmente aplicaba lo que yo pensaba. El subagente respondió con total confianza. “Parece correcto. El guard en la línea 47 evita la condición de carrera que describiste.”

Excepto que no era así. El guard que me preocupaba ni siquiera estaba en el controlador. Estaba en un middleware que el subagente jamás había visto, porque su resumen comprimido del contexto había reducido ese middleware a una línea que decía, más o menos, “el proyecto usa la pila estándar de middleware de Laravel.” El matiz —el middleware personalizado que realmente importaba— se perdió durante la compresión.

Fue entonces cuando comencé a prestar atención a los subagentes bifurcados en Claude Code. Y después de dos semanas reestructurando cómo delego tareas en sesiones largas, no pienso volver atrás.

Esta publicación es lo que me habría gustado que alguien me diera el primer día que activé /fork. No es un comunicado de prensa. Es lo que realmente sucedió cuando lo probé en trabajo real de cliente, donde el costo de compresión duele y donde incluso los subagentes bifurcados a veces fallan.

El impuesto de compresión del que nadie habla

Aquí está el asunto con los subagentes normales en Claude Code. No heredan tu conversación. Heredan un resumen de tu conversación: la compresión de contexto incorporada de Anthropic que procesa todo lo que has dicho hasta el momento, condensándolo en algo lo suficientemente pequeño como para caber en la ventana de contexto propia del subagente junto con su tarea.

Esa compresión siempre es con pérdida. Siempre. Es inevitable.

El modelo mental que yo tenía estaba equivocado. Pensaba que un subagente era como un colega a quien puedes enviar un mensaje por Slack: “oye, cosa rápida, esto es en lo que hemos estado trabajando, échale un vistazo a esto”. Pero lo que realmente estaba haciendo era más parecido a entregarle a un colega un resumen ejecutivo de una página sobre una reunión de tres horas y pedirle que opine sobre una decisión que depende de un comentario específico que alguien hizo en el minuto 47.

El resumen captura la forma general. Pierde los detalles. Y en el trabajo con código, los detalles lo son todo.

Puedes verlo en los issues de GitHub que mantiene el equipo de Anthropic. Hay una solicitud activa — issue #6825 — pidiendo una herencia configurable del prompt del sistema y la memoria para subagentes, precisamente porque el comportamiento de herencia predeterminado es demasiado o demasiado poco según lo que estés haciendo. Y existe una inquietud paralela en issue #4908 sobre el paso de contexto acotado, que en realidad es el mismo problema visto desde otro ángulo: los desarrolladores quieren controlar lo que el subagente ve realmente.

La tensión está aquí: una ventana de contexto completa degrada la calidad de las decisiones de Claude Code con el tiempo — la precisión cae a partir de unos 200.000 tokens según mis pruebas, y la propia documentación de manejo de contexto para la ventana de 1M de Anthropic reconoce ese descenso. Por eso la sesión principal quiere mantenerse ligera. Pero al subagente, hambriento de contexto, se le escapan detalles críticos. La compresión es el compromiso, y todo compromiso tiene un precio.

Los subagentes bifurcados rompen esa dicotomía. Heredan todo el historial de conversaciones de la sesión principal, byte por byte, y además comparten la caché de prompts con esa sesión para que no tengas que pagar el precio completo por los tokens. Esa es la propuesta. La pregunta en la que pasé dos semanas trabajando: ¿se sostiene realmente?

Qué Hace Realmente /fork (Y Por Qué Es Diferente)

El comando /fork crea un subagente que comienza con todo tu historial de conversación cargado en su ventana de contexto. No es un resumen. No es un esquema comprimido. Son los mensajes reales, las llamadas a herramientas, las lecturas de archivos — todo lo que has acumulado hasta el momento en que realizas el fork.

Crucialmente, el fork comparte la caché de prompts con la sesión principal. Esto es más importante de lo que parece. Sin caché compartida, un subagente bifurcado sería prohibitivamente caro: pagarías por los mismos tokens heredados dos veces, una en la sesión principal y otra en el fork. En el informe de ingeniería de contexto de Anthropic sobre LMCache, se sitúa la tasa de reutilización de prompts en distintas fases de Claude Code en un 92 %, y para bucles de subagentes estilo ReAct incluso es más alta. El forking depende en gran medida de esa reutilización.

El perfil de coste práctico se muestra así. Si tu sesión principal lleva acumulados 180k tokens y haces un fork, el fork se inicia con esos mismos 180k tokens. Pero, como esos tokens ya están cacheados, el precio efectivo se acerca al de una lectura de caché: alrededor del 10 % del precio normal de entrada en niveles Sonnet. Así, un fork que nominalmente te costaría como una prompt de 180k tokens, realmente te cuesta mucho más cerca de una de 18k tokens en el primer turno, y a partir de ahí se comporta como una conversación normal.

Eso es lo que cambia las cuentas sobre cuándo delegar.

Hay un detalle sutil pero importante en su desarrollo. Una optimización reciente en los internos de /fork escribe un puntero, en vez de toda la conversación padre, al disco por cada fork, con hidratación al leer. Es fontanería, no visible para los usuarios, pero es la razón por la que puedes crear múltiples forks sin llenar el disco. Ahora la funcionalidad está con forma de producción, no como experimento.

Para habilitar subagentes bifurcados en versiones externas, debes establecer la variable de entorno CLAUDE_CODE_FORK_SUBAGENT=1 o activar la bandera equivalente en tu settings.json. Una vez habilitado, /fork está disponible como comando slash en cualquier sesión, y puedes dirigirte directamente al fork generado para prompts de seguimiento sin volver al hilo principal.

El Primer Fork en el Que Realmente Confié

Seré honesto: no confié en /fork desde el primer día. Ya me habían decepcionado demasiadas veces funciones que lucían impecables en la landing page y se desmoronaban al enfrentarse a código real de clientes, así que mi postura por defecto es el escepticismo.

Esto fue lo que me hizo cambiar de opinión.

Estaba trabajando en un proyecto de sistema de diseño: un dashboard con un tablero Kanban, una vista de calendario y un panel de ajustes, todo necesitando compartir un lenguaje visual coherente. Llevaba unas 140k tokens en una sesión en la que ya había tomado una docena de decisiones sobre componentes, establecido un sistema de colores, elegido una escala tipográfica y escrito tres componentes. Necesitaba generar dos variaciones de diseño de la tarjeta Kanban — una más densa y otra más espaciosa — para ver cuál encajaba mejor con el resto del sistema.

Con un subagente normal, esto habría sido un desastre. El subagente habría recibido un resumen comprimido que diría algo como "el proyecto usa Tailwind, el sistema de diseño es oscuro con acentos púrpura, la tipografía es Inter". Eso no es suficiente para generar variaciones que realmente parezcan formar parte del mismo sistema. Se habría perdido la mitad de los matices: la escala exacta de espaciado que había estado usando, los tratamientos específicos de sombras, la forma en la que venía gestionando el tamaño de los íconos… todo eso se habría esfumado.

En cambio, hice un fork. De hecho, dos forks, en paralelo. Uno con el prompt “genera una variación densa de la tarjeta Kanban — mantén todo igual en el sistema existente, solo comprime el espaciado vertical en un ~25% y ajusta la escala tipográfica un nivel hacia abajo”. El segundo con “genera una variación más espaciosa de la tarjeta Kanban — conserva el sistema, expande el padding y dale más aire a la tarjeta”.

Ambos forks devolvieron variaciones que realmente parecían pertenecer al mismo sistema de diseño, porque tenían el mismo sistema de diseño cargado. No un resumen. El sistema completo. Los tokens de color que ya había definido, los patrones de componentes que había establecido, la lógica de espaciado que había estado refinando durante dos horas. Todo estaba ahí.

Ese fue el momento en el que dejé de cuestionar la función y empecé a usarla.

Donde el Forking Demuestra su Valor

Dos semanas de uso intensivo me han permitido trazar una clasificación aproximada de cuándo los subagentes forked realmente marcan la diferencia y cuándo los subagentes normales siguen siendo la herramienta adecuada. Permíteme repasar los patrones que más resultados me han dado.

Paralelización de Trabajo de Diseño

Este es el caso de uso que me convenció. Cuando estás tomando decisiones visuales o estructurales que dependen de un sistema que ya has construido en la sesión, perder ese sistema por compresión mata la calidad del resultado. Forkear lo preserva.

Ahora, de forma rutinaria, lanzo dos o tres forks en paralelo cuando necesito evaluar variantes — diseños de componentes, estructuras de APIs, esquemas de bases de datos, alternativas de copy. Cada fork recibe el contexto completo más un prompt de variación concreto. Comparo las salidas lado a lado. La comparación solo tiene sentido porque los tres forks partieron exactamente de la misma base.

Consolidación de Memoria y Recapitulación

Si has usado el comando /bytheway de Claude Code o las funciones de consolidación de memoria, ya has utilizado subagentes forked — se ejecutan en segundo plano. Estas tareas necesitan la conversación completa para ser útiles. Un resumen generado a partir de un compendio comprimido es solo un resumen de un resumen, que en contenido equivale a una fotocopia de una fotocopia.

Ahora que sé lo que ocurre bajo el capó, uso estas funciones de forma mucho más agresiva. Cuando estoy a punto de alcanzar un límite de contexto en una sesión que quiero preservar, lanzo un /bytheway para consolidar las decisiones importantes en la memoria antes de compactar o reiniciar.

Verificación Paralela Multiherramienta

Aquí tienes un patrón que he perfeccionado y que me resulta realmente útil. Cuando acabo de generar un bloque de código no trivial, lanzo dos forks simultáneamente:

1. Fork A: "Genera un diagrama Mermaid que muestre cómo los cambios de código realizados fluyen por el ciclo de vida de la petición. Marca cualquier cosa que haya cambiado en un color diferente."

2. Fork B: "Haz una búsqueda web para verificar que los patrones de API usados en los cambios de código son la mejor práctica actual para [framework] a fecha de 2026. Cita todo lo que veas obsoleto."

Ambos forks tienen el contexto completo de la sesión, así que ambos saben exactamente a qué código me refiero. El fork del diagrama me da una validación visual. El fork de verificación detecta los casos en que mi memoria muscular escribió un patrón que era idiomático hace tres años pero ya no lo es. Obtengo dos puntos de vista independientes sobre el mismo cambio, generados en paralelo, sin llenar de ruido la sesión principal.

Contención de Tangentes

Esta es menos vistosa, pero esencial para la sanidad mental. A veces tengo una pregunta lateral interesante pero fuera de tema. "Espera — si hubiéramos usado un patrón ORM distinto aquí, ¿todo este flujo sería más simple?" Normalmente ese tipo de tangentes o desvían mi hilo principal durante veinte minutos o se pierden porque no quiero desviarme.

Los subagentes forked te dan una respuesta limpia. Forkeas, lanzas la pregunta tangencial, exploras el contrafactual. Si la respuesta es valiosa, traes el insight a la sesión principal. Si es un callejón sin salida, /rewind y el fork desaparece. La conversación principal nunca supo que ocurrió.

Esto supone un cambio en mi forma de usar Claude Code, no solo una función. Ahora exploro más preguntas secundarias porque el coste de explorar pasó de ser "posible desvío" a "tangente gratuita, deséchala si no sirve".

Cuándo bifurcar es la decisión equivocada

Bifurcar no siempre es lo correcto. Hay una trampa real en asumir que más contexto siempre es mejor, y la descubrí en la segunda semana de usar la funcionalidad.

La trampa es el sesgo. Un subagente bifurcado ha visto todo lo que has hecho en la sesión, incluyendo el código que acabas de escribir, las decisiones de arquitectura que tomaste y las bibliotecas que elegiste. Cuando le pides a un fork que revise ese código, no obtienes una mirada fresca. Obtienes tus propios ojos, solo que corriendo como un proceso aparte. El fork recuerda por qué tomaste cada decisión, y el sesgo de confirmación aparece inevitablemente.

Esto importa especialmente para las revisiones de código. Una buena revisión detecta aquello en lo que no pensaste, lo que significa que debe venir de una mente que no ha estado pensando como tú.

Esto lo probé de manera directa. Escribí un lote de código relacionado con autenticación y pedí a un subagente bifurcado que lo revisara. El fork volvió con sugerencias cosméticas: nombres de variables, un ajuste en el docstring, un pequeño refactor. Luego, pedí a un subagente normal (contexto fresco, sin historial) que revisara el mismo código. El subagente normal detectó que no estaba comparando un token en tiempo constante correctamente, lo que representaba un bug real de seguridad que el fork había pasado por alto porque, en el contexto del fork, el código “parecía razonable dado los patrones establecidos”.

Esa es la regla básica con la que me he quedado:

• Bifurca cuando el contexto sea un activo. Coherencia en el diseño, consolidación de memoria, flujos de trabajo multi-paso que requieren historial, exploración de tangentes.
• No bifurques cuando el contexto sea una carga. Revisiones de código, auditorías de seguridad, pruebas adversarias, cualquier situación donde necesites partir de supuestos renovados.

Los subagentes normales siguen teniendo un lugar en la mesa. Simplemente cumplen otra función.

Desglose: Forked vs Normal

Aquí tienes la comparativa que me habría gustado tener el primer día, comprimida en algo realmente útil para decidir en el momento.

La fila más relevante es la de "Ideal para". No uses /fork solo porque sea la función más reciente. Úsala cuando la tarea realmente se beneficie de la continuidad del contexto. De lo contrario, estarás pagando el precio del sesgo sin obtener ninguna ventaja.

Activar y Usar Forked Subagents

Si aún no has activado los forked subagents, aquí tienes el camino más corto.

Abre el archivo settings.json de Claude Code — normalmente ubicado en ~/.claude/settings.json para el ámbito de usuario, o en .claude/settings.json en la raíz de tu proyecto. Puedes establecer la variable de entorno CLAUDE_CODE_FORK_SUBAGENT=1 en tu perfil de shell, o añadir el flag equivalente en tu settings JSON. El nombre exacto de la clave ha cambiado entre versiones, así que revisa las notas de la última versión de Claude Code si con la variable de entorno no basta.

Una vez activado, /fork está disponible como comando slash en cualquier sesión. Escríbelo, añade tu prompt, y ya tienes un fork. Puedes dirigirte al fork directamente en los siguientes turnos anteponiendo mensajes, y puedes usar /rewind para descartar un fork que no resultó útil.

Algunos consejos operativos tras dos semanas trabajando así:

Haz forks de forma intencional, no impulsiva. La primera semana forkeaba para todo. Fue un error. Forkear implica un sesgo implícito en tareas tipo revisión, y añade sobrecarga mental porque ahora tienes que seguir dos o tres hilos distintos. He acabado usando forks solo tres o cuatro veces por sesión seria — en momentos en que realmente aporta tener todo el contexto.

Usa forks paralelos para converger. Si tienes dudas sobre una decisión, lanza dos forks con supuestos opuestos y compáralos. Hace poco apliqué esto decidiendo si usar server components o client components para una página concreta de Next.js. Dos forks, dos argumentos, salida lado a lado. La respuesta fue evidente tras leer ambos cinco minutos.

Atento al hábito de /rewind. /rewind es la vía de escape que hace barata la exploración. Si no lo usas con regularidad, probablemente no estés forkeando lo suficiente como para explorar. Forks que resulten callejones sin salida deben ser rebobinados, no lamentados.

Haz pruebas adversariales combinando forks y subagentes normales. Tras generar una solución en un fork, envía el mismo problema a un subagente normal, sin contexto. Si coinciden, tu confianza debe aumentar. Si discrepan, esa discrepancia es información útil: investiga por qué la visión nueva detecta algo que el fork saturado de contexto pasó por alto.

Lo que Hice Mal la Primera Semana

Quiero ser honesto sobre los errores, porque la función es lo suficientemente potente como para que sea tentador exagerar sus beneficios.

El primer error: forkeé demasiado. Forkeé para revisiones de código, lo cual fue una tontería. El fork, al recordar cada fragmento de código que acababa de escribir, básicamente solo estaba validando mi trabajo sin un análisis real. La charla de Boris Cherny sobre el flujo de trabajo de Claude Code enfatiza que aportar un contexto fresco es, a veces, el sentido principal de un subagente, y yo ignoré ese consejo al empezar.

El segundo error: no me di cuenta de cuánto importa calentar el caché. El primer fork en una sesión conlleva un coste real al almacenar en caché el contexto heredado. Los siguientes forks son mucho más baratos. Si haces un solo fork para una tarea pequeña, realmente no estás amortizando el caché como la función está pensada. Agrupa tus forks cuando sea posible; si sabes que vas a necesitar tres exploraciones paralelas, lánzalas casi al mismo tiempo.

El tercer error: me acomodé respecto a la longitud de la sesión. Los subagentes forkeados no resuelven el problema fundamental de que una sesión principal de 400k tokens tiende a generar razonamientos difusos. Simplemente trasladan parte del trabajo fuera de la sesión principal hacia los forks. Si tu sesión principal está saturada, los forks derivados también estarán sobrecargados. En algún punto igual tendrás que compactar, crear un punto de control o comenzar desde cero. Mi anterior análisis sobre la gestión de contexto de 1M en Claude Code profundiza mucho más en el lado de la poda.

La funcionalidad no es una excusa para una mala higiene de sesiones. De hecho, premia la buena gestión de sesiones al hacer que la delegación sea realmente útil dentro de sesiones bien organizadas.

El patrón que se quedó

De todos los flujos de trabajo que probé, hay uno que se ha quedado y ahora hago de forma instintiva.

Cuando estoy metido de lleno en una construcción y por tomar una decisión que se siente fundamental — "¿debo usar esta librería o crear la mía?" "¿esta API debe ser REST u otra cosa?" "¿esta arquitectura de componentes es generalizable o me estoy encerrando en un rincón?" — hago un fork doble. Dos forks paralelos, cada uno adoptando un lado de la decisión, y a cada uno le pido que argumente su caso con todo el contexto de la sesión.

Cinco a diez minutos después tengo dos memorandos cortos. Leo ambos. La respuesta correcta suele ser evidente para ese momento, y lo más importante, el razonamiento suele ser evidente. No solo obtengo una recomendación — obtengo la justificación de cada opción, evaluada en el contexto específico de lo que ya he construido.

Esto ha reemplazado el hábito que tenía de escribirle a un amigo desarrollador para discutir decisiones. El amigo a veces no estaba disponible, no conocía el contexto del proyecto y tenía sus propios sesgos. Los dos forks siempre están disponibles, conocen exactamente el contexto del proyecto porque son el contexto del proyecto, y sus sesgos son transparentes porque yo escribí los prompts.

Eso no es un cambio menor. Es un cambio real en la forma en que tomo decisiones técnicas en proyectos en solitario.

La prueba que haría esta noche

Si has llegado hasta aquí y aún no has activado /fork, esto es lo que haría antes de acostarme.

Abre la configuración de Claude Code, activa CLAUDE_CODE_FORK_SUBAGENT=1 y reinicia la sesión. Elige un proyecto en el que hayas estado trabajando durante algunas horas hoy — uno que ya tenga más de 80k tokens de contexto. Piensa en una pregunta que te haya estado rondando sobre ese proyecto, algo que no has resuelto porque sentías que era una desviación demasiado grande.

Escribe /fork, haz la pregunta y observa lo que devuelve.

Luego compara lo que obtuviste con lo que habrías conseguido usando un subagente normal — de hecho, puedes ejecutar el mismo prompt con un subagente normal después y comparar los resultados lado a lado. Fíjate en lo que el fork detectó y el subagente normal pasó por alto. Observa cuándo la perspectiva fresca del subagente normal resultó más útil que la memoria completa del fork.

Para el segundo o tercer fork, ya tendrás una idea de cuándo esta función realmente merece la pena y cuándo no. Ese instinto es lo que en realidad estás desarrollando. El comando es fácil. El juicio sobre cuándo usarlo es la verdadera habilidad.

Colaboremos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
• Portafolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io