Ga naar inhoud

Twee keer betalen voor het contextvenster

Bijgewerkt September 1, 2026 · eerst gepubliceerd September 1, 2026

Kort antwoord: Een contextvenster wordt aangeprezen als capaciteit: 200,000 tokens, een miljoen tokens, ruimte voor alles wat je nodig hebt. Capaciteit is niet de factureringseenheid. Je betaalt voor wat je...

Een contextvenster wordt aangeprezen als capaciteit: 200,000 tokens, een miljoen tokens, ruimte voor alles wat je nodig hebt. Capaciteit is niet de factureringseenheid. Je betaalt voor wat je verstuurt, en in een gesprek met meerdere beurten stuur je het grootste deel elke beurt opnieuw.

Dat is de tweede betaling. Een document van 30,000 tokens dat aan het begin van een gesprek van twintig beurten wordt geladen, is niet 30,000 input-tokens. Het is dichter bij 600,000, want beurt twee stuurt het opnieuw mee, en beurt twintig ook.

De rekensom die niemand maakt

De kosten schalen met het kwadraat van de gesprekslengte, niet lineair. Een verdubbeling van het aantal beurten vervierdubbelt ruwweg de input-tokens, als de context zich blijft opstapelen. Teams die "kosten per bericht" modelleren en met het aantal berichten vermenigvuldigen, onderschatten lange sessies zwaar, en de fout groeit juist bij de gebruikers die je het liefst behoudt.

Er komt vaak nog een derde kostenpost bij: veel aanbieders rekenen voor verzoeken boven een long-contextdrempel een hoger tarief. Eén extra bijlage kan een verzoek over die grens duwen en de hele aanroep herprijzen, input en output, niet alleen de tokens die over de grens gingen.

Wat je moet meten

Volg de contextbenutting: verstuurde tokens ten opzichte van tokens die het model echt nodig had. Het is het dichtstbijzijnde wat dit vakgebied heeft aan een verspillingsmetriek. Volg input-tokens per gesprek, niet per verzoek, en kijk naar de p99 — daar zitten de sessies die twintig keer zoveel kosten als de mediaan.

Stel alerts in op verzoeken die de long-contextprijsdrempel overschrijden. Het is een sprong, geen glijdende schaal, en het ziet er in een dagtotaal nergens naar uit.

Drie oplossingen, de goedkoopste eerst

Cache het stabiele prefix. Als de systeemprompt en de geladen documenten tijdens een gesprek niet veranderen, maakt prompt-caching van de herhaalde kosten een fractie. Dit is de enige wijziging met het hoogste rendement voor elk product met meerdere beurten.

Kort de geschiedenis bewust in. Oudere beurten verdienen zelden hun herverzendprijs. Vat het eerdere deel van een lang gesprek samen en laat de ruwe beurten vallen; je houdt de draad en stopt met het betalen van de volle prijs ervoor.

Stuur het fragment, niet het corpus. Retrieval bestaat precies hiervoor. Dat het venster groot genoeg is voor een heel document, is geen argument om een heel document erin te stoppen.

Gerelateerd

Gerelateerd


Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit →

Terug naar finopsllm.com