Acelerar fluxos de trabalho agênticos com WebSockets na Responses API

Quando pede ao Codex para corrigir um bug, ele percorre a sua base de código à procura de ficheiros relevantes, lê-os para criar contexto, faz alterações e executa testes para verificar se a correção funcionou. Nos bastidores, isto significa dezenas de pedidos de ida e volta à Responses API: determinar a próxima ação do modelo, executar uma ferramenta no seu computador, enviar o resultado da ferramenta de volta para a API e repetir.

Todos estes pedidos podem somar minutos que os utilizadores passam à espera que o Codex conclua tarefas complexas. Do ponto de vista da latência, o loop do agente do Codex passa a maior parte do tempo em três fases principais: trabalho nos serviços da API (para validar e processar pedidos), inferência do modelo e tempo do lado do cliente (executar ferramentas e criar contexto do modelo). A inferência é a fase em que o modelo corre em GPUs para gerar novos tokens. No passado, executar a inferência de LLMs em GPUs era a parte mais lenta do loop agêntico, pelo que a sobrecarga dos serviços da API era fácil de ocultar. À medida que a inferência fica mais rápida, a sobrecarga acumulada da API numa execução agêntica torna-se muito mais notória.

Neste artigo, vamos explicar como tornámos loops de agentes que usam a API 40% mais rápidos de ponta a ponta, permitindo que os utilizadores experienciem o salto na velocidade de inferência de 65 para quase 1 000 tokens por segundo. Abordámos isto através de colocação em cache, eliminação de saltos de rede desnecessários, melhoria da nossa stack de segurança para sinalizar problemas rapidamente e — mais importante — a criação de uma forma de estabelecer uma ligação persistente à Responses API, em vez de ter de fazer uma série de chamadas síncronas à API.

Na Responses API, modelos principais anteriores como o GPT‑5 e o GPT‑5.2 corriam a cerca de 65 tokens por segundo (TPS). Para o lançamento do GPT‑5.3‑Codex‑Spark, um modelo rápido de programação, o nosso objetivo era ser uma ordem de grandeza mais rápido: mais de 1 000 TPS, possibilitado por hardware especializado da Cerebras otimizado para inferência de LLMs. Para garantir que os utilizadores podiam experienciar a verdadeira velocidade deste novo modelo, tivemos de reduzir a sobrecarga da API. 

Por volta de novembro de 2025, lançámos um sprint de desempenho na Responses API, implementando muitas otimizações na latência do caminho crítico para um único pedido: 

• Colocação em cache de tokens renderizados e da configuração do modelo em memória para evitar tokenização dispendiosa e chamadas de rede em respostas com vários turnos
• Reduzir a latência de saltos de rede eliminando chamadas a serviços intermédios (por exemplo, resolução de processamento de imagens) e chamando diretamente o próprio serviço de inferência
• Melhorar a nossa stack de segurança para podermos executar determinados classificadores e sinalizar conversas mais depressa

Com estas melhorias, observámos uma melhoria de quase 45% no tempo até ao primeiro token (TTFT) — o que reflete o quão responsiva a API parece —, mas estas melhorias ainda não eram suficientemente rápidas para o GPT‑5.3‑Codex‑Spark. Mesmo com estas melhorias, a sobrecarga da Responses API era demasiado grande face à velocidade do modelo — isto é, os utilizadores tinham de esperar pelos CPUs que executam a nossa API antes de poderem usar as GPUs que servem o modelo.

O problema mais profundo era estrutural: tratávamos cada pedido do Codex como independente, processando o estado da conversa e outro contexto reutilizável em cada pedido de seguimento. Mesmo quando a maior parte da conversa não tinha mudado, continuávamos a pagar pelo trabalho associado a todo o histórico. À medida que as conversas ficavam mais longas, esse processamento repetido tornava-se mais caro.

Para otimizar o design, repensámos o protocolo de transporte: seria possível manter uma ligação persistente e colocar o estado em cache, em vez de estabelecer uma nova ligação por HTTP e enviar todo o histórico da conversa em cada pedido de seguimento? A ideia era enviar apenas a informação nova que exigisse validação e processamento e colocar em cache o estado reutilizável em memória durante a vida útil da ligação. Isto reduziria a sobrecarga de trabalho redundante.

Considerámos algumas abordagens diferentes, incluindo WebSockets e streaming bidirecional em gRPC. Optámos por WebSockets porque, enquanto protocolo simples de transporte de mensagens, os utilizadores não teriam de alterar as estruturas de entrada e saída da Responses API. Era amigável para developers e encaixava na nossa arquitetura existente com pouca perturbação.

O primeiro protótipo de WebSocket mudou o que achávamos possível em termos de latência na Responses API. Um engenheiro da equipa do Codex, com profunda experiência em toda a stack da API, reuniu um protótipo ao executar um agente do Codex durante a noite.

Neste protótipo, execuções agênticas foram modeladas como uma única Response de longa duração. Usando funcionalidades do asyncio, a Responses API bloqueava de forma assíncrona no ciclo de amostragem depois de ser amostrada uma chamada de ferramenta, e a Responses API enviava um evento response.done de volta para o cliente. Depois de executar a chamada de ferramenta, os clientes enviavam de volta um evento response.append com o resultado da ferramenta, o que desbloqueava o ciclo de amostragem e permitia que o modelo continuasse.

Uma analogia aqui é tratar a chamada de ferramenta local como uma chamada de ferramenta alojada. Quando o modelo chama a pesquisa na Web, o loop de inferência bloqueia, chama um serviço de pesquisa na Web e coloca a resposta do serviço no contexto do modelo. No nosso design, fizemos o mesmo; mas, em vez de chamar um serviço remoto, enviámos a chamada de ferramenta do modelo para o cliente, de volta através do WebSocket. Quando o cliente respondia, colocávamos a resposta da chamada de ferramenta do cliente no contexto e continuávamos a amostrar.

Este design foi extremamente eficaz porque eliminou trabalho repetido na API ao longo de uma execução do agente. Podíamos fazer o trabalho pré-inferência uma vez, pausar para a execução da ferramenta e fazer o trabalho pós-inferência uma vez no final.

Infelizmente, isso teve o custo de um formato de API menos familiar e mais complexo. Queríamos que os developers conseguissem adicionar suporte para WebSockets sem terem de reescrever a sua integração com a API em torno de um novo modo de interação.

Na versão que lançámos, voltámos a um formato familiar: continuar a usar response.create com o mesmo body e usar previous_response_id para continuar o contexto da conversa a partir do estado da response anterior.

Numa ligação WebSocket, o servidor mantém uma cache em memória, com âmbito da ligação, do estado da response anterior. Quando uma response.create de seguimento inclui previous_response_id, vamos buscar esse estado à cache, em vez de reconstruirmos toda a conversa de raiz.

Esse estado em cache inclui:

• O objeto response anterior
• Itens de entrada e de saída anteriores
• Definições de ferramentas e namespaces
• Artefactos de amostragem reutilizáveis, como tokens previamente renderizados

Ao reutilizar o estado em memória da response anterior, conseguimos implementar várias otimizações importantes:

• Fazer com que alguns dos nossos classificadores de segurança e validadores de pedidos processem apenas a nova entrada, e não todo o histórico em cada pedido
• Manter uma cache em memória de tokens renderizados, à qual vamos anexando conteúdo, para podermos evitar tokenização desnecessária
• Reutilizar a nossa lógica bem-sucedida de resolução/encaminhamento de modelos entre pedidos 
• Sobrepor trabalho pós-inferência não bloqueante, como faturação, com pedidos subsequentes

O objetivo era aproximar-nos o mais possível do protótipo com sobrecarga mínima, mas com um formato de API que os developers já compreendiam e em torno do qual já tinham desenvolvido.

Após um sprint de dois meses a criar o modo WebSocket, lançámos uma alpha com startups-chave de agentes de programação para que pudessem integrá-lo na sua infraestrutura e aumentar o tráfego em segurança. Os utilizadores alpha adoraram, reportando melhorias até 40%⁠(abre numa nova janela) nos seus fluxos de trabalho agênticos. Com base no feedback positivo da alpha, estávamos prontos para lançar.

Os resultados do lançamento foram imediatos. O Codex migrou rapidamente a maioria do seu tráfego da Responses API para o modo WebSocket, observando melhorias significativas de latência. Para o GPT‑5.3‑Codex‑Spark, atingimos a nossa meta de 1 000 TPS e vimos picos até 4 000 TPS, mostrando que a Responses API conseguia acompanhar uma inferência muito mais rápida em tráfego real de produção. O impacto também se fez sentir rapidamente na comunidade de developers:

• O Codex migrou rapidamente a maioria do seu tráfego para WebSockets. Utilizadores do Codex a executar os modelos mais recentes, como o GPT‑5.3‑Codex⁠(abre numa nova janela), GPT‑5.4⁠(abre numa nova janela), e versões posteriores beneficiam todos da aceleração do modo WebSocket.
• A Vercel integrou o modo WebSocket no AI SDK e viu a latência diminuir até 40%⁠(abre numa nova janela).
• Os fluxos de trabalho multi-ficheiro do Cline são 39% mais rápidos⁠(abre numa nova janela).
• Os modelos da OpenAI no Cursor ficaram até 30% mais rápidos⁠(abre numa nova janela).

O modo WebSocket é uma das novas capacidades mais significativas na Responses API desde o seu lançamento em março de 2025. Passámos da ideia à execução em produção em apenas algumas semanas, através de uma colaboração estreita entre as equipas de API e de Codex da OpenAI. Não só melhora drasticamente a latência de execução do agente, como também responde a uma necessidade crescente para os builders: à medida que a inferência do modelo fica mais rápida, os serviços e sistemas à volta da inferência também têm de acelerar para transferir estes ganhos para os utilizadores.