Subagentes Forked no Claude Code: Por Que Deixei de Usar os Convencionais

Subagentes Forked no Claude Code: Por Que Deixei de Usar os Convencionais

Eram 1h47 da manhã quando percebi que estava depurando o problema errado havia quatro horas.

Eu estava no meio de uma longa sessão no Claude Code — provavelmente já com uns 180 mil tokens — integrando um fluxo de pagamento para o SaaS de um cliente. Invoquei um subagente normal para revisar um controller específico e me dizer se a lógica de validação realmente estava garantindo o que eu esperava. O subagente respondeu com confiança: “Parece correto. O guard no linha 47 previne a condição de corrida que você descreveu”.

Exceto que não era verdade. O guard que estava me preocupando nem sequer estava no controller. Ele estava num middleware que o subagente nunca viu, porque o resumo de contexto comprimido acabou reduzindo esse middleware a uma linha parecida com: “project usa stack padrão de middlewares do Laravel”. A sutileza — o middleware customizado que realmente importava — foi perdida no processo de compressão.

Foi aí que comecei a prestar atenção nos subagentes forked no Claude Code. E depois de duas semanas reestruturando a forma como delego tarefas em sessões longas, não pretendo voltar atrás.

Este post é o que eu gostaria que alguém tivesse me entregue no primeiro dia em que habilitei o /fork. Não é o press release. É o que de fato aconteceu quando testei no trabalho real com clientes, onde o custo da compressão machuca e onde até subagentes forked ainda cometem erros.

O Imposto da Compressão Que Ninguém Comenta

Aqui está o problema com os subagentes normais no Claude Code. Eles não herdam sua conversa. Eles herdam um resumo da sua conversa — a compressão de contexto nativa da Anthropic, aplicada a tudo o que você disse até então, reduzido a algo pequeno o suficiente para caber na janela de contexto do subagente junto com a tarefa dele.

Essa compressão perde dados. Sempre. Precisa ser assim.

O modelo mental que eu carregava estava errado. Eu achava que um subagente era como um colega a quem eu pudesse mandar uma mensagem rápida: “Oi, só um minuto, aqui está no que temos trabalhado, dá uma olhada nisso.” Mas, na prática, era mais como entregar a esse colega um resumo executivo de uma página de uma reunião de três horas e pedir para ele opinar em uma decisão que dependia de um comentário específico feito no minuto 47.

O resumo preserva a estrutura. Os detalhes se perdem. E para trabalho com código, os detalhes são tudo.

Você pode ver isso nas issues do GitHub mantidas pela equipe da Anthropic. Há um pedido ativo — issue #6825 — solicitando herança configurável do prompt do sistema e da memória para subagentes, justamente porque o comportamento padrão de herança é, dependendo da situação, exagerado ou insuficiente. E uma preocupação paralela aparece na issue #4908 sobre passagem de contexto com escopo, que basicamente trata do mesmo problema sob outro ângulo: desenvolvedores querem controlar o que o subagente realmente enxerga.

É aí que mora a tensão: uma janela de contexto completa degrada a qualidade das decisões do Claude Code ao longo do tempo — a precisão cai após cerca de 200k tokens nos meus próprios testes, e a própria Anthropic, em sua documentação de gerenciamento de contexto para a janela de 1M, reconhece esse abismo. Ou seja, a sessão principal quer permanecer enxuta. Mas o subagente, privado de contexto, toma decisões ruins. A compressão é o meio-termo, e todo meio-termo tem seu preço.

Os subagentes forked rompem esse impasse. Eles herdam todo o histórico da conversa da sessão principal, byte a byte, e compartilham o prompt-cache com essa sessão, assim você não paga o preço cheio nos tokens. Essa é a proposta. A pergunta, que passei duas semanas investigando: ela realmente se sustenta?

O Que o /fork Realmente Faz (E Por Que é Diferente)

O comando /fork gera um subagente que inicia já com todo o histórico de conversa carregado na janela de contexto. Não é um resumo. Não é um esboço comprimido. São as mensagens reais, as chamadas de ferramenta reais, as leituras reais de arquivos — tudo o que você acumulou até o ponto em que executou o fork.

Crucialmente, o fork compartilha o prompt cache com a sessão principal. Isso é mais relevante do que parece. Sem esse cache compartilhado, um subagente criado via fork seria proibitivamente caro — você pagaria duas vezes pelos mesmos tokens herdados, uma na sessão principal e outra no fork. O artigo de engenharia de contexto da Anthropic sobre o LMCache reportou uma taxa de reutilização de prompts de 92% nas fases do Claude Code, e para loops de subagente no estilo ReAct é ainda maior. Os forks dependem amplamente dessa reutilização.

O perfil de custo, na prática, fica assim: se sua sessão principal está com 180 mil tokens e você faz um fork, o fork começa também com 180 mil tokens. Mas, como esses tokens já estão em cache, o preço efetivo se aproxima das taxas de leitura do cache — cerca de 10% do preço normal de input nos planos Sonnet. Ou seja, um fork que normalmente custaria o equivalente a um prompt de 180 mil tokens acaba custando muito mais próximo de um prompt de 18 mil tokens no primeiro turno, e a partir daí se comporta como uma conversa normal.

É esse detalhe que muda toda a lógica de quando vale a pena delegar uma tarefa.

Há um ponto sutil, porém importante, na arquitetura dessa funcionalidade. Uma otimização recente nos internos do /fork faz com que seja gravado um ponteiro, em vez de toda a conversa-mãe, no disco para cada fork, com hidratação na leitura. É um detalhe de infraestrutura, não visível para o usuário final, mas é por isso que hoje você pode criar múltiplos forks sem lotar o disco. O recurso já possui maturidade de produção, não é mais apenas experimental.

Para ativar subagentes forked em builds externos, defina a variável de ambiente CLAUDE_CODE_FORK_SUBAGENT=1 ou habilite a flag correspondente no seu settings.json. Uma vez ativado, o /fork fica disponível como comando de barra em qualquer sessão, e você pode interagir diretamente com o fork criado para prompts subsequentes, sem precisar retornar ao thread principal.

O Primeiro Fork em que Realmente Confiei

Sendo honesto — não confiei no /fork logo de cara. Já tinha me decepcionado demais com recursos que pareciam perfeitos na landing page e desmoronavam no código real de cliente, então meu padrão é o ceticismo.

Veja o que me fez mudar de ideia.

Eu estava trabalhando em um projeto de design system — um dashboard com um board Kanban, uma visualização de calendário e um painel de configurações, todos precisando compartilhar uma linguagem visual consistente. Já estava com cerca de 140 mil tokens em uma sessão, na qual já tinha decidido uma dúzia de componentes, definido o sistema de cores, escolhido um escala de tipografia e escrito três componentes. Precisava criar duas variações do cartão Kanban — uma mais compacta, outra mais espaçosa — para ver qual delas se encaixava melhor no sistema.

Com um subagente normal, teria sido um desastre. O subagente receberia um resumo comprimido do tipo: “projeto usa Tailwind, design system é escuro com acentos roxos, tipografia é Inter.” Isso não é suficiente para gerar variações com aquela sensação de pertencerem ao mesmo sistema. Metade das sutilezas — a escala exata de espaçamentos que eu vinha usando, os tratamentos de sombra específicos, o padrão que eu empregava no tamanho dos ícones — tudo isso teria sumido.

Em vez disso, fiz um fork. Na verdade, dois forks, em paralelo. Um com o prompt: “gere uma variação de cartão Kanban mais densa — mantenha tudo do sistema existente, apenas comprima o espaçamento vertical em cerca de 25% e reduza a escala tipográfica um nível.” O segundo: “gere uma variação de cartão Kanban mais espaçosa — mantenha o sistema, expanda o padding e dê mais respiro ao cartão.”

Ambos os forks retornaram variações que realmente pareciam pertencer ao mesmo design system, porque estavam com o mesmo sistema carregado. Não um resumo — o sistema todo. Os tokens de cor definidos, os padrões de componentes estabelecidos, a lógica de espaçamentos que eu vinha refinando há duas horas. Tudo ali.

Foi ali que eu parei de brigar com o recurso e comecei a usá-lo de verdade.

Onde o Fork Faz Valer a Pena

Duas semanas de uso intenso me deram uma taxonomia prática de onde os subagentes forked realmente importam e onde os subagentes normais ainda são a ferramenta mais adequada. Vou detalhar os padrões que mais valeram a pena.

Paralelização de Trabalho de Design

Esse é o caso de uso que me convenceu. Quando você está tomando decisões visuais ou estruturais que dependem de um sistema já construído na sessão, perder esse sistema por compressão derruba a qualidade do resultado. O fork preserva essa base.

Hoje, rotineiramente crio dois ou três forks em paralelo quando preciso avaliar variações — design de componentes, estruturas de APIs, esquemas de banco de dados, alternativas de copy. Cada fork recebe o contexto completo da sessão, mais um prompt orientando a variação desejada. Comparo as saídas lado a lado. Essa comparação só faz sentido porque todos os forks partiram da mesma fundação.

Consolidação de Memória e Recapitulação

Se você já usou o comando /bytheway do Claude Code ou recursos de consolidação de memória, já trabalhou com subagentes forked — eles rodam nos bastidores. Essas tarefas precisam do contexto completo da conversa para serem úteis. Recapitular a partir de um resumo comprimido vira só um resumo do resumo, o que equivale a uma cópia xerox de uma cópia xerox.

Agora que sei o que acontece nos bastidores, uso esses recursos de maneira mais agressiva. Quando estou prestes a bater no limite de contexto em uma sessão que quero preservar, aciono um /bytheway para consolidar as decisões importantes na memória antes de compactar ou reiniciar.

Verificação Paralela com Múltiplas Ferramentas

Aqui está um padrão que desenvolvi e considero realmente útil. Quando gero um trecho de código substancial, costumo criar dois forks ao mesmo tempo:

1. Fork A: "Gere um diagrama Mermaid mostrando como as alterações no código se propagam pelo ciclo de vida da requisição. Marque em uma cor diferente tudo o que mudou."

2. Fork B: "Faça uma pesquisa na web para verificar se os padrões de API usados nas alterações do código são considerados melhores práticas para [framework] em 2026. Cite qualquer coisa que pareça desatualizada."

Ambos os forks recebem o contexto completo da sessão, então ambos sabem exatamente a qual código estou me referindo. O fork do diagrama me dá uma checagem visual rápida. O fork de verificação pega casos em que minha memória muscular usou um padrão que era comum há três anos, mas já perdeu espaço. Consigo dois pontos de vista independentes sobre a mesma alteração, gerados em paralelo, sem poluir a sessão principal com nenhuma dessas tarefas.

Conter Tangentes

Este é mais sutil, mas faz muita diferença para a produtividade. Às vezes tenho uma dúvida paralela interessante, mas fora de tópico. "Espera — se tivéssemos usado outro padrão de ORM aqui, todo esse fluxo seria mais simples?" Normalmente, esse tipo de tangente ou descarrila minha thread principal por vinte minutos ou se perde porque prefiro não sair do foco.

Os subagentes forked permitem uma resposta limpa. Forko, faço a pergunta tangente, exploro o contrafactual. Se a resposta vale, levo o insight para a sessão principal. Se for um beco sem saída, uso /rewind e o fork desaparece. A conversa principal nunca soube que aquilo aconteceu.

Isso muda meu comportamento ao usar o Claude Code, não é só uma funcionalidade. Passo a explorar mais dúvidas paralelas porque o custo da exploração caiu de "potencial desvio" para "tangente gratuita, descarte se for inútil".

Quando o Fork Não É a Escolha Certa

O fork nem sempre é a melhor opção. Existe uma armadilha real em supor que mais contexto é sempre melhor, e eu caí nela na segunda semana usando o recurso.

A armadilha é o viés. Um subagente forkado viu tudo o que você fez na sessão — incluindo o código que acabou de escrever, as escolhas de arquitetura que tomou, as bibliotecas que selecionou. Quando você pede para um fork revisar esse código, não está recebendo um olhar novo. Está recebendo os seus próprios olhos, apenas rodando como um processo separado. O fork se lembra por que você tomou cada decisão, e o viés de confirmação se infiltra.

Para revisões de código, isso faz diferença. Uma boa revisão de código identifica aquilo em que você não pensou, o que significa que precisa vir de uma mente que não esteve pensando da mesma forma que você.

Eu testei isso diretamente. Escrevi um lote de código relacionado à autenticação e pedi para um subagente forkado revisar. O fork voltou com sugestões cosméticas — nomes de variáveis, um ajuste em docstring, um pequeno refactor. Depois pedi para um subagente normal (contexto novo, sem histórico) revisar o mesmo código. O subagente normal sinalizou que eu não estava comparando um token em tempo constante corretamente, o que era uma falha real de segurança que o fork ignorou porque, no contexto do fork, o código “parecia razoável dadas as práticas já estabelecidas.”

Essa é a regra prática a que cheguei:

• Fork quando o contexto é um ativo. Consistência de design, consolidação de memória, fluxos de trabalho multi-etapas que precisam de histórico, exploração de tangentes.
• Não use fork quando o contexto é uma responsabilidade. Revisões de código, auditorias de segurança, testes adversariais, qualquer situação em que você precise de uma nova série de premissas.

Os subagentes normais ainda têm seu lugar à mesa. Eles só têm uma função diferente.

A análise: Forked vs Normal

Aqui está a comparação que eu gostaria de ter tido no primeiro dia, resumida de modo que você realmente possa usar quando precisar decidir na hora.

A linha mais importante é a “Melhor para”. Não escolha o /fork só porque é o recurso mais novo. Use-o quando a tarefa realmente se beneficia da continuidade de contexto. Caso contrário, você está pagando um preço em viés sem nenhum ganho real.

Ativando e Usando na Prática

Se você ainda não ativou os subagentes forked, aqui está o caminho mais curto.

Abra o seu settings.json do Claude Code — normalmente em ~/.claude/settings.json para escopo de usuário, ou .claude/settings.json na raiz do seu projeto. Você pode definir a variável de ambiente CLAUDE_CODE_FORK_SUBAGENT=1 no seu perfil do shell, ou adicionar o flag equivalente no seu JSON de configurações. O nome exato da chave já mudou entre versões, então consulte as notas de lançamento atuais do Claude Code caso só a variável de ambiente não ative o recurso.

Com o recurso ativo, o comando /fork fica disponível como barra dentro de qualquer sessão. Digite, insira o seu prompt, e pronto: você criou um fork. Dá para direcionar mensagens para o fork usando prefixo, e usar /rewind para descartar forks que não deram certo.

Algumas dicas práticas depois de duas semanas usando isso:

Faça fork de forma intencional, não por reflexo. Na primeira semana, eu fazia fork para tudo. Estava errado. Cada fork embute um viés implícito em tarefas de revisão e adiciona sobrecarga mental, já que agora há dois ou três threads para acompanhar. Hoje, faço fork três ou quatro vezes a cada sessão realmente séria — só em momentos em que a tarefa realmente se beneficia de todo o contexto.

Use forks paralelos para convergência. Se estiver em dúvida diante de uma decisão, crie dois forks com premissas opostas e compare. Fiz isso recentemente ao decidir entre components de servidor ou components de cliente para uma página específica em Next.js. Dois forks, dois argumentos, resultados lado a lado. A resposta ficou óbvia em cinco minutos lendo ambos.

Fique atento ao hábito de usar /rewind. /rewind é a saída de emergência que torna a exploração barata. Se não estiver usando regularmente, provavelmente está fazendo pouco fork para investigar hipóteses. Forks que se tornam becos sem saída devem ser descartados, não lamentados.

Combine forks com subagentes normais para validação adversarial. Quando um fork gera uma solução, envie o mesmo problema para um subagente normal, sem contexto. Se ambos concordam, sua confiança deve aumentar. Se discordam, preste atenção — a divergência é informação valiosa: descubra por que a visão sem contexto percebeu algo que o fork carregado de contexto perdeu.

O Que Eu Errei na Primeira Semana

Quero ser honesto sobre os equívocos, porque o recurso é tão poderoso que é tentador exagerar suas qualidades.

O primeiro erro: eu fiz forks demais. Fiz fork para revisões de código, o que foi uma estupidez. O fork, lembrando de cada trecho de código que eu tinha acabado de escrever, basicamente só carimbava meu próprio trabalho de volta para mim. A palestra do Boris Cherny sobre workflow no Claude Code destaca que contexto fresco muitas vezes é o objetivo principal de um subagente, e eu ignorei esse conselho no começo.

O segundo erro: não percebi o quanto o aquecimento do cache importa. O primeiro fork em uma sessão paga um custo real para armazenar em cache o contexto herdado. Forks subsequentes são baratos. Se você faz apenas um fork para uma tarefa pequena, não está realmente amortizando o cache da forma como o recurso foi projetado. Agrupe seus forks sempre que possível — se você sabe que vai precisar de três explorações paralelas, gere todas próximas uma da outra.

O terceiro erro: fiquei complacente com o tamanho da sessão. Subagentes forkados não resolvem o problema fundamental de que uma sessão principal com 400 mil tokens é uma sessão de pensamento confuso. Eles apenas movem parte do trabalho para fora da sessão principal, distribuindo em forks. Se sua sessão principal está inchada, os forks originados dessa sessão também estarão. Em algum momento, você ainda precisa compactar, criar checkpoints ou começar do zero. Meu artigo anterior sobre gerenciamento de contexto de 1M no Claude Code aprofunda o lado da poda nesse processo.

O recurso não desculpa má higiene de sessão. Ele recompensa boas práticas de sessão, tornando a delegação realmente útil em sessões bem gerenciadas.

O Padrão Que Pegou

De todos os fluxos de trabalho que testei, um deles permaneceu e hoje é automático.

Quando estou imerso em uma build e prestes a tomar uma decisão que parece fundamental — "devo usar essa biblioteca ou criar minha própria?" "essa API deve ser REST ou algo diferente?" "essa arquitetura de componentes se generaliza ou estou me colocando numa sinuca?" — faço dois forks. Dois forks paralelos, cada um assumindo um lado da decisão, ambos instruídos a defender seu ponto de vista com todo o contexto da sessão.

Cinco a dez minutos depois, tenho dois memorandos curtos. Leio ambos. A resposta certa geralmente salta aos olhos, mas, mais importante ainda, o raciocínio normalmente também fica evidente. Não estou apenas recebendo uma recomendação — estou vendo os argumentos de cada opção, avaliados exatamente com base no contexto específico do que já construí.

Isso substituiu um hábito antigo de pedir a um amigo dev para conversar sobre decisões técnicas. O amigo nem sempre estava disponível, não conhecia o contexto do projeto e tinha seus próprios vieses. Os dois forks estão sempre disponíveis, conhecem exatamente o contexto do projeto porque são o contexto do projeto, e seus vieses são transparentes porque fui eu quem escreveu os prompts.

Não é uma mudança pequena. É uma verdadeira transformação na forma como tomo decisões técnicas em projetos solo.

O Teste Que Eu Faria Esta Noite

Se você leu até aqui e ainda não ativou o /fork, aqui está o que eu faria antes de dormir.

Abra as configurações do Claude Code, ative CLAUDE_CODE_FORK_SUBAGENT=1 e reinicie a sessão. Escolha um projeto em que você já trabalhou algumas horas hoje — algo que esteja além dos 80k tokens de contexto. Pense em uma pergunta incômoda sobre esse projeto, algo que você não respondeu porque parecia uma tangente grande demais.

Digite /fork, faça a pergunta e veja o que volta.

Depois, compare o que você recebeu com o que teria conseguido de um subagente normal — na verdade, você pode rodar o mesmo prompt usando um subagente normal em seguida e comparar lado a lado. Veja o que o fork capturou que o subagente normal deixou passar. Note em que situações a perspectiva “fresca” do subagente normal foi mais útil do que o recall total do fork.

Depois do segundo ou terceiro fork, você já vai ter uma noção de quando o recurso realmente vale a pena e quando não. Essa intuição é o que você está de fato desenvolvendo. O comando é simples. O discernimento sobre quando usar é o verdadeiro diferencial.

Vamos Trabalhar Juntos

Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (projetos sob medida & integrações): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io