Por que loops de agentes mais rápidos importam
A OpenAI diz que refez a infraestrutura por trás da Responses API para tornar fluxos de trabalho no estilo agente substancialmente mais rápidos, uma mudança voltada a reduzir o tempo que os usuários passam esperando enquanto ferramentas, modelos e chamadas de API vão e voltam durante tarefas complexas.
Em uma publicação técnica de 22 de abril, a empresa descreveu como sistemas como o Codex podem exigir dezenas de solicitações sequenciais para concluir uma única tarefa: o modelo decide o que fazer em seguida, uma ferramenta é executada no lado do cliente, o resultado é enviado de volta à API, e o ciclo se repete. Esse padrão faz com que até pequenas quantidades de sobrecarga se acumulem rapidamente.
Segundo a OpenAI, o problema de desempenho ficou mais visível à medida que a inferência em si ficou mais rápida. A empresa disse que os modelos carro-chefe anteriores na Responses API rodavam a cerca de 65 tokens por segundo. Para o GPT-5.3-Codex-Spark, a OpenAI mirou mais de 1.000 tokens por segundo usando hardware da Cerebras. Quando a geração do modelo ficou tão rápida, as partes mais lentas do loop deixaram de ser fáceis de esconder.
Do gargalo de inferência ao gargalo da API
A OpenAI divide a latência do agente em três grandes estágios: trabalho do serviço de API, inferência do modelo e tempo do lado do cliente. O lado do cliente ainda importa porque as ferramentas precisam ser executadas e o contexto precisa ser montado, mas a empresa disse que a própria camada de API havia se tornado um gargalo relevante.
Essa mudança exigiu uma estratégia de otimização diferente. Em vez de focar apenas na vazão de GPU, a OpenAI diz que começou a remover atrito ao longo do caminho da requisição. Por volta de novembro de 2025, a empresa lançou o que chamou de sprint de desempenho na Responses API. O trabalho incluiu armazenar em cache na memória os tokens renderizados e a configuração do modelo, reduzir saltos extras de rede chamando os serviços de inferência de forma mais direta e acelerar partes da pilha de segurança para que algumas conversas pudessem ser classificadas mais rapidamente.
Essas mudanças melhoraram o tempo até o primeiro token em quase 45%, segundo a empresa. Mas a OpenAI diz que isso ainda não era suficiente para expor totalmente os ganhos de velocidade da sua pilha de inferência mais nova.
A mudança para WebSocket
A maior mudança foi arquitetural: substituir uma série de chamadas síncronas separadas à API por uma conexão persistente com a Responses API usando WebSockets. Na prática, isso significa que cliente e API podem permanecer conectados durante todo o loop do agente, em vez de desmontar e reconstruir constantemente o estado da requisição.
A OpenAI diz que sessões persistentes permitiram manter informações úteis associadas à própria conexão. Isso reduziu trabalho repetido de configuração e ajudou o sistema a reutilizar o contexto de forma mais eficiente entre turnos. O resultado, segundo a empresa, foi uma melhora de cerca de 40% na velocidade do loop de agentes de ponta a ponta.
Para os usuários, o significado é direto. Se um agente de programação ou pesquisa precisa de muitas chamadas de ferramentas para concluir um trabalho, cortar a sobrecarga de cada ciclo pode ter um efeito maior do que acelerar apenas uma etapa. Um fluxo que antes parecia travado entre ações pode começar a parecer mais próximo de uma interação ao vivo.
O que a OpenAI otimizou
- Cache associado à conexão para evitar repetir trabalho caro de configuração.
- Menos saltos de rede desnecessários entre serviços de API e serviços de inferência.
- Verificações de segurança mais rápidas em partes do pipeline de moderação e classificação.
- Um canal WebSocket persistente para reduzir o custo do uso de ferramentas em múltiplos turnos.
A OpenAI enquadrou o trabalho como resposta a uma mudança mais ampla no setor: a inferência está ficando rápida o suficiente para que os sistemas ao redor passem a determinar cada vez mais a qualidade percebida do produto. Nesse ambiente, um modelo pode pensar rápido, mas a experiência ainda pode parecer lenta se as camadas de orquestração ficarem para trás.
Por que isso importa além do Codex
Embora a OpenAI tenha ilustrado o problema com o Codex, as implicações se estendem a qualquer agente que use ferramentas. Assistentes corporativos, sistemas de atendimento ao cliente, copilotos de pesquisa e agentes de software dependem de muitas interações pequenas em vez de uma única resposta longa do modelo. Assim, sessões persistentes e menor sobrecarga de orquestração podem importar tanto quanto o desempenho bruto em benchmarks.
A publicação também oferece um vislumbre de um cenário competitivo em mudança. Por anos, os fornecedores de modelos enfatizaram melhor raciocínio e janelas de contexto maiores. Cada vez mais, porém, eles também competem em engenharia de sistemas: vazão, responsividade, latência de segurança e quão eficientemente um modelo consegue permanecer no loop com ferramentas externas.
A mensagem da OpenAI é que a infraestrutura ao redor do modelo agora é um recurso do produto por direito próprio. Se as velocidades de inferência continuarem subindo, isso provavelmente se tornará ainda mais verdadeiro.
O sinal maior
A conclusão mais profunda não é apenas que WebSockets são mais rápidos do que chamadas síncronas repetidas. É que os produtos de agentes estão amadurecendo para se tornarem sistemas de software em tempo real cujo desempenho depende da coordenação entre APIs, caches, camadas de segurança e runtimes de ferramentas.
Isso faz desta atualização mais do que uma nota de engenharia. É um sinal de que os próximos ganhos em usabilidade de IA podem vir da redução do atrito entre etapas do modelo, e não apenas de tornar cada etapa individual mais inteligente. À medida que sistemas agênticos assumem tarefas mais longas e mais complexas, essa distinção pode determinar se eles parecem experimentais ou operacionais.
Este artigo é baseado na cobertura da OpenAI. Leia o artigo original.
Originally published on openai.com
