Em 19 de agosto, a OpenAI publicou no blog para desenvolvedores um texto intitulado "Codex as a platform", trocando a forma de descrever o Codex: de "assistente de programação que roda no terminal" para "camada de execução de código aberto sobre a qual outros podem construir diretamente".
O artigo começa esclarecendo um ponto facilmente esquecido: a maioria das pessoas conhece o Codex pelo aplicativo desktop, pela linha de comando ou por um plugin de IDE, mas essas três portas de entrada compartilham o mesmo sistema subjacente, que já estava disponível no GitHub (repositório openai/codex, licença Apache 2.0, atualmente com 109 mil estrelas). O que a OpenAI faz agora é um reposicionamento: transformar algo que era "detalhe interno de implementação do nosso produto" em "a base sobre a qual vocês constroem".
A camada que envolve o modelo
O texto original em inglês usa o termo harness, que a comunidade técnica costuma traduzir como framework de execução ou arcabouço de controle. A definição da OpenAI é bem direta:
"That surrounding execution system is the harness."
Esse sistema de execução que envolve o modelo é o harness.
Detalhando, é ele quem coleta contexto, decompõe a tarefa em passos executáveis, mantém o estado da sessão ao longo de múltiplas rodadas, chama ferramentas, executa dentro dos limites configurados de sandbox e permissões, para no momento certo para aguardar aprovação humana e, por fim, devolve o resultado ao sistema de negócio. Nada disso tem relação com os pesos do modelo, mas a qualidade da execução afeta diretamente os resultados. A OpenAI cita novamente seus próprios dados do ARC-AGI-3, do fim de julho: apenas ativando, na camada de harness, a retenção de raciocínio e a compressão de contexto, a pontuação do GPT-5.6 Sol no conjunto público subiu de 13,3% para 38,3%, enquanto o número de tokens de saída caiu para cerca de um sexto. O modelo não mudou; o que mudou foi a camada ao redor dele.
Três níveis de integração, por profundidade de intrusão
A OpenAI dividiu claramente as formas de integração em três camadas, para que os desenvolvedores escolham conforme o cenário, sem precisar encaixar tudo numa janela de chat.
O codex exec é voltado a scripts, tarefas de CI e trabalhos únicos em segundo plano: executa um fluxo de agente com limites bem definidos, entrega um resultado estruturado e encerra. O Codex SDK é voltado a aplicações que precisam iniciar, retomar e ler em streaming tarefas do Codex diretamente no código. O Codex app-server é o nível mais invasivo: a aplicação se conecta a um processo local do Codex, mantém a sessão sempre aberta, recebe um fluxo de eventos, pode interromper a qualquer momento, expõe suas próprias ferramentas ao agente e assume o tratamento das solicitações de aprovação.
Para explicar como usar o app-server, a OpenAI criou de quebra um aplicativo de exemplo chamado Relay, um painel fictício de tratamento de exceções em transporte de cargas. O usuário não digita prompts; primeiro seleciona um carregamento, depois clica em um botão como "Compare recovery"; a aplicação passa o contexto relevante, o Codex usa uma ferramenta MCP conectada pela própria aplicação para buscar dados atualizados e explicar as opções disponíveis; para de fato remarcar algo, é obrigatória a aprovação humana, e só depois de registrar a operação no banco de dados a aplicação atualiza sua própria interface de negócio.
Essa escolha de design é explicada sem rodeios no artigo: não se deve substituir painéis de despacho, linhas do tempo, mapas e telas de tickets por uma janela de chat genérica — essas interfaces existem justamente para que as pessoas entendam a situação, tomem decisões e mantenham a sensação de controle.
Quem já colocou em produção
A OpenAI listou três grupos de casos públicos. GitHub e JetBrains integraram o Codex aos próprios fluxos de trabalho em IDE; a Cisco usou o Codex SDK no App Builder do Cloud Control; Thrive Holdings e Crete incorporaram o Codex ao processo de preparação de declarações de imposto de renda, processando 7 mil declarações na fase piloto, com redução de cerca de um terço no tempo de preparação.
Esse último número é o mais consistente de todos. Preparação de declarações é um caso típico de alta repetição, baixa tolerância a erros e forte exigência de conformidade; apresentar uma escala de piloto e um indicador de eficiência comparável é muito mais útil do que afirmações vagas do tipo "aumento expressivo de produtividade". A OpenAI também aproveitou para reforçar que esse modelo não serve apenas a equipes de engenharia: triagem de suporte ao cliente, coordenação operacional, classificação de incidentes de segurança, verificação prévia em vendas — todos têm o mesmo formato: a aplicação fornece contexto, ferramentas e etapas de aprovação, e o Codex cuida do ciclo entre elas.
Até onde vai o código aberto
Há uma frase destacada no artigo: o que é aberto é o harness e as superfícies de integração; o acesso ao modelo e os serviços hospedados continuam sendo cobrados à parte.
Colocando essa frase ao lado dos três níveis de integração, fica clara a estratégia da OpenAI. A camada de execução é entregue de graça, auditável e personalizável, e qualquer um pode incorporá-la ao próprio produto; mas, a cada ciclo de agente executado, os tokens continuam passando pela API da OpenAI. Quanto mais útil for a parte aberta e quanto mais produtos a incorporarem, maior o volume de chamadas do lado do modelo. É a mesma jogada que a Anthropic fez ao transformar o MCP em padrão de fato para integração de ferramentas — só que desta vez a OpenAI está cedendo algo bem mais pesado: o runtime inteiro.
Para equipes que constroem produtos de agentes, o ganho imediato é economizar um trabalho repetido. Estado de sessão, fluxo de eventos, chamadas de ferramentas, interrupções para aprovação — a maioria das equipes já escreveu isso pelo menos uma vez, e depois ainda teve que ajustar. Agora existe uma implementação validada em larga escala, legível linha a linha, para servir de referência. Fazendo as contas: se apenas a mudança na camada de harness já reduz os tokens de saída a um sexto, com o mesmo orçamento dá para rodar cinco ciclos a mais — isso sozinho já vale a pena para muitas equipes lerem o código-fonte com atenção.
O custo também está à vista: quanto mais profunda a integração, mais atrelada ao modelo de cobrança da OpenAI. Isso fica especialmente claro no nível app-server, que vai além de uma simples relação de chamadas de API e praticamente traz o processo de terceiros para dentro do próprio produto.
Fontes: blog para desenvolvedores da OpenAI "Codex as a platform", CocoLoop, repositório GitHub openai/codex; licença, número de estrelas e os três níveis de integração conferidos no repositório e na documentação oficial, pontuação do ARC-AGI-3 e redução de tokens conforme dados divulgados pela própria OpenAI.