Otimização de custos do Codex na prática: como economizar tokens sem perder critério

"A Codex rate card explica a relação entre input, cached input e output tokens; essa é a base da análise de custos neste artigo."
Otimização de custos do Codex na prática: como economizar tokens sem perder critério
A mesma tarefa, mas a cota some muito mais rápido do que o esperado. Um thread longo relê o contexto o dia inteiro. multi_agent está ligado por padrão. AGENTS.md tem milhares de linhas. Até tarefas pequenas rodam no modelo mais caro. Se você quer saber para onde vai o dinheiro e como reduzir isso de forma sistemática, aqui está a leitura direta.
1. Para onde vai o dinheiro: como a cobrança funciona
Os custos do Codex vêm de quatro fontes: reler contexto, sessões longas, subtarefas em paralelo e níveis altos de raciocínio. O mecanismo básico é a cobrança token/credit: cada bloco de input, cached input e output consome o crédito correspondente. Os diferentes tipos de token têm tarifas diferentes. cached input custa menos que input normal, e é por isso que o prompt cache pode economizar dinheiro. As tarifas exatas estão na rate card oficial.
O Codex não funciona com um simples limite mensal, e sim com uma janela móvel. Quando a janela enche, entram os rate limits. Plus e Pro têm rate-limit reset banking, e a janela se recupera depois do prazo. As API keys são cobradas separadamente por token e não dependem do limite do plano do Codex.
Se quiser ver o uso, use /status para a sessão atual ou abra o usage dashboard nas configurações do Codex para ver o consumo do time.
Reler contexto é a fonte de gasto mais fácil de ignorar. Em cada tarefa, o Codex relê AGENTS.md, a documentação do projeto e o histórico do thread. Se AGENTS.md tem milhares de linhas, a documentação é enorme e um thread roda por muitas rodadas, os tokens vão se acumulando. Sessões longas são cumulativas: quanto mais longo o thread e mais ele lê, mais caro fica. Com multi_agent, cada agente ativo consome sua própria cota, então o custo sobe com o paralelismo. Modelos mais potentes como GPT-5.5/5.4 custam mais que GPT-5.4 mini, e os níveis de raciocínio Low/Medium/High/Extra High também mexem na conta.
Veja como as medidas de economia se comparam ao custo de oportunidade:
| Medida de economia | Efeito esperado | Trade-off |
|---|---|---|
| Escolher um modelo mais barato | Reduz o consumo em 30-60% | Menos raciocínio; pior em tarefas complexas |
| Limpar o contexto no tempo certo | Reduz o consumo em 20-40% | Mais threads novos; histórico se perde |
| Enxugar o AGENTS.md | Reduz o consumo em 10-20% | Mais fragmentação da documentação; manutenção maior |
| Usar o prompt cache | Reduz o consumo em 15-30% | O contexto precisa permanecer estável |
| Reduzir multi_agent | Reduz o consumo em 20-50% | Menos paralelismo; execução mais lenta |
Economizar não é virar pão-duro. Um modelo mais barato pode cortar a conta em 30-60%, mas tarefas complexas podem piorar. Limpar o contexto no tempo certo pode economizar 20-40%, mas exige abrir mais threads. Enxugar o AGENTS.md pode economizar 10-20%, mas joga trabalho para a estrutura da documentação. O critério real é a tarefa. Não sacrifique a capacidade principal só para poupar um pouco.
Monitorar o uso
Com /status no console você vê o estado do thread atual, incluindo tamanho do contexto e cota consumida. No usage dashboard das configurações do Codex você vê o consumo do time e o estado da janela de quota. Acompanhe isso periodicamente para comparar o efeito real das medidas de economia.
2. Níveis de modelo e raciocínio: nem sempre o mais caro
A escolha do modelo impacta diretamente o custo. O Codex oferece quatro níveis de raciocínio: Low, Medium, High e Extra High. Low é rápido e fechado, ótimo para tarefas simples. Medium e High combinam mais com trabalho mais complexo ou com debugging pesado. Extra High é para tarefas agentic longas. Em modelos, GPT-5.5 e GPT-5.4 são os frontier; GPT-5.4 mini é a variante leve; 5.3-Codex e 5.2 já estão defasados.
A regra base é simples: frontier para pensar, mini para trabalho rotineiro. Escolha o nível de raciocínio conforme a dificuldade real. Não use sempre a combinação mais cara. Manter o nível mais alto por padrão queima cota sem necessariamente ajudar nas tarefas simples.
A distribuição é esta:
| Tipo de tarefa | Nível de raciocínio recomendado | Cenário típico |
|---|---|---|
| Busca simples, mudança de formato | Low | Formatação de documento, pequenos ajustes |
| Refactor, desenvolvimento de recurso | Medium | Refactor de um arquivo, integração de API |
| Debugging, lógica complexa | High | Bug em vários arquivos, ajuste de performance |
| Tarefas agentic longas | Extra High | Automação multi-etapas, desenvolvimento exploratório |
Para consultas simples e conversões de formato, use Low + mini. Para refactors e desenvolvimento de recursos, Medium + mini ou Medium + GPT-5.4. Para debugging e lógica complexa, High + GPT-5.4/5.5. Para tarefas agentic longas, Extra High + GPT-5.5. Escolha pela dificuldade real, não pela sensação de segurança. Ir alto demais “por garantia” também custa caro.
FAQ: como escolher um modelo que economize
Para tarefas de pensamento, modelos frontier (GPT-5.5/5.4); para trabalho pequeno, mini (GPT-5.4 mini). Ajuste o nível de raciocínio à dificuldade. Busca simples: Low. Debugging complexo: High. Tarefa agentic longa: Extra High.
3. Gestão de sessões: não deixe um thread rodando o dia inteiro
Uma sessão longa pode passar o dia inteiro relendo contexto. Os tokens voam. O Codex relê o thread a cada execução, e quanto mais longo ele for e mais ler, maior o custo. A solução é simples: sessões curtas. Um thread, uma tarefa.
Na prática: AGENTS.md tem milhares de linhas, a documentação do projeto é enorme e os vai-e-vem se repetem muitas vezes. Uma única releitura custa alguns tokens, mas dezenas de rodadas viram dezenas de milhares. Quanto mais o thread cresce, mais fácil o Codex se enrolar e pior o resultado.
| Comando | Para que serve | Quando usar |
|---|---|---|
/compact | Comprimir o contexto inicial | Quando um thread começa a crescer (o Codex também faz isso automaticamente) |
/clear | Apagar o thread atual | Quando a tarefa terminou |
/resume | Retomar um thread anterior | Quando precisa continuar uma tarefa passada |
/fork | Criar uma ramificação | Quando é preciso explorar caminhos diferentes |
/agent | Mudar para um agente paralelo | Quando você precisa de multi_agent |
/status | Ver o estado do thread | Quando quiser monitorar o uso |
Melhores práticas de sessão
Quando uma tarefa termina, use /clear imediatamente ou abra um thread novo para evitar acúmulo de contexto. Em sessões longas, use /compact para comprimir a parte inicial e economizar tokens. Não use /resume a menos que realmente precise continuar a tarefa anterior. Não misture bugfix, feature, refactor e deployment no mesmo thread. O contexto fica confuso e os tokens se perdem. Para ramificações de exploração, use /fork, mas lembre-se de que cada ramificação consome sua própria cota.
FAQ: como gerenciar sessões longas
Quando a tarefa terminar, use /clear ou abra um thread novo. Em sessões longas, use /compact. Um thread, uma tarefa.
4. AGENTS.md enxuto: evitar o corte de 32 KiB
AGENTS.md cresce rápido e engole contexto. Além disso, pode ser truncado. project_doc_max_bytes vem por padrão em 32 KiB. Assim que o AGENTS.md chega a esse limite, o sistema para de adicionar conteúdo e corta o restante. O truncamento faz perder instruções e desperdiça contexto.
Como enxergar o tamanho do AGENTS.md:
| Tamanho do AGENTS.md | Impacto | Solução |
|---|---|---|
| < 16 KiB | Sem efeito perceptível; baixo consumo de contexto | Manter como está |
| 16-32 KiB | Carga média; acompanhar | Separar o que não for essencial |
| > 32 KiB | Risco de truncamento; algumas instruções somem | Dividir em pastas aninhadas |
Passos para enxugar o AGENTS.md
Mantenha um único AGENTS.md leve e estável abaixo de 32 KiB, e deixe ali só as instruções centrais e as regras comuns. Se passar do limite, mova as regras extras para pastas aninhadas como docs/.agents e deixe os detalhes em arquivos .md dedicados à tarefa. Use o override por proximidade para que o AGENTS.md local de uma subpasta tenha prioridade.
Para um guia mais detalhado, veja AGENTS.md Best Practices.
5. Prompt cache: tornar mais barato o contexto estável
cached input custa menos que input normal, e essa é a principal razão para usar prompt cache. Se o contexto ficar estável, o Codex pode cobrá-lo como cached input. Mantenha AGENTS.md e a documentação do projeto estáveis para que o cache realmente funcione.
O mecanismo é simples: o Codex guarda blocos de contexto estáveis como AGENTS.md e a documentação do projeto. Na próxima execução, eles viram cached input. Se você muda isso toda hora, a cache falha e você volta para a cobrança normal de input. Uma boa taxa de cache pode reduzir o custo de uma execução em 15-30%.
A regra prática: manter AGENTS.md curto e estável, colocar as regras duráveis em um lugar fixo e mover conteúdo volátil para uma pasta temporária ou documentação específica da tarefa. Não coloque tudo no prompt.
Troca entre uso e cache:
| Alavanca de cache | Efeito esperado | Trade-off |
|---|---|---|
| AGENTS.md estável | Maior hit rate de cached input | Exige planejamento; menos mudanças |
| Docs do projeto estáveis | Menos tokens relidos | A cache quebra quando a doc muda |
| Evitar mudanças frequentes | Hit rate mais estável | Menos flexibilidade |
FAQ: como o prompt cache economiza dinheiro
Mantenha AGENTS.md e a documentação do projeto estáveis para aproveitar cached input. cached input custa menos que input normal, e a diferença exata está definida na rate card oficial.
6. Paralelismo e plan mode: só ligue quando precisar
multi_agent v2 é cobrado por execução ativa. Cada agente ativo consome cota, então o paralelismo custa mais do que um único agente. Por enquanto, multi_agent ainda é experimental; a postura padrão deve ser de contenção. Ligue apenas quando for realmente necessário.
A conta é simples: um agente roda uma vez e consome X. Se multi_agent colocar três agentes para rodar em paralelo, cada agente ativo consome X e o total vira 3X. Quanto mais agentes, mais caro. Além disso, cada agente relê contexto, raciocina e gera saída, e isso soma tudo.
| Modo de paralelismo | Efeito no custo | Cenário típico |
|---|---|---|
| Um agente | Custo base | Uma tarefa, execução sequencial |
| multi_agent (paralelismo leve) | +20-30% | Exploração paralela real |
| multi_agent (paralelismo forte) | +50-100% | Tarefas agentic longas |
multi_agent faz sentido quando a tarefa realmente precisa de exploração paralela, por exemplo mudar vários arquivos ao mesmo tempo, sincronizar vários documentos ou rodar fluxos agentic longos como testes automáticos, deployment e monitoramento. Para um bugfix pontual, um refactor passo a passo ou trabalho individual com orçamento apertado, não é a melhor opção. Para entender melhor os custos do paralelismo, veja Codex Multi-Agent in Practice.
A regra para multi_agent é simples: desligado por padrão, ligado só quando fizer sentido. Mantenha poucos agentes ativos e reduza o paralelismo se o custo subir rápido demais.
FAQ: o paralelismo multi-agent é caro?
Sim. O multi-agent v2 cobra por execução ativa, então cada agente ativo consome cota. Deixe desligado por padrão.
7. Plan mode: não abuse em tarefas simples
Plan mode adiciona uma rodada de planejamento, então consome tokens extras. Em tarefas complexas, essa rodada pode evitar retrabalho. Em tarefas simples, muitas vezes é só overhead. Se a tarefa estiver clara, execute direto.
Assim, complexidade e plan mode se relacionam:
| Dificuldade da tarefa | Usar plan mode? | Impacto no custo |
|---|---|---|
| Simples (um passo, clara) | Não | Custo base |
| Média (vários passos, precisa de validação) | Sim | Uma rodada extra de planejamento, mas menos retrabalho |
| Complexa (cadeia agentic longa) | Sim | Uma rodada extra de planejamento, mas evita um retrabalho mais caro |
A regra: plan mode para tarefas complexas, execução direta para as simples. É a recomendação conservadora. A decisão final depende da tarefa.
FAQ: plan mode custa mais?
Sim, ele adiciona uma rodada extra de tokens. Não use em tarefas simples; guarde para tarefas complexas e evite retrabalho.
8. Monitoramento e orçamento: só economiza quem enxerga
Para saber se a economia está funcionando, é preciso visibilidade. O Codex oferece dois pontos de monitoramento: o usage dashboard e /status. O usage dashboard fica nas configurações do Codex e mostra o consumo do time e o estado da janela de quota. /status no console mostra o tamanho do contexto e a cota consumida do thread atual.
Passos para monitorar o uso
Abra o usage dashboard nas configurações do Codex para ver o uso do time. Use /status para inspecionar o thread atual. Para planejamento de orçamento, dá para usar uma faixa de referência: Plus fica em torno de $20/mês, Pro em torno de $200/mês, Business em torno de $25-30 por pessoa por mês, e experiências reais de time costumam ficar perto de $100-200 por pessoa por mês (somente como referência, não oficial). Esses números servem como referência para 2026-06; para decisões reais, siga o preço oficial.
FAQ: quanto custa por mês?
Plus fica em torno de $20/mês, Pro em torno de $200/mês. Na prática, em times costuma aparecer uma faixa de $100-200 por pessoa por mês. O número real está no usage dashboard.
9. FAQ
Q1: Para onde vai o dinheiro do Codex?
Para reler contexto, sessões longas, paralelismo multi-agent e níveis altos de raciocínio. Veja a seção 1.
Q2: Como escolher um modelo mais barato?
Frontier para pensar (GPT-5.5/5.4), mini para o simples (GPT-5.4 mini). Ajuste o nível de raciocínio à dificuldade. Veja a seção 2.
Q3: Como lidar com sessões longas?
Use /clear quando terminar a tarefa, ou /compact em threads longos. Um thread, uma tarefa. Veja a seção 3.
Q4: Como o prompt cache ajuda a economizar?
Mantenha AGENTS.md e a documentação do projeto estáveis para aproveitar cached input. cached input custa menos que input normal. Veja a seção 5.
Q5: AGENTS.md grande demais é um problema?
Sim, acima de 32 KiB ele pode ser truncado e ainda consome contexto. Mantenha o arquivo principal leve e mova o excesso para pastas aninhadas. Veja a seção 4.
Q6: O paralelismo multi-agent é caro?
Sim, porque a cobrança é por execução ativa. Deixe desligado por padrão. Veja a seção 6.
Q7: Plan mode custa mais?
Sim, ele adiciona uma rodada extra de tokens. Não use em tarefas simples. Veja a seção 7.
Q8: Quanto custa aproximadamente por mês?
Plus em torno de $20/mês, Pro em torno de $200/mês. Em times, costuma-se falar em $100-200 por pessoa por mês. Veja a seção 8.
10. Próximos passos e leitura complementar
Se quiser um guia sobre permissões e erros comuns, leia Codex Sandbox and Permission Boundaries. Se quiser se aprofundar em agentes paralelos, leia Codex Multi-Agent in Practice.
Fazer um check de custos do Codex
Revise rapidamente os cinco focos de gasto mais comuns: cobrança, modelo, sessões, cache e paralelismo.
- 1
Step 1: Verificar o uso
Comece com `/status` e o usage dashboard para ver a sessão atual e o consumo do time. - 2
Step 2: Reduzir o raciocínio
Use Low ou mini para tarefas simples; deixe os níveis altos para debugging de verdade. - 3
Step 3: Encurtar sessões
Quando terminar, `/clear`; se o thread crescer, `/compact`; `/fork` só quando precisar de uma ramificação. - 4
Step 4: Estabilizar o contexto
Mova as regras duradouras para um AGENTS.md enxuto ou para documentação dedicada à tarefa. - 5
Step 5: Controlar o paralelismo
Ative multi_agent e plan mode só quando eles realmente agregarem valor.
FAQ
Para onde vai o dinheiro do Codex?
Qual modelo usar para pagar menos?
Como lidar com sessões longas?
Como o prompt cache ajuda a economizar?
multi_agent sempre sai mais caro?
Quanto custa o Codex por mês?
12 min de leitura · Publicado em: 13 ago 2026 · Atualizado em: 13 ago 2026
Guia prático de OpenAI Codex
Se você chegou pela busca, o caminho mais rápido é ir para o post anterior ou próximo desta série.
Anterior
Codex Computer Use e o navegador integrado na prática: deixar o agente ver páginas, operar apps e iterar o frontend
Aprenda como o Codex Computer Use e o navegador integrado funcionam juntos: operar apps com o cursor, iterar frontend no navegador, usar Developer mode para depuração e escolher o fluxo certo para cada plataforma.
Parte 12 de 15
Próximo
Codex Automations para tarefas longas: gatilhos agendados, heartbeats e trabalho de vários dias
Um guia prático para usar o Codex Automations: quando escolher automação autônoma ou ligada ao projeto, quando preferir um heartbeat no thread, como ajustar worktree, sandbox, approval policy, frequência e condições de parada, e como evitar transformar trabalho de bastidor em um loop sem fim.
Parte 14 de 15



Comentários
Entre com GitHub para comentar