De schatting die nooit klopt met de factuur
De prijspagina en de factuur beschrijven twee verschillende dingen. De prijspagina beschrijft een token: $5 per miljoen op Claude Opus 4.8, een fractie van een cent voor een klantvraag. Je factuur beschrijft hoe je product het model werkelijk aanroept, en dat pad is langer, en veel duurder, dan de token waarop je de prijs baseerde. Niemand rekent je te veel aan.
De kloof is niet één mysterieuze kostenpost. Het is een kleine set specifieke, benoembare vermenigvuldigers, en zodra je ze kunt zien, kun je ervoor budgetteren. Hier zijn ze, één voor één, uitgerekend op een supportchatbot die draait op Claude Opus 4.8.
| Item | Bedrag |
|---|---|
| Je schatting | $200 |
| Context over meerdere beurten | + $1,260 |
| Je factuur | $1,460 |
Wat je begroot versus wat je gefactureerd krijgt
Support-chatbot · 10,000 gesprekken / maand · Claude Opus 4.8 ($5 / $25 per 1M)
Gemodelleerd, geen offerte. Aannames: een gesprek van 4 beurten; een systeemprompt van 1,500 tokens plus opgehaalde kennis die bij elke beurt opnieuw wordt verstuurd; een klantbericht van ~500 tokens en een antwoord van ~700 tokens per beurt. Dat is ~15,200 input- en ~2,800 output-tokens per gesprek, of $760 input + $700 output over 10,000 gesprekken. Je cijfers zullen verschillen; de vorm niet.
De zorgvuldige eigenaar schat $200 per maand: 10,000 gesprekken, elk een korte vraag en een langer antwoord, eerlijk geprijsd op $5 input en $25 output. De factuur is $1,460. De eigenaar die alleen de klantvraag telde - inputtokens, één beurt - budgetteerde $25 en zat er bijna zestig keer naast. Geen van beiden deed iets fout met rekenen. Ze schatten de verkeerde hoeveelheid.
Val 1: je prijsde de vraag, maar het antwoord kost vijf keer meer
Op elk huidig Claude-model kosten outputtokens precies vijf keer zoveel als inputtokens. Fable 5 is $10 in en $50 uit. Opus 4.8 is $5 en $25. Sonnet 5 is $3 en $15 (op een introductietarief van $2 en $10 tot en met 31 augustus 2026). De verhouding beweegt nooit, en die wijst de verkeerde kant op voor hoe mensen schatten: we prijzen datgene wat we typen, wat kort is, en vergeten datgene wat het model terugschrijft, wat lang is.
In het supportvoorbeeld is de klantvraag ongeveer 500 tokens en het antwoord ongeveer 700. Die antwoorden alleen al - 700 tokens keer 10,000 gesprekken tegen $25 per miljoen - komen neer op $175 per maand, wat al zeven keer de volledige input-only schatting van $25 is. Als je product samenvat, opstelt, uitlegt of code schrijft, is de outputkant waar je geld zit, en het is de kant die de sticker-prijs stilletjes te licht inschat.
Val 2: een gesprek is geen vraag
Dit is de grote, en het is de val die een nette schatting verandert in een verrassende factuur. De API heeft geen geheugen. Hij onthoudt je laatste beurt niet. Dus om een gesprek voort te zetten, stuurt je applicatie het hele ding opnieuw bij elke afzonderlijke beurt: de systeemprompt, welke kennis je ook hebt opgehaald, en het volledige heen-en-weer tot dan toe. Je wordt voor al dat opnieuw in rekening gebracht, telkens wanneer het model spreekt.
Loop het supportgesprek langs vier beurten. Een systeemprompt en kennisfragment van 1,500 tokens rijden mee bij elke beurt. Tegen beurt vier stuur je ook drie eerdere vragen en drie eerdere antwoorden opnieuw. Tel het op en één gesprek van vier beurten verbruikt ongeveer 15,200 inputtokens, niet de 500 die je voor ogen had toen je naar één vraag keek. Dat is ruwweg dertig keer de input die je schatte, en het is waarom opnieuw verzonden context, niet het model dat je koos, de grootste regel op de bovenstaande factuur is.
Het stapelt ook op. Omdat elke beurt opnieuw betaalt voor alle beurten ervoor, groeien de totale kosten van een gesprek met het kwadraat van de lengte, niet in een rechte lijn. Een gesprek van tien beurten kost geen tien keer een gesprek van één beurt, het kost veel meer. Een chatfunctie die goedkoop voelt in een demo van drie berichten kan zich heel anders gedragen zodra echte gebruikers zich nestelen in threads van twintig berichten.
Val 3: het denken waarvoor je betaalt maar dat je nooit ziet
Het model redeneert voordat het antwoordt, en dat redeneren wordt als output in rekening gebracht, of je het nu ziet of niet. Op Fable 5 staat dit denken altijd aan: een verzoek dat een net antwoord van 500 tokens teruggeeft, kan eerst enkele duizenden tokens aan redeneren hebben besteed, en elk van die onzichtbare tokens wordt geprijsd tegen het outputtarief van $50. Het antwoord op je scherm is het kleine deel van waarvoor je betaalde.
Dezelfde hendel bestaat op de Opus-familie via de effort-instelling. Zet effort omhoog en het model denkt langer en roept meer tools aan, waarbij het meer tokens besteedt voor meer betrouwbaarheid. Zet het omlaag en het beweegt sneller en goedkoper. Geen van beide is verkeerd, maar als je nooit een niveau koos, betaal je wat de standaard ook kost. Als je een altijd-denkend model afweegt tegen een standaardmodel, is de eerlijke vergelijking niet de twee prijslijsten maar de twee tokenaantallen die een echte taak oplevert - wat precies is waar onze Fable 5 versus Opus 4.8 uiteenzetting op ingaat.
Val 4: dezelfde tekst, geteld als meer tokens
Hier is degene die zelfs zorgvuldige teams betrapt. Wanneer je overstapt naar een nieuwer model, kan zijn tokenizer - het ding dat tekst in factureerbare tokens hakt - dezelfde tekst als meer tokens tellen dan voorheen. Je veranderde een modelstring, voegde geen functies toe, hield exact dezelfde prijs per token aan, en de factuur ging toch omhoog.
| Model | Bedrag |
|---|---|
| Sonnet 4.6 | $900 |
| Sonnet 5 | $1,170 |
| Verschil | + $270 |
Zelfde tekst, zelfde prijslijst, een hogere rekening
Eén maandelijks werklast op de identieke prijslijst ($3 / $15 per 1M)
Het gepubliceerde tokenizer-drift-cijfer (~30%) toegepast op een vast volume. Dezelfde documentenset tokeniseert tot ~100M tokens op Sonnet 4.6 (50M input + 50M output = $150 + $750 = $900) en tot ~130M op Sonnet 5 (65M + 65M = $195 + $975 = $1,170). Zelfde woorden, zelfde prijslijst, +$270 per maand.
Sonnet 5 telt ruwweg 30 procent meer tokens dan Sonnet 4.6 voor dezelfde woorden. De Opus 4.7 tokenizer draait ergens tussen gelijk en ongeveer 35 procent zwaarder dan Opus 4.6, afhankelijk van de inhoud. Dus een upgrade die er gratis uitziet op de prijspagina, kan een factuur stilletjes met een derde verhogen. De oplossing is niet om upgraden te vermijden - de nieuwere modellen zijn het meestal waard - maar om je echte tokenaantallen opnieuw te meten na elke overstap en opnieuw te budgetteren vanuit de nieuwe cijfers, in plaats van aan te nemen dat een identieke tariefkaart een identieke factuur betekent.
Val 5: de pogingen die je nooit ziet
Het schone verzoek-en-antwoord dat je je voorstelt, is het gelukkige pad. In productie zijn er tijdelijke fouten die opnieuw worden geprobeerd, veiligheidsweigeringen, en agent-loops die een tool aanroepen, het resultaat lezen, en het model opnieuw aanroepen. Elk van die extra heen-en-weer-ritten is meer tokens op de meter, en geen ervan verschijnt in je mentale model van "één vraag, één antwoord".
Er is hier echte nuance de moeite waard om te kennen. Op Fable 5 wordt een verzoek dat wordt geweigerd voordat het enige output produceert, helemaal niet in rekening gebracht, terwijl een verzoek dat halverwege de stream wordt geweigerd het deel factureert dat al gestreamd is. Retries zijn goedkoop om te maken en gemakkelijk ongelimiteerd te laten, dus een kleine bug - een agent die één keer meer loopt dan zou moeten, een retry-beleid zonder plafond - duikt op als een regelpost, niet als een stack trace.
De hele verborgen factuur op één pagina
Zes vermenigvuldigers zitten tussen een LLM-prijslijst en de factuur. Vijf ervan leven in hoe je het model aanroept; de zesde leeft in hoe je het werk inplant. Geen ervan is een truc of een verborgen kost, en elk heeft een specifieke hendel die het afvlakt.
| Verborgen kost | Wat het veroorzaakt | Typische omvang | De hendel die het afvlakt |
|---|---|---|---|
| Output geprijsd op 5x input | Elk antwoord dat het model schrijft | Meestal het grootste deel van de factuur | Verkort antwoorden, begrens max output, verlaag het effort-niveau |
| Opnieuw verzonden context | De API is stateloos, dus geschiedenis wordt bij elke beurt opnieuw verzonden | Totale gesprekskosten groeien met het kwadraat van het aantal beurten | Prompt caching (leesbewerkingen tegen ~0.1x op de gecachte prefix) |
| Denktokens | Altijd-aan redeneren (Fable 5) of een hoge effort-instelling | Kan het antwoord dat je werkelijk ziet in het niet doen vallen | Stem effort af op de taak, gebruik een niet-denkende tier voor eenvoudig werk |
| Tokenizer-drift | Een nieuwer model telt dezelfde tekst als meer tokens | ~+30% Sonnet 4.6 naar Sonnet 5 | Meet tokenaantallen opnieuw na elke modelwissel, budgetteer dan opnieuw |
| Retries en tool-loops | Tijdelijke fouten, weigeringen, agent-heen-en-weer-ritten | Elke mislukte poging kan opnieuw factureren | Idempotentie plus backoff, houd tool-loops begrensd |
| Niet-gebatcht achtergrondwerk | Latentie-tolerante taken op de live API draaien | Volle prijs voor werk dat kon wachten | Batch API (-50% op alles) |
Het grootste deel van de factuur is optioneel
Lees die tabel opnieuw en let op de rechterkolom. Bijna elke vermenigvuldiger heeft een korting die ertegenover staat, en de drie grootste zijn niet "stap over naar een goedkoper model" - het zijn dingen die je kunt doen op het model dat je al draait.
- Prompt caching pakt de opnieuw verzonden context rechtstreeks aan. Die systeemprompt van 1,500 tokens die je bij elke beurt verstuurt, kan één keer worden gecacht en dan bij elke latere beurt worden teruggelezen tegen ruwweg een tiende van de inputprijs. Er is een kleine eenmalige toeslag om de cache te schrijven, dus het betaalt zich precies uit wanneer je dezelfde context veel hergebruikt, wat precies is wat een chatfunctie doet.
- De Batch API haalt 50 procent van alles af voor werk dat een beetje latentie kan verdragen - samenvattingen 's nachts, bulkclassificatie, alles waar een gebruiker niet in realtime op wacht.
- Het juist dimensioneren van het model en de output - de gemakkelijke helft van je verkeer naar een goedkopere tier sturen, antwoordlengte begrenzen, bewust een effort-niveau kiezen - snoeit de 5x outputkant van de factuur zonder één antwoord te veranderen waar gebruikers om geven.
Gestapeld in de juiste volgorde kunnen deze een factuur met meer dan de helft snijden zonder de ervaring te verlagen, wat een heel artikel op zich is. Als je nog in het stadium bent van beslissen of een AI-functie überhaupt de moeite waard is om te bouwen, is het eerlijke uitgangspunt hetzelfde als waar dit stuk voor pleit: schat vanuit het echte aanroeppad, en vergelijk dat dan tegen wat de taak waard is. Onze gids voor praktische AI-automatisering voor kleinere bedrijven is een goede volgende halte.
