Waarom output-tokens bij LLM API's 4-8x meer kosten dan input-tokens

Kijk naar de prijspagina van elke grote LLM API — OpenAI, Anthropic, Google, maakt niet uit — en je ziet steeds dezelfde vorm: output-tokens kosten een aantal keer meer dan input-tokens. En dat is geen kleine meerprijs. Bij de huidige modellen ligt de verhouding consistent tussen 4x en 8x. Dat is geen prijsgrilligheid van één specifieke leverancier; het is een direct gevolg van hoe deze modellen daadwerkelijk draaien.

De echte reden: input is parallel, output is sequentieel

Het verwerken van input-tokens — je prompt, systeembericht, gespreksgeschiedenis — gebeurt in één enkele forward pass. Het model leest de hele input in één keer en berekent attention over alles tegelijk, parallel. Moderne GPU’s zijn extreem goed in dit soort gebundelde, parallelle berekeningen, dus een prompt van 3.000 tokens en een prompt van 300 tokens kosten niet evenredig zoveel meer rekentijd als hun tokenaantallen zouden doen vermoeden — de overhead van het model één keer laten draaien is de dominante kostenpost, niet de lengte van wat het leest.

Output-tokens genereren is fundamenteel anders. Elk nieuw token hangt af van elk voorgaand token, inclusief de tokens die het model net zelf heeft gegenereerd — dus token 500 van een antwoord kan pas berekend worden als token 499 al bestaat. Dat dwingt een sequentiële lus af: één forward pass per output-token, na elkaar uitgevoerd, zonder mogelijkheid om over de reeks te parallelliseren. 500 output-tokens produceren betekent het model 500 keer achter elkaar laten draaien, niet één keer.

Die asymmetrie in rekenkracht — één parallelle pass voor input, N sequentiële passes voor N output-tokens — is waarom de prijzen van elke grote aanbieder er hetzelfde uitzien, ongeacht bedrijf, modelarchitectuur of regio. Het is minder een zakelijke beslissing dan een directe doorberekening van de onderliggende rekenkosten.

Wat dit betekent voor je prompts

De praktische conclusie is bot: een uitgebreid modelantwoord kost onevenredig veel meer dan een lange prompt met een kort antwoord, zelfs als het totale tokenaantal vergelijkbaar lijkt. Als je je API-uitgaven wilt verlagen, levert het inkorten van de output meestal per token meer op dan het inkorten van de input.

Een paar concrete hendels:

• Beperk de responslengte expliciet. Een instructie in het systeemprompt zoals “antwoord in één alinea” of een max_tokens-limiet doet meer voor de kosten dan het inkorten van je eigen prompt.
• Vraag om gestructureerde output in plaats van proza. Een JSON-object met drie velden is vaak veel korter dan hetzelfde uitgelegd in zinnen, en net zo bruikbaar verderop in de pipeline.
• Leg niet te veel uit in het systeemprompt om op output te besparen. Een langer, preciezer systeemprompt (input, goedkoop) dat betrouwbaar een kort, correct antwoord oplevert (output, duur) is meestal een betere ruil dan een korte, vage prompt waardoor het model gaat hedgen met een lang antwoord.
• Gebruik een goedkoper model voor grootschalige, laagcomplexe output. Als een taak geen frontier-model-redenering nodig heeft — classificatie, extractie, korte antwoorden — dan is de output-prijs van een budgetmodel vaak een orde van grootte lager.

Het werkelijke bedrag berekenen

De verhouding verklaart waarom output meer kost, maar het exacte bedrag hangt af van welk model je gebruikt en hoeveel tokens elke kant van een verzoek daadwerkelijk verbruikt. Omdat de input/output-verdeling — en de vermenigvuldigingsfactor daartussen — echt per model verschilt (een budgetmodel en een topmodel hanteren niet dezelfde verhouding), is de enige betrouwbare manier om je werkelijke kosten te kennen: je eigen cijfers per model invullen.

De LLM API Pricing Calculator van CodeKitHub doet precies dat: kies je model, voer je input- en output-tokenaantallen in, en hij toont de inputkosten, outputkosten en het totaal — plus een maandschatting als je ongeveer weet hoeveel verzoeken je gaat doen. Als je niet zeker weet hoeveel tokens je daadwerkelijke prompt gebruikt, geeft de Token Counter tool het exacte aantal met de echte tokenizer, in plaats van een ruwe schatting op basis van tekens.

Beide draaien volledig in je browser — geen API-key, geen account, er wordt niets naar elders verstuurd.