OpenAI Codex: o Agente na Nuvem
- ⬜🗺️ O Panorama dos Coding Agents(Ferramentas de IA para Código)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Esse módulo responde de frente a pergunta técnica que todo mundo faz: "o harness do Codex precisa abstrair várias linguagens de tool call — isso degrada performance?". A resposta curta: não do jeito que a intuição sugere. A resposta longa — com dados — é o que vem a seguir.
Antes: dois produtos, o mesmo nome
Codex (2021) — modelo de completions
Fine-tune do GPT-3 em código público do GitHub. Base técnica do Copilot original (inline autocomplete). Depreciado em 2023.
Codex (2025/2026) — agente autônomo cloud
Produto novo: recebe uma tarefa, abre um container isolado na OpenAI, clona o repositório GitHub, executa e devolve um PR. Passou por três gerações de modelo: codex-1 (RL fine-tune de o3 para tarefas longas, mai/2025), gpt-5-codex (set/2025, compute adaptativo por dificuldade) e GPT-5.1-Codex-Max (nov/2025, "compactação" nativa para sessões de 24h+ e contexto efetivo acima de 400k tokens).
Arquitetura: cloud sandbox
Esta é a diferença arquitetural central. Enquanto Claude Code opera na sua máquina, o Codex opera em um ambiente completamente remoto:
// Fluxo do OpenAI Codex
Você → "implementa autenticação OAuth no meu projeto"
↓
OpenAI recebe a tarefa
↓
Container isolado é criado nos servidores da OpenAI
↓
Seu repositório GitHub é clonado no container
↓
Agente executa: lê código, escreve, roda testes
↓
Resultado: Pull Request aberto no seu GitHub
↓
Você revisa o PR como faria com qualquer devO container tem acesso à internet, pode instalar dependências, rodar compiladores e executar testes — mas não tem acesso à sua máquina local. Seus arquivos locais, variáveis de ambiente locais, serviços rodando em localhost — nada disso está disponível.
Assíncrono e paralelo: o grande diferencial
Claude Code é síncrono: você manda uma tarefa e espera a resposta antes de enviar a próxima. O Codex é assíncrono:
Exemplo de uso paralelo
09:00 → você submete: "adiciona testes para o módulo de pagamentos"
09:01 → você submete: "refatora a camada de cache para Redis"
09:02 → você submete: "corrige o bug #247 no parser de CSV"
Três agentes trabalhando em paralelo. Você continua seu trabalho.
09:18 → PR #1 aberto: "feat: add payment module tests"
09:23 → PR #2 aberto: "refactor: migrate cache to Redis"
09:31 → PR #3 aberto: "fix: CSV parser bug #247"
Para times, isso é poderoso. Múltiplos desenvolvedores podem submeter tarefas independentes sem concorrência de recursos locais.
O modelo por baixo: codex-1 → GPT-5.1-Codex-Max
A linhagem é importante porque cada versão mudou o que o harness precisa gerenciar:
A pergunta que todo mundo faz: o harness mata performance?
A intuição é razoável: se o harness precisa receber tool calls em JSON, validar, parsear, roteá-las, converter erros de volta para o modelo, traduzir entre formatos — tudo isso parece que deveria cobrar um preço. Mas os números não confirmam isso da forma que se imagina.
✗ O que NÃO é o gargalo
→ Parsear JSON/XML de tool calls: ordem de microssegundos. O LLM levou ~1-30 segundos pra gerar aquela resposta. O parser é irrelevante no orçamento.
→ Validar schema da ferramenta: microssegundos. Mesmo que você valide 50 chamadas por minuto, não chega perto do tempo de inferência.
→ Dispatch para a função correta: lookup de hashmap. Imensuravelmente pequeno.
✓ O que REALMENTE mexe no benchmark
→ Formato de edição (diff unificado vs search-replace vs whole-file vs udiff-simple): o mesmo LLM oscila 20+ pontos no benchmark Aider só mudando o formato. Não é o parse — é o modelo saber escrever o formato sem erros.
→ Quantidade e descrição das ferramentas: cada ferramenta ocupa tokens no system prompt, compete por atenção. Harnesses com 8 ferramentas bem desenhadas ganham de harnesses com 40 ferramentas redundantes.
→ Política de contexto: quando cortar histórico, quando compactar, o que preservar. Aí mora o que te faz ganhar ou perder uma tarefa multi-hora.
→ Orçamento de turnos: SWE-agent mostrou que subir o limite de 50 para 250 turnos levou Claude Opus de 23% para 45%+ no SWE-bench — o modelo já sabia, só precisava de loop.
→ Prompt caching: re-enviar os mesmos 30k tokens do system prompt sem cache custa latência e dinheiro. Harnesses que usam cache_control corretamente ganham 60-90% em p50/p95 time-to-first-token.
Em outras palavras: a afirmação "o parser do harness derruba performance" é falsa. A afirmação correta é mais sutil — o DESENHO do harness muda benchmark drasticamente, mas não via CPU, e sim via engenharia de prompt, gestão de contexto e protocolo de ferramentas.
A evidência concreta
Três pontos de dado públicos para ancorar a discussão:
// 1. SWE-bench Pro (nov/2025): // Confucius Code Agent + Claude Sonnet 4.5 → 52,7% // Claude Opus 4.5 (scaffold nativo Anthropic) → 52,0% // Modelo "menor" com scaffold dedicado bate modelo "maior" // com scaffold genérico. O harness importa MAIS que o tamanho // do modelo nesse regime. // 2. Claude Opus 4.5 em diferentes scaffolds no SWE-bench: // SEAL Harness → 45,9% // Scaffold X → ~50% // Claude Code → 55,4% // Mesmo modelo. Spread de 9,5 pontos só trocando o harness. // 3. SWE-bench Verified (abr/2026): // Seis modelos frontier (Opus 4.6, Sonnet 4.6, GPT-5.1, // Gemini 3 Pro, Haiku 4.5, codex-max) dentro de ~0,8pt. // Hoje, diferenças de 20 pontos em benchmark "final" entre // ferramentas vêm majoritariamente do scaffold, não do LLM.
Trade-offs reais: cloud vs local
✓ Vantagens do Cloud Sandbox
→ Não consome sua CPU/RAM local durante execução
→ Ambiente limpo e reprodutível a cada tarefa (sem "na minha máquina funciona")
→ Múltiplas tarefas em paralelo sem impactar seu trabalho atual
→ Isolamento total — o agente não pode deletar seus arquivos locais acidentalmente
✗ Limitações do Cloud Sandbox
→ Sem acesso a serviços locais (banco de dados local, APIs com segredos locais)
→ Precisa de repositório no GitHub (não funciona com repos apenas locais)
→ Latência maior para tarefas pequenas (overhead do container)
→ Seus arquivos e código passam pelos servidores da OpenAI
Segurança e privacidade: o elefante na sala
Esta é uma decisão que cada time precisa tomar conscientemente. Ao usar o Codex, o código do seu repositório é enviado para a OpenAI para ser processado no sandbox.
A OpenAI afirma não treinar modelos com dados da API por padrão, e oferece contratos de processamento de dados (DPA) para clientes enterprise. Mas para código proprietário sensível ou projetos com compliance rigoroso (HIPAA, SOC2), avaliar isso é obrigatório.
Claude Code tem um perfil de privacidade diferente: seus arquivos ficam na sua máquina. Só o texto dos prompts (o que você escreveu e o que o agente leu) trafega pela API da Anthropic.
Então, Codex ou Claude Code?
A pergunta correta não é "qual é melhor" e sim "qual é o problema". Critérios concretos:
Seu repo está no GitHub e a tarefa é bem-definida (bug fix, adição de testes, pequena refatoração)
→ Codex — Paralelismo. Você dispara 5 tarefas, continua trabalhando, revê PRs.
Você precisa de acesso a serviços locais (banco dev, docker compose com secrets, serviço interno sem exposição pública)
→ Claude Code — Codex no sandbox não consegue falar com localhost:5432 da sua máquina.
Tarefa exploratória / debug difícil / código proprietário sob compliance (HIPAA, LGPD, dados regulados)
→ Claude Code — Arquivos permanecem na sua máquina, só prompts vão pra API. Auditoria mais simples.
Time precisa desbloquear backlog — várias tasks triviais em paralelo enquanto devs trabalham em tarefas hard
→ Codex — Modelo assíncrono foi desenhado pra isso. Cada PR é um review, não um shadowing.
Você está aprendendo a codebase ou precisa de controle fino sobre cada passo
→ Claude Code — Você vê cada tool call, pode interromper, redirecionar. No Codex você só vê o PR final.
Quiz rápido
3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito