Otimizações do agent loop do ChatGPT reduzem custo por tarefa

Arquitetura em três camadas

Quando um usuário envia uma tarefa ao Codex ou ChatGPT Work, a requisição não vai direto ao LLM. Ela passa por três camadas: o harness (orquestração, execução de ferramentas e manutenção do histórico), a API (autenticação, tokenização, validação e checks de segurança) e a inferência (execução do modelo em GPUs). Cada iteração do loop agêntico repete trabalho nessas três camadas, e é nessa repetição que mora o custo.

Otimizações no harness

WebSockets persistentes com requests incrementais: em vez de abrir uma conexão HTTPS a cada chamada de modelo (com handshake TCP/TLS e reenvio de todo o contexto), o Codex mantém um único WebSocket aberto e envia apenas o delta - por exemplo, só o resultado da última tool call, com uma referência ao response anterior.
Prefixos de prompt estáveis: para aproveitar o prompt caching (que reutiliza estado computado para o início idêntico do prompt), o harness trata o histórico como append-only e mantém estado volátil (como configurações de aprovação) fora do prompt. Um bug real: tool definitions em hash map sem ordem garantida quebravam o cache silenciosamente.
Descoberta diferida de ferramentas: em vez de incluir centenas de schemas de ferramentas no prompt, o contexto carrega só as ferramentas core mais uma ferramenta tool_search. Quando o modelo precisa de algo, busca por palavras-chave via BM25 e o schema é injetado sob demanda.
Code Mode: em vez de emitir tool calls uma a uma (cada uma exigindo um round trip completo), o modelo escreve um pequeno programa JavaScript que executa as chamadas em paralelo, filtra e junta resultados, e devolve só a resposta compacta ao contexto.

Otimizações na API

Tokenização apenas do delta: com o WebSocket, a API mantém a conversa tokenizada em memória. A primeira request tokeniza tudo; as subsequentes tokenizam só o trecho novo, tornando o custo por chamada próximo de O(1).
Safety checks em paralelo com inferência: os classificadores de segurança rodam simultaneamente ao processamento do prompt, escondendo a latência dentro da janela que já existiria antes do primeiro token. Se um check falha, o stream é cortado ou o output é retido, dependendo do modelo.
Roteamento para CPUs mais novas: ao mapear gerações de processadores no fleet Kubernetes, a OpenAI descobriu que chips Broadwell antigos tinham ~20% pior TTFT e usavam ~2x mais CPU que Ice Lake. Mover tráfego para hardware mais novo foi uma otimização significativa.

Otimizações na inferência

Roteamento cache-aware: o roteador balanceia carga e prioriza enviar requests de volta à máquina que já tem o KV cache daquela conversa, evitando recomputação.
Gestão do KV cache: políticas de evicção são testadas contra traces de produção (não intuição), mantendo estado quente na GPU e movendo/evictando o frio.
Decodificação especulativa: um modelo draft pequeno propõe vários tokens; o modelo grande verifica todos em um único passo paralelo. A métrica-chave é o acceptance length médio.
Separação de prefill e decode: prefill (compute-heavy) e decode (memory-heavy) rodam em frotas separadas, cada uma configurada para seu gargalo. O KV cache é transferido entre elas.

Lições gerais

Os engenheiros da OpenAI destacam três princípios: manter o design simples (busca lexical em vez de embeddings para tool discovery, por exemplo); usar o próprio agente para otimizar seu stack (o Codex reescreveu grande parte da API que o serve); e otimizar end-to-end, pois nenhum ganho isolado é transformador - os grandes resultados vêm de encadear muitas pequenas otimizações.