OpenAI WebSockets: sneller bij agents met veel toolcalls

Een coding-agent die een bug zoekt, doet zelden één modelaanroep. Hij leest een bestand, draait een test, leest de foutmelding, past iets aan en draait de test opnieuw. Twintig of dertig rondes tussen model en tools zijn geen uitzondering. En bij elke ronde betaal je dezelfde overhead: een nieuwe HTTP-request, en een server die eerst de stand van het gesprek weer bij elkaar moet hebben voordat het model verder kan.

Op die overhead richt de WebSocket-modus van OpenAI's Responses API zich, die OpenAI eind februari 2026 aankondigde. De verbinding blijft open, en per beurt stuur je alleen wat er nieuw is. Volgens OpenAI loopt een workflow met meer dan twintig toolcalls daardoor ongeveer 40% sneller, van begin tot eind.

Wat is de WebSocket-modus van de Responses API?

WebSocket-modus is een manier om de Responses API aan te roepen via één langlevende WebSocket-verbinding, in plaats van met een losse HTTP-request per antwoord. Over die verbinding stuur je response.create-events met dezelfde inhoud als een gewone Responses-aanroep, alleen zonder de velden stream en background. Het antwoord komt terug als een stroom server-events.

Houd dit apart van de Realtime API. Die werkt al sinds de lancering in oktober 2024 met WebSockets (inmiddels ook met WebRTC) en is gemaakt voor spraak: audio erin, audio eruit, met zo weinig mogelijk vertraging. De WebSocket-modus van de Responses API is bedoeld voor agents die met tekst en tools werken, zoals coding-agents en orkestratieloops.

Waar zit de snelheidswinst?

Het model rekent over een WebSocket niet sneller. De winst zit in wat er tussen twee modelbeurten gebeurt.

In een agentloop over HTTP gaat een beurt zo: het model vraagt om een toolcall, jouw code voert die uit, en je stuurt een nieuwe request met het resultaat. Die request verwijst met previous_response_id naar het vorige antwoord, of stuurt het hele gesprek opnieuw mee. Hoe dan ook moet de server de toestand van het gesprek eerst terughalen.

In WebSocket-modus houdt OpenAI de meest recente antwoorden vast in een geheugencache die bij de verbinding hoort. Een vervolgbeurt hoeft die toestand niet van schijf te halen, en jij stuurt alleen de nieuwe input. Vaak is dat niet meer dan de uitkomst van de toolcall:

{
  "type": "response.create",
  "model": "…",
  "store": false,
  "previous_response_id": "resp_…",
  "input": [
    {
      "type": "function_call_output",
      "call_id": "call_…",
      "output": "{\"tests\": \"3 failed\"}"
    }
  ]
}

Hoeveel dat per beurt scheelt, hangt af van je context; OpenAI publiceert alleen totaalcijfers. Wel is duidelijk dat de besparing meegroeit met het aantal rondes. Een chatbot die één vraag beantwoordt, merkt er weinig van. Een agent die dertig keer een tool aanroept, spaart dertig keer dezelfde overhead uit. Daarom noemt OpenAI de modus vooral nuttig voor workflows met veel heen-en-weer tussen model en tools.

Hoeveel sneller is het in de praktijk?

De cijfers komen van OpenAI en een paar vroege gebruikers, niet van onafhankelijke metingen. OpenAI noemt ongeveer 40% snellere uitvoering bij workflows met meer dan twintig toolcalls. Volgens InfoQ meldde Vercel tot 40% minder latency, Cline 39% bij workflows over meerdere bestanden en Cursor tot 30%. OpenAI's eigen Codex heeft volgens OpenAI het grootste deel van zijn Responses-verkeer naar WebSocket-modus verplaatst.

Het belangrijke woord is "tot". Het gaat om de beste gevallen: lange ketens met veel kleine stappen. Doet jouw applicatie één aanroep per gebruikersvraag, dan levert een permanente verbinding vooral extra code op om te onderhouden.

Wat verandert er aan je agent-architectuur?

Een verbinding leeft maximaal een uur

Na 60 minuten moet je opnieuw verbinden. Een agent die langer bezig is, heeft dus herstel-logica nodig. De documentatie noemt drie routes: doorgaan met previous_response_id als het antwoord is opgeslagen, opnieuw beginnen met de volledige context, of verder gaan vanaf een gecomprimeerde versie van het gesprek via het endpoint /responses/compact.

De cache hoort bij de verbinding

Werk je met store: false of Zero Data Retention, dan bestaat het vorige antwoord alleen in die cache. Valt de verbinding weg, dan geeft een vervolgbeurt de fout previous_response_not_found. Wie om privacyredenen niets bij OpenAI laat opslaan, moet de context dus aan de eigen kant bijhouden om na een onderbreking verder te kunnen.

Meerdere taken over één verbinding

Eén verbinding kan tot 16 antwoorden tegelijk verwerken, verdeeld over stream_id's. Antwoorden met dezelfde stream_id lopen na elkaar, verschillende lopen parallel. Handig als een agent subtaken uitzet, maar je moet zelf bijhouden welk event bij welke taak hoort.

Voorverwarmen kan

Stuur je response.create met generate: false, dan zet OpenAI de systeemprompt en tooldefinities alvast klaar zonder iets te genereren. De eerste echte beurt bouwt daarop voort via previous_response_id.

WebSockets of WebRTC?

Die keuze speelt bij de Realtime API. OpenAI is daar duidelijk over: browser- en mobiele clients verbinden via WebRTC, omdat dat "in de meeste gevallen" robuuster is. Een backend die server-naar-server praat, gebruikt een WebSocket. Een WebSocket vanuit de browser kan met een kortlevend token, maar is niet de aanbevolen route.

Bij de Responses API kies je tussen gewone HTTP-requests en WebSocket-modus.

Wat gaat er mis als je dit in productie zet?

Herverbinden. Netwerken haperen en de verbinding stopt sowieso na een uur. Test expliciet wat je agent doet als de socket halverwege een toolcall wegvalt.
Toestand. Bij lange sessies moet je bepalen wat je bewaart, samenvat of weggooit, zeker met store: false.
Meten. Log events met tijdstempels, zonder gevoelige inhoud, zodat je ziet waar de tijd heen gaat: model, tool of netwerk. Pas dan weet je of de overstap iets oplevert voor jouw workload.

Tel dus eerst hoeveel rondes je agent per taak maakt. Zijn het er twee of drie, dan kun je dit overslaan. Zijn het er twintig of meer, dan is dit snelheidswinst die je krijgt zonder van model of prompt te wisselen.

OpenAI WebSockets: waarom agents met veel toolcalls sneller worden

Wat is de WebSocket-modus van de Responses API?

Waar zit de snelheidswinst?

Hoeveel sneller is het in de praktijk?