Eu era o /clear do meu agente

Por alguns dias, o que eu mais fiz no Forge foi digitar duas coisas: /clear e /forge-resume.

O Forge é a infraestrutura que eu montei em cima do Claude Code para gerar projetos a partir de um brief. Um agente entende o pedido, outro desenha a arquitetura, outro escreve a spec. Depois um orquestrador puxa as tasks uma a uma: subagentes implementam, três rodadas de review aprovam, e só então a task é marcada como feita. Funciona bem. O chato é que, a cada tantas tasks, o orquestrador parava e me pedia para limpar a conversa e mandar ele continuar.

Eu obedecia. Num projeto de 75 tasks, isso dá de 15 a 25 paradas. Nenhuma delas decide nada. Eu era o botão de reiniciar.

Um dia cansei e pedi, com estas palavras: “cria uma maneira de ser automatizado, apenas me peça caso necessite de alguma dúvida”. Parece trivial. Não é: o agente não tem como apagar a própria memória, e essa limitação decide o desenho de todo o resto.

Uma janela grande demais para dar alarme

Primeiro, por que ele parava.

No dia 23 de setembro eu medi 33 sessões reais do orquestrador. Cada turno carregava entre 230 mil e 350 mil tokens de contexto, com pico de 558 mil. As sessões passavam de centenas de turnos. E nenhuma compactação.

A janela do modelo é de 1 milhão de tokens, então o auto-compact do Claude Code nunca chegava perto de disparar. Visto de fora, estava tudo bem. Por dentro, cada turno relia e regravava centenas de milhares de tokens de histórico, e a conta vinha junto.

E custo nem é o pior. Contexto longo piora a resposta. A Chroma testou 18 modelos de ponta e concluiu que o desempenho fica “cada vez menos confiável conforme o input cresce” (Context Rot). No NoLiMa, apresentado no ICML 2025, 11 de 13 modelos caem abaixo da metade do próprio desempenho em texto curto quando o contexto chega a 32 mil tokens. Um estudo de 2023 já tinha mostrado que o que fica no meio de um contexto longo é lembrado pior do que o que está no começo ou no fim (Lost in the Middle). A própria Anthropic escreve que contexto deve ser tratado como “um recurso finito, com retorno marginal decrescente”.

A correção veio no mesmo dia. Todo o estado de um projeto Forge já mora em disco: brief, design, spec, lista de tasks, histórico do git. Então o orquestrador passou a gravar um bilhete de passagem de até 30 linhas, o handoff.md, e a encerrar a janela em pontos fixos: depois do design, depois da spec e a cada cinco tasks. Um hook mede o tamanho real da conversa a cada ferramenta chamada e avisa quando passa de 150 mil tokens. As janelas passaram a nascer com uns 43 mil e a morrer antes de degradar.

Resolveu o custo e a qualidade. E me promoveu a reiniciador oficial.

Por que o agente não se limpa sozinho

A pergunta óbvia: se o orquestrador sabe a hora de parar, por que ele mesmo não limpa a conversa?

Porque não consegue. /clear é um comando do CLI, digitado por gente, e não uma ferramenta que o modelo possa chamar. Nenhum hook, tool ou subagente zera a conversa em andamento. O modelo só consegue acrescentar tokens à própria janela. Tirar, nunca.

As saídas que parecem resolver isso de dentro falham, cada uma por um motivo:

• Compactar (/compact ou o auto-compact) resume a conversa em vez de descartá-la. O resumo é escrito pelo próprio modelo e perde coisa no caminho. E o limiar de disparo, que eu poderia baixar, vale também para os subagentes, que têm janela menor e compactariam cedo demais.
• Subagentes eu já uso. Quem implementa, revisa e verifica roda isolado e devolve só um resumo. Mas o orquestrador que chama todos eles continua acumulando cada resumo, cada leitura da lista de tasks, cada saída de teste. É ele que chega aos 300 mil.
• Um fork da sessão herda o contexto inteiro. É o contrário do que eu queria.

Sobra uma única janela limpa de verdade: um processo novo. Isso empurra a solução para fora da sessão. Alguém precisa ver um processo terminar e iniciar o próximo. Esse alguém era eu. Agora é um script.

Um script burro de propósito

O forge-loop é um script bash que roda num terminal comum, fora do Claude Code. Nasceu com 260 linhas e hoje passa de 400; quase tudo que entrou depois serve para ele parar melhor. A cada volta ele faz a mesma coisa:

1. Confere o disco. Árvore do git suja é decisão minha (commit ou stash), então ele me chama direto, sem gastar a volta.
2. Sobe um processo novo do Claude Code em modo não interativo, com /forge-resume --autopilot e um teto de gasto por janela.
3. Mostra o progresso numa linha por ação (qual subagente, qual comando, qual arquivo) e guarda o log fora do repositório.
4. Quando o processo termina, lê as três primeiras linhas do bilhete de passagem, o último commit e quantas tasks foram marcadas como feitas.
5. Decide se relança, se para ou se me chama.

Essas três linhas são o contrato inteiro entre os dois lados:

STATUS: CHECKPOINT | AGUARDA-HUMANO | CONCLUIDO | BLOQUEADO
PROXIMO: TASK-040 (Tela inicial) → TASK-041 → …
PERGUNTA: <uma linha, só quando precisa de mim>

O script não interpreta o que o modelo escreveu, não mexe na lista de tasks, não commita e não decide o que exige um humano. Isso continua sendo trabalho do orquestrador. O script lê três linhas e o git, e só.

Ele para sozinho quando o projeto termina, quando o orquestrador pede um humano, quando o gasto acumulado bate US$ 150 ou quando a execução chega a 40 janelas. E para quando desconfia de travamento: duas voltas seguidas sem commit de código nem task nova, ou três seguidas mexendo em código sem fechar task nenhuma. Commit que só atualiza o bilhete ou a memória do agente não conta como avanço. Cada janela ainda tem um relógio de três horas. Estourou, o processo é derrubado e a volta conta como falha; duas falhas seguidas também encerram tudo.

A das voltas sem progresso é a mais curiosa. Quando uma janela termina sem avançar e sem bilhete novo, quase sempre é porque o modelo fez uma pergunta no chat, e ali não tem ninguém para ler. O script me entrega a pergunta junto com o último texto dele. Toda parada toca o sino do terminal e, no Windows, abre um aviso na tela, para quando eu saí da frente do computador.

Do outro lado, o /forge-resume ganhou um modo autopilot com regras próprias. Pergunta no chat está proibida. Confirmação de rotina, do tipo “continuo a partir da TASK-X?”, vira “sim” e fica registrada numa linha. Decisão de verdade (aprovar design, task bloqueada, mudança de escopo, ação destrutiva fora da task, dependência fora da stack) vira STATUS: AGUARDA-HUMANO e fim de turno. Aí o script abre uma sessão interativa, eu respondo, saio, e ele segue de onde parou.

E a segurança? O loop roda com permissões automáticas, mas os bloqueios do Forge são hooks, não pedidos educados no prompt. rm -rf, curl | sh, force-push e segredo em commit continuam barrados em qualquer modo, desde que o hook chegue a rodar. Se ele nem inicia (bash fora do PATH, caminho quebrado na configuração), o Claude Code trata como erro não bloqueante e a ação passa. Por isso, antes da primeira janela, o loop testa os bloqueios do jeito que o Claude Code os chamaria, com um rm -rf / e uma chave falsa. Se algum não bloquear, ele nem começa.

O começo de cada projeto também segue manual, de propósito: é ali que o agente me pergunta sobre o produto e que eu aprovo o design.

Os números, e o que eles não provam

O primeiro uso real foi no pokearena-ar, um PWA em Next.js com servidor de WebSocket. Duas janelas, sete tasks fechadas com todos os testes verdes, 72 minutos, US$ 22,70 e nenhuma intervenção minha. Depois vieram mais duas execuções no mesmo projeto. Somando as três: 31 tasks em 11 janelas.

Comparei com as 13 sessões manuais dos dias anteriores, no mesmo projeto:

	Manual (13 sessões)	Loop (3 execuções)
Tasks	29	31
Minutos por task	79,9	17,8
Custo do orquestrador por task	US$ 3,77	US$ 1,97
Custo por task com subagentes	não medido	US$ 3,98
Contexto mediano por turno	122,7 mil tokens	98,6 a 109,1 mil tokens

Bonito, né? Agora as letras miúdas.

Os minutos das sessões manuais incluem o tempo em que o agente ficou parado me esperando. Teve sessão que levou 701 minutos para fechar três tasks, porque eu não estava lá. O loop não pensa mais rápido. Ele só não espera ninguém.

O custo eu só consigo comparar pelo orquestrador, porque nas sessões manuais os subagentes não foram medidos. Orquestrador contra orquestrador, o loop sai por pouco mais da metade, e o número variou entre US$ 1,67 e US$ 2,14 de uma execução para outra. Com os subagentes, a task do loop custou uns US$ 4. O equivalente do manual eu simplesmente não tenho.

E o loop pegou as tasks de depois. As do começo do projeto, de motor de jogo e rede, eram as mais pesadas. Parte da diferença é a dificuldade da task, não o script.

O que o loop mudou de fato foi outra coisa: quantas vezes eu precisei intervir. Antes, uma vez a cada três a cinco tasks. Nas três execuções, os chamados foram quase todos para decisões que são minhas mesmo. A exceção foi uma janela que terminou esperando um subagente.

E as alternativas?

Antes de escrever o script, olhei o que já existia. O critério era um só: a janela do orquestrador fica limpa de verdade, sem mim no meio?

O plugin Ralph Wiggum, do repositório oficial do Claude Code, usa um hook de parada para devolver o prompt ao agente e mantê-lo trabalhando. Resolve o “não parar”, mas dentro da mesma sessão, com o contexto acumulando.

O context editing, junto com a memory tool, é a resposta da própria Anthropic para agentes de longa duração: a API apaga resultados antigos de ferramentas de forma determinística, e o agente guarda o que importa fora da janela. Em tese é melhor que o meu script. Só que é recurso da API, não um botão do Claude Code interativo. Para usar, eu teria de reescrever o orquestrador como uma aplicação à parte e abrir mão dos hooks, skills e subagentes em que o Forge se apoia.

O GSD parte da mesma ideia: trabalho pesado em subagentes com contexto limpo e sessão principal enxuta. Eu já tinha pegado dele outra coisa, a verificação rodando a aplicação de verdade. Mas ele também não traz quem relance a sessão principal.

Ficou o processo novo. O preço é pagar a largada de cada janela: uns 43 mil tokens na primeira chamada, entre US$ 0,51 e US$ 0,88, mais o tempo de ele se reorientar. E manter um script.

O que eu ainda não sei

A amostra cresceu, mas segue pequena: um projeto, três execuções, onze janelas. No Forge, uma mudança dessas só vira regra depois de três voltas seguidas sem intervenção e sem nenhuma janela terminando sem bilhete. Em 27 de setembro foram cinco seguidas, relançadas pelo script com segundos de intervalo, até parar numa decisão de produto que era minha. Só que a primeira janela daquela mesma execução terminou sem bilhete, esperando um subagente que o processo não esperou. Pela régua que eu mesmo escrevi, ainda não cheguei lá. Na prática, quase.

E tem uma dúvida maior. Em março, a Anthropic contou como monta agentes que constroem aplicações inteiras sozinhos (Harness design for long-running application development). Com o Sonnet 4.5, eles faziam o mesmo que eu: limpavam a janela e passavam um bilhete para o agente seguinte. O motivo era outro, uma “ansiedade de contexto” que fazia o modelo apressar o fim do trabalho perto do limite. Com o Opus 4.5 largaram isso: “I was able to drop context resets from this harness entirely”. O agente passou a rodar numa sessão contínua, com compactação automática. Ou seja, o reset que eu defendi lá em cima pode ser muleta de modelo antigo. Eu não medi a alternativa. Até medir, o processo novo é uma aposta, não uma conclusão.

Eu tinha limitado cada janela a US$ 15, e o orquestrador passou a fechar o checkpoint com três ou quatro tasks em vez de cinco, para não ficar sem verba no meio de uma. Achei que ele tinha olhado o próprio gasto. Não tinha. No modo não interativo a janela inteira é um turno só, e a telemetria do Forge só é gravada no fim do turno. Ele estimou, e estimou só o custo dele, uns US$ 2 por task, quando a task de verdade, com os subagentes, saía por US$ 4,64. Acertou a direção por sorte.

Hoje essa conta é do script. Ele pega o custo real por task das últimas cinco janelas, põe 30% de

margem e avisa o orquestrador no começo de cada janela: LIMITE DESTA JANELA: 3. Com US$ 20 por janela e o custo atual, dá três tasks. Cinco pediriam uns US$ 30.

O resto é menos charmoso. Nada impede que eu abra uma sessão manual com o loop rodando, e as duas brigariam pela mesma lista de tasks; existe um aviso, não uma trava. Se o loop for lançado como tarefa em segundo plano do próprio Claude Code, fechar a sessão mata o loop junto, e por isso ele abre uma janela de console só dele. E tudo foi testado primeiro no Windows: o script roda em Git Bash e WSL, mas o aviso na tela e a janela separada não foram testados fora.

No caminho apareceram dois bugs. O primeiro nem era do loop: um gate que copia minha configuração para o repositório travava para sempre, porque os hooks liam a entrada com cat e ela nunca fechava. Um </dev/null resolveu, e só apareceu por causa do loop.

O segundo é mais constrangedor. Nas dez primeiras janelas, o comando nunca chegou certo ao modelo. O Git Bash transforma qualquer argumento que começa com / num caminho do Windows, e o orquestrador recebia C:/Program Files/Git/forge-resume --autopilot. Ele achou o comando certo sozinho, por uma dica que o Forge injeta no começo de cada sessão. A primeira correção desligou a conversão de tudo e zerou minha telemetria de custo, porque os hooks herdaram a mesma configuração. A segunda desligou só para aquele comando. Script burro, eu disse. Às vezes, burro demais.

O que sobrou para mim

O pedido foi “apenas me peça caso necessite de alguma dúvida”. Foi exatamente o que ficou. O agente trabalha, para quando precisa e me chama para as decisões que são minhas: o que o produto deve ser, se o design está aprovado, se vale mudar o escopo.

Nas três execuções, foram umas nove horas de janela em que ninguém precisou de mim. O que fazer com elas é outra conversa, e essa eu já tive por aqui.