Acelerando fluxos de trabalho com agentes com WebSockets na Responses API

Quando você pede ao Codex para corrigir um bug, ele percorre sua base de código em busca de arquivos relevantes, lê esses arquivos para construir contexto, faz edições e executa testes para verificar se a correção funcionou. Nos bastidores, isso significa dezenas de requisições de ida e volta para a 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.

Todas essas requisições podem somar minutos que os usuários passam esperando o Codex concluir tarefas complexas. Do ponto de vista de latência, o loop do agente do Codex passa a maior parte do tempo em três etapas principais: trabalho nos serviços da API (para validar e processar requisições), inferência do modelo e tempo do lado do cliente (executando ferramentas e construindo o contexto do modelo). Inferência é a etapa em que o modelo roda em GPUs para gerar novos tokens. No passado, rodar inferência de LLM em GPUs era a parte mais lenta do loop com agentes, então a sobrecarga dos serviços da API era fácil de esconder. À medida que a inferência fica mais rápida, a sobrecarga cumulativa da API em uma execução com agentes fica muito mais perceptível.

Neste post, vamos explicar como deixamos loops de agentes usando a API 40% mais rápidos de ponta a ponta, permitindo que os usuários experimentem o salto na velocidade de inferência de 65 para quase 1.000 tokens por segundo. Fizemos isso com cache, eliminando saltos de rede desnecessários, melhorando nossa stack de segurança para sinalizar problemas rapidamente e — mais importante — criando uma forma de estabelecer uma conexão persistente com a Responses API, em vez de ter que fazer uma série de chamadas síncronas à API.

Na Responses API, modelos carro-chefe anteriores como GPT‑5 e GPT‑5.2 rodavam 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, nossa meta era ser uma ordem de magnitude mais rápido: mais de 1.000 TPS, viabilizados por hardware especializado da Cerebras otimizado para inferência de LLM. Para garantir que os usuários pudessem experimentar a verdadeira velocidade desse novo modelo, tivemos que reduzir a sobrecarga da API. 

Por volta de novembro de 2025, iniciamos um sprint de performance na Responses API, implementando várias otimizações na latência do caminho crítico de uma única requisição: 

• Fazer cache de tokens renderizados e da configuração do modelo em memória para pular tokenização cara e chamadas de rede em respostas de múltiplos turnos
• Reduzir a latência de saltos de rede eliminando chamadas para serviços intermediários (por exemplo, resolução de processamento de imagem) e chamando diretamente o próprio serviço de inferência
• Melhorar nossa stack de segurança para que pudéssemos rodar certos classificadores e sinalizar conversas mais rapidamente

Com essas melhorias, vimos uma melhora de quase 45% no tempo até o primeiro token (TTFT) — que reflete o quão responsiva a API parece — mas essas melhorias ainda não foram rápidas o suficiente para o GPT‑5.3‑Codex‑Spark. Mesmo com essas melhorias, a sobrecarga da Responses API era grande demais em relação à velocidade do modelo — isto é, os usuários tinham que esperar pelas CPUs que rodam nossa API antes de poderem usar as GPUs que servem o modelo.

O problema mais profundo era estrutural: tratávamos cada requisição do Codex como independente, processando o estado da conversa e outro contexto reutilizável em cada requisição de acompanhamento. Mesmo quando a maior parte da conversa não mudava, ainda pagávamos pelo trabalho ligado ao histórico completo. À medida que as conversas ficavam mais longas, esse processamento repetido ficava mais caro.

Para enxugar o design, repensamos o protocolo de transporte: será que poderíamos manter uma conexão persistente e fazer cache do estado, em vez de estabelecer uma nova conexão via HTTP e enviar o histórico completo da conversa em cada requisição de acompanhamento? A ideia era enviar apenas as novas informações que exigem validação e processamento e manter em memória, em cache, o estado reutilizável durante toda a vida útil da conexão. Isso reduziria a sobrecarga de trabalho redundante.

Consideramos algumas abordagens diferentes, incluindo WebSockets e streaming bidirecional via gRPC. Escolhemos WebSockets porque, como um protocolo simples de transporte de mensagens, os usuários não precisariam mudar os formatos de entrada e saída da Responses API. Ele era amigável para desenvolvedores e se encaixava na nossa arquitetura existente com pouca ruptura.

O primeiro protótipo com WebSocket mudou o que achávamos possível em termos de latência da Responses API. Um engenheiro da equipe do Codex, com profunda expertise em toda a stack da API, montou um protótipo rodando um agente do Codex durante a noite.

Nesse protótipo, execuções com agentes foram modeladas como uma única Response de longa duração. Usando recursos do asyncio, a Responses API bloquearia de forma assíncrona no loop de amostragem após uma chamada de ferramenta ser amostrada, e a Responses API enviaria um evento response.done de volta ao cliente. Depois de executar a chamada de ferramenta, os clientes enviariam de volta um evento response.append com o resultado da ferramenta, o que desbloqueava o loop de amostragem e deixava o modelo continuar.

Uma analogia aqui é tratar a chamada de ferramenta local como uma chamada de ferramenta hospedada. Quando o modelo chama a busca na web, o loop de inferência bloqueia, chama um serviço de busca na web e coloca a resposta do serviço no contexto do modelo. No nosso design, fizemos a mesma coisa; mas, em vez de chamar um serviço remoto, enviamos a chamada de ferramenta do modelo para o cliente de volta pelo WebSocket. Quando o cliente respondia, colocávamos a resposta da chamada de ferramenta do cliente no contexto e continuávamos a amostrar.

Esse design foi extremamente eficaz porque eliminou o trabalho repetido da API ao longo de uma execução com agentes. 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 complicado. Queríamos que os desenvolvedores pudessem simplesmente adicionar suporte a WebSocket sem precisar reescrever a integração com a API em torno de um novo modo de interação.

Para a versão que lançamos, voltamos a um formato familiar: continuar usando response.create com o mesmo body e usar previous_response_id para dar continuidade ao contexto da conversa a partir do estado da Response anterior.

Em uma conexão WebSocket, o servidor mantém um cache em memória, com escopo da conexão, do estado de responses anteriores. Quando um response.create de acompanhamento inclui previous_response_id, buscamos esse estado no cache em vez de reconstruir toda a conversa do zero.

Esse estado em cache inclui:

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

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

• Fazer com que alguns de nossos classificadores de segurança e validadores de requisições processem apenas a nova entrada, não o histórico completo a cada vez
• Manter um cache em memória de tokens renderizados ao qual vamos anexando conteúdo, para que possamos pular tokenização desnecessária
• Reutilizar nossa lógica bem-sucedida de resolução/roteamento de modelos entre requisições 
• Sobrepor trabalho pós-inferência não bloqueante, como cobrança, com requisições subsequentes

O objetivo era chegar o mais perto possível do protótipo de sobrecarga mínima, mas com um formato de API que os desenvolvedores já entendiam e sobre o qual já tinham construído.

Depois de um sprint de dois meses construindo o modo WebSocket, lançamos uma versão alfa com startups-chave de agentes de programação para que elas pudessem integrá-lo à sua infraestrutura e escalar o tráfego com segurança. Os usuários da versão alfa adoraram, relatando melhorias de até 40%⁠(abre em uma nova janela) em seus fluxos de trabalho com agentes. Com o feedback positivo da alfa, estávamos prontos para lançar.

Os resultados do lançamento foram imediatos. O Codex rapidamente direcionou a maior parte do seu tráfego da Responses API para o modo WebSocket, vendo melhorias significativas de latência. Para o GPT‑5.3‑Codex‑Spark, atingimos nossa meta de 1.000 TPS e vimos picos de 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 apareceu rapidamente na comunidade de desenvolvedores:

• O Codex rapidamente direcionou a maior parte do seu tráfego para WebSockets. Usuários do Codex usando os modelos mais recentes, como GPT‑5.3‑Codex⁠(abre em uma nova janela), GPT‑5.4⁠(abre em uma nova janela), e além, todos se beneficiam do ganho de velocidade do modo WebSocket.
• A Vercel integrou o modo WebSocket ao AI SDK e viu a latência diminuir em até 40%⁠(abre em uma nova janela).
• Os fluxos de trabalho de múltiplos arquivos do Cline são 39% mais rápidos⁠(abre em uma nova janela).
• Os modelos da OpenAI no Cursor ficaram até 30% mais rápidos⁠(abre em uma nova janela).

O modo WebSocket é uma das novas capacidades mais significativas da Responses API desde seu lançamento em março de 2025. Fomos da ideia à execução em produção em apenas algumas semanas, graças à colaboração próxima entre as equipes de API e Codex da OpenAI. Ele não só melhora drasticamente a latência do rollout de agentes como também atende a uma necessidade crescente para quem está construindo: à medida que a inferência do modelo fica mais rápida, os serviços e sistemas ao redor da inferência também precisam acelerar para transferir esses ganhos aos usuários.