Stateless (LLM API)

Wat betekent stateless bij een LLM API?

Een taalmodel-API is stateless: hij houdt tussen twee oproepen niets over jou bij. Elke aanvraag komt binnen zonder voorgeschiedenis, het model leest de tekst die in die ene aanvraag zit, geeft een antwoord en vergeet alles weer. Stuur je twee keer exact dezelfde aanvraag, dan begint de tweede even blanco als de eerste.

Dat botst met hoe een chatassistent aanvoelt. Je stelt een vervolgvraag en hij weet duidelijk nog waarover je een minuut geleden bezig was. Het model onthield dat niet. De toepassing errond nam het hele gesprek tot dan toe en plakte het mee in de nieuwe aanvraag.

De documentatie van de Messages API van Anthropic zegt het zonder omweg: de API dient voor losse vragen of voor stateless gesprekken over meerdere beurten, en je geeft de vorige beurten telkens mee via de parameter messages. Het gesprek is iets wat je meestuurt, niet iets wat het model vasthoudt.

Waar het geheugen van een chatsessie echt zit

Dat geheugen zit in jouw toepassing en het gaat elke beurt opnieuw over de lijn. Een gesprek van drie beurten stuurt zoiets als dit:

[
  {"role": "user", "content": "Hoeveel klanten hebben in Q1 opgezegd?"},
  {"role": "assistant", "content": "Tweeënveertig, vooral op het starterspakket."},
  {"role": "user", "content": "En wat heeft ons dat gekost?"}
]

Alleen de laatste regel is nieuw. De twee erboven staan er zodat het model weet waar "dat" naar verwijst. Bij beurt vier gaan die drie berichten opnieuw mee, plus het nieuwe. Bij beurt dertig gaan er negenentwintig opnieuw mee.

Zo wordt ook duidelijk waarom het context window een plafond zet op de lengte van een gesprek en niet op de lengte van één bericht. Elke beurt die je toevoegt, reist mee met alle beurten daarna, tot het geheel niet meer past en de oudste berichten weg moeten of samengevat worden.

Waarom je factuur sneller stijgt dan je gebruik

Omdat je de historiek opnieuw meestuurt, betaal je ook opnieuw voor die historiek. De handleiding van OpenAI over conversation state is daar expliciet over: ook wanneer je met previous_response_id werkt, worden alle eerdere input tokens uit de keten nog altijd als input tokens gefactureerd.

Reken het eens na met ronde cijfers. Stel: een systeeminstructie van 2.000 tokens, en elke beurt voegt ongeveer 500 tokens vraag en antwoord toe.

• Beurt 1 stuurt 2.000 input tokens.

• Beurt 2 stuurt er 2.500.

• Beurt 20 stuurt er 11.500, meer dan vijf keer zoveel als de eerste.

Over die twintig beurten factureer je ruwweg 135.000 input tokens, terwijl er maar zo'n 10.000 tokens aan echt nieuwe tekst tussen jou en het model passeerden. Het verschil is dezelfde historiek die je keer op keer betaalt.

Waar het op neerkomt: verdubbel je de lengte van een gesprek, dan zit je dichter bij vier keer de kost dan bij twee keer. Als een zaakvoerder vraagt waarom de AI-factuur sneller steeg dan het aantal vragen dat de mensen stelden, is dit bijna altijd de verklaring. Er werd niet meer gewerkt met het model. Er werd in langere sessies gewerkt.

Server-side state en de Responses API

Nieuwere API's houden het gesprek wel voor je bij. Met de Responses API van OpenAI koppel je beurten aan elkaar door het id van het vorige antwoord mee te geven in previous_response_id, en de bijhorende Conversations API bewaart de gesprekstoestand als een blijvend object met een eigen identifier. Azure OpenAI ondersteunt diezelfde manier van koppelen en bewaart de antwoorddata standaard 30 dagen.

Hier is precisie belangrijk, want het leest gemakkelijk als een oplossing voor het kostenprobleem. Dat is het niet. De boekhouding verhuist naar de server, waardoor jouw toepassing het gespreksverslag niet meer hoeft rond te sturen of zelf bij te houden. Het model eronder leest nog steeds het volledige gesprek bij elke beurt, en volgens de zin die hierboven staat, betaal je dat ook nog steeds volledig.

Die server-side toestand is bovendien een keuze en geen nieuwe standaard. In de documentatie van Azure staat dat je met store=false gewoon een stateless aanvraag doet en de rest van de Responses API behoudt. Wat het aantal tokens wél omlaag haalt, is compactie: Azure biedt een optie context_management met een compact_threshold, die oudere beurten vervangt door een samengeperste versie zodra het gesprek boven die grens komt.

Wat prompt caching hieraan verandert

Prompt caching pakt niet het aantal hergebruikte tokens aan, maar hun prijs. Anthropic omschrijft het als hervatten vanaf een vast begin van je prompt, zodat een stabiel stuk (een lange systeeminstructie, een document, het eerdere deel van een gesprek) bij de volgende oproep niet helemaal opnieuw verwerkt wordt.

De tarieven maken het interessant. Op de API van Anthropic kost het wegschrijven naar de cache 1,25 keer het gewone inputtarief en het lezen uit de cache 0,1 keer, met een standaardlevensduur van vijf minuten die gratis opnieuw begint telkens de cache gebruikt wordt. Een gesprek dat in een vlot tempo doorloopt, betaalt voor zijn eigen historiek dus een tiende van de normale prijs.

Caching en stateless werken spreken elkaar niet tegen. Caching is net wat stateless werken betaalbaar houdt: de API krijgt nog altijd het hele gesprek bij elke oproep binnen, alleen rekent hij veel minder aan voor het stuk dat hij kort geleden al zag.

Waar moet je op letten bij het gebruik van stateless API's

De wachttijd groeit mee met het gespreksverslag, niet met de vraag. Een vervolgvraag van één regel sleept bij beurt dertig duizenden tokens historiek voor zich uit, en het model leest die allemaal voor het begint te antwoorden. Een chat die 's ochtends snel aanvoelde, voelt in de namiddag traag aan, alleen al daarom.

De kwaliteit zakt in lange sessies. Modellen halen het begin en het einde van een lange prompt beter terug dan het midden, dus een afspraak die je vijftig beurten geleden maakte, moet opboksen tegen alles wat er sindsdien bovenop kwam. Een nieuw gesprek starten is vaak een echte oplossing en geen omweg.

De kost per gebruiker valt niet af te leiden uit het aantal berichten. Twee mensen die evenveel berichten sturen, verschillen makkelijk een factor tien in verbruik, naargelang ze in korte stukjes werken of in één eindeloze draad. Meet en factureer op tokens.

Historiek inkorten is een ontwerpkeuze. De oudste berichten weggooien is goedkoop en verliest stilzwijgend instructies. Samenvatten is duurder en verliest details. Wat je ook kiest, beslis het bewust en zeg tegen het model wat het niet meer heeft.