Mais arquitetura, menos tokens caros ao orquestrar agentes de código

Este artigo é uma leitura do fluxo compartilhado em r/codex. Os nomes de modelos e os preços citados são os informados na publicação original e podem mudar; confira a tabela vigente antes de usar o cálculo em produção.

Quando uma tarefa de código é grande, a decisão mais cara nem sempre é qual modelo usar. Muitas vezes é deixar o modelo mais caro descobrir o problema, desenhar a solução, implementar, testar e revisar tudo no mesmo contexto.

O fluxo proposto no r/codex separa essas responsabilidades: um modelo forte organiza o trabalho; um agente mais barato executa a maior parte; o primeiro volta para revisar e decidir se vale uma nova rodada de delegação. A ideia não elimina o custo de tokens. Ela tenta colocá-lo onde ele muda o resultado.

1. Planeje antes de abrir o terminal

O primeiro passo usa SOL xhigh para transformar a tarefa em um plano de implementação detalhado. Isso força uma resposta para perguntas que normalmente aparecem tarde demais: quais arquivos mudam, qual é o comportamento esperado, quais riscos existem, como testar e o que não deve ser alterado.

Se a tarefa ainda estiver vaga, a publicação sugere uma etapa opcional de perguntas dirigidas — uma habilidade no estilo “Grill Me”. Em vez de adivinhar requisitos, o agente pergunta até ter confiança suficiente para propor a implementação.

O ganho não vem de produzir um documento bonito. Vem de reduzir retrabalho. Um plano que aponta dependências, critérios de aceite e casos de falha dá ao agente executor um alvo verificável.

2. Comprima o contexto que não será usado

Depois do planejamento, a recomendação é compactar a conversa. O orquestrador não precisa carregar cada tentativa, cada saída de comando e cada raciocínio intermediário para a etapa seguinte. Ele precisa preservar decisões, restrições, arquivos relevantes e o plano.

Contexto grande tem dois custos: aumenta a conta e torna mais fácil o agente se prender a detalhes que já não importam. A compactação não deve apagar informação crítica; ela deve trocar um histórico longo por um estado de trabalho claro.

3. Use o modelo caro como orquestrador

Na execução, SOL recebe a tarefa e o plano, mas não precisa escrever todo o código. Seu papel é iniciar Luna em modo de raciocínio máximo, revisar o resultado e escolher entre duas ações: delegar uma correção com o contexto necessário ou corrigir localmente quando isso for mais barato e simples.

codex exec \
  -m gpt-5.6-luna \
  -c 'model_reasoning_effort="max"' \
  --ephemeral \
  -s workspace-write \
  -a never \
  'PLANO'

A revisão deve testar se a implementação respeitou o plano, se os testes cobrem falhas reais e se a solução ficou mais complexa do que a tarefa exige. Sem esse filtro, a divisão de trabalho só distribui erro entre dois agentes.

Meça o custo por papel, não só o total

A publicação usa como referência US$ 0,20 por milhão de tokens de entrada e US$ 1,20 por milhão de tokens de saída para a API da Luna. Com esses valores, dá para pedir ao orquestrador um relatório separado: custo da Luna, custo do próprio SOL e uma estimativa de quanto custaria se SOL xhigh resolvesse tudo sozinho.

Essa comparação evita uma armadilha comum: considerar a delegação barata só porque um agente tem preço menor. Se o executor recebe um plano ruim, precisa de muitas idas e voltas ou devolve código que exige reescrita, a economia desaparece. O número útil é o custo para entregar uma mudança correta, testada e compreensível.

O que vale testar no seu projeto

• Comece com uma tarefa que tenha critérios de aceite claros e alguns testes existentes.
• Registre tokens e tempo por etapa: planejamento, execução, revisão e correção.
• Peça ao orquestrador para manter o resumo de estado após cada ciclo.
• Compare a taxa de retrabalho com uma execução de modelo único.
• Trate preços e disponibilidade de modelos como dados variáveis, não como premissas permanentes.

O ponto central do fluxo não é prometer tokens infinitos. É reservar raciocínio caro para decisões, desenho e revisão; deixar a implementação repetível para um agente mais econômico; e medir se a divisão realmente reduz o custo de entrega.

---

Fonte: “Never run out of tokens again?” — r/codex. Publicação original fornecida pelo solicitante.