Este texto é uma leitura do fluxo compartilhado em r/codex. Os nomes de modelos e os preços mencionados abaixo 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.
TAREFA
Seu trabalho é orquestrar e revisar o agente de max-thinking da Luna.
Dê atenção especial a:
- qualidade do código;
- implementações simples e compreensíveis;
- comentários e documentação úteis;
- práticas idiomáticas do framework;
- testes significativos, inclusive casos de borda e falhas.
Depois da revisão, escolha:
1. chamar Luna novamente com o contexto necessário para resolver os problemas; ou
2. corrigir você mesmo quando isso consumir substancialmente menos tokens.
Inicie Luna com:
codex exec \
-m gpt-5.6-luna \
-c 'model_reasoning_effort="max"' \
--ephemeral \
-s workspace-write \
-a never \
'PLANO'Há uma distinção importante aqui: orquestrar não é apenas repassar prompts. A revisão precisa 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.