Downgraden is de laatste hefboom, niet de eerste
Overstappen van Opus 4.8 naar Sonnet 4.6 verlaagt de prijs per token met 40 procent, en het genereert elk antwoord dat je product geeft opnieuw. Dat is de afweging waar de meeste teams als eerste naar grijpen, en meestal is die voorbarig, omdat twee grotere kortingen al op de prijslijst staan voor het model dat je vandaag draait: prompt caching leest herhaalde context tegen ongeveer een tiende van de inputprijs, en de Batch API neemt een vaste halvering op alles wat kan wachten. Geen van beide verandert ook maar één antwoord. Ze stapelen. En als je ze eerst toepast, is de downgrade waar je je op schrap zette vaak niet meer nodig.
Om de cijfers eerlijk te houden blijven we werken aan dezelfde patiënt: de support-chatbot waarvan we de $1,460-factuur in deel één uit elkaar hebben gehaald. Vier hefbomen, op volgorde toegepast, geen modelwissel voor het verkeer dat ertoe doet:
| Item | Bedrag |
|---|---|
| Factuur deel 1 | $1,460 |
| + prompt caching | $1,332 |
| + routing | $799 |
| + output trim | $673 |
De chatbot uit deel 1, vier hefbomen later
Opus 4.8, 10,000 gesprekken / maand · hefbomen toegepast van links naar rechts
Gemodelleerd op de aannames van deel 1 (10,000 gesprekken van vier beurten; een system block van 1,500 tokens; vragen van 500 tokens, antwoorden van 700 tokens; Opus 4.8 tegen $5 / $25 per 1M). Caching gebruikt 5-minute vensters en respecteert de minimale cachebare prefix van 4,096 tokens van Opus 4.8, dus het begint pas vanaf beurt 3 te lonen. Routing stuurt de makkelijkere helft van de gesprekken naar Haiku 4.5 ($1 / $5) en verandert die antwoorden. Trimmen snijdt antwoorden ~30% met de input ongewijzigd, wat de schatting conservatief houdt.
Hefboom 1: prompt caching, de korting die verborgen zit in je herhaalde context
Deel één liet zien dat opnieuw verstuurde context de grootste post op een conversationele rekening is: dezelfde system prompt en dezelfde groeiende geschiedenis, bij elke beurt opnieuw gefactureerd. Caching pakt precies die post aan. Je markeert de stabiele prefix van je verzoek, betaalt een eenmalige premie om die te schrijven (1.25x de inputprijs op de 5-minute tier, 2x op de 1-hour tier), en elk later verzoek dat met dezelfde bytes begint leest die terug tegen ongeveer een tiende van de prijs.
| Cache-tier | Schrijfpremie | Read-prijs | Verdient zichzelf terug |
|---|---|---|---|
| 5-minute | 1.25x inputprijs, eenmalig | ~0.1x inputprijs | Bij het 2e gebruik van de prefix |
| 1-hour | 2x inputprijs, eenmalig | ~0.1x inputprijs | Bij het 3e gebruik |
Twee eerlijke kanttekeningen voordat je 90 procent inboekt. Ten eerste geldt de korting voor het gecachte deel, niet voor de rekening: onze chatbot daalt van $1,460 naar $1,332, een besparing van 9 procent, omdat de gesprekken kort zijn. Op Opus 4.8 kan niets onder 4,096 tokens worden gecacht, dus een chat van vier beurten overschrijdt die drempel pas bij beurt drie; de diepste, duurste beurten krijgen de korting, de vroege niet. Ten tweede betekent de schrijfpremie dat een prefix cachen die niemand hergebruikt een manier is om extra te betalen. Caching schittert waar de context groot is of gesprekken diep gaan, wat precies is waar deel één zei dat de pijn zit.
Hefboom 2: de Batch API, een vaste halvering op alles wat kan wachten
De Batch API is de eenvoudigste korting in de catalogus: dien werk asynchroon in, krijg resultaten binnen minuten tot uren terug, betaal 50 procent van de standaardprijs op elke token in de job, gecachte tokens inbegrepen. Er is geen enkele kwaliteitsafweging; het is hetzelfde model dat dezelfde antwoorden produceert, alleen niet terwijl iemand naar een spinner kijkt.
Het addertje onder het gras is de definitie van "kan wachten". Een klant midden in een gesprek kan dat niet, dus het live verkeer van onze chatbot krijgt niets van deze hefboom, en daarom verschijnt het niet in de waterval hierboven. Maar bijna elk AI-product draagt een schaduwworkload met zich mee die wel kan wachten: de nachtelijke samenvattingen van die support-gesprekken, bulkclassificatie, rapportgeneratie, content-pipelines. Prijs die apart en batch ze standaard; de live prijs betalen voor werk waar niemand op wacht is het stilste lek in de meeste rekeningen.
Hefboom 3: routeer op moeilijkheid, niet standaard
Niet elk gesprek heeft je beste model nodig. Wachtwoordresets en vragen over de bezorgstatus vereisen geen Opus 4.8; ze vereisen een correcte opzoeking en een beleefde zin, wat Haiku 4.5 levert voor $1 / $5 per miljoen tokens, vijf keer goedkoper per token. In ons model brengt het versturen van de makkelijkere helft van de gesprekken naar Haiku de rekening van $1,332 naar $799, de grootste enkele stap in de waterval.
Behandel deze hefboom anders dan de vorige twee, want het is de eerste die de outputs verandert. Caching en batching leveren identieke antwoorden; routing geeft het gerouteerde deel een ander model. De discipline die het veilig houdt: classificeer conservatief, routeer alleen het verkeer dat een goedkoper model aantoonbaar doorstaat op je eigen testset, en houd een escalatiepad terug naar het grote model op het moment dat het gesprek niet langer makkelijk is.
Hefboom 4: trim de outputkant, want die factureert tegen vijf keer input
Elk Claude-model prijst outputtokens tegen precies vijf keer input, dus de lengte van je antwoorden is een prijsbeslissing, of je die nu bewust hebt genomen of niet. Support-antwoorden opgevuld met herhaalde vragen en afsluitende beleefdheden kosten bij volume echt geld. De assistent instrueren om te antwoorden in de kortste vorm die het ticket volledig oplost snijdt onze gemodelleerde antwoorden met ongeveer 30 procent en de rekening van $799 naar $673, en bij de Opus-familie is de effort-instelling dezelfde knop een niveau hoger: draai die terug voor routineverkeer en het model besteedt minder reasoning-tokens om op dezelfde plek te komen.
De grens is hier niet technisch maar menselijk: trim voorbij het punt van bruikbaarheid en antwoorden gaan kortaf overkomen, wat later terugkomt als herhaalcontacten. Snijd de opvulling weg, houd de inhoud.
Waar de 50 tot 90 procent daadwerkelijk vandaan komt
Stapel de hefbomen op onze chatbot en de factuur landt op $673, 54 procent onder waar deel één hem achterliet, terwijl de moeilijke helft van het verkeer nog op exact hetzelfde model draait dat exact dezelfde antwoorden produceert. Of je eigen getal dichter bij 50 of 90 landt, wordt bepaald door twee eigenschappen van je workload: hoeveel van je input herhaalde context is, en hoeveel van je werk kan wachten.
| Workload | Bespaard |
|---|---|
| Live support-chatbot | -54% |
| Nachtelijke document-pipeline | -64% |
| Asynchrone agent, zware gedeelde context | -88% |
Hoe diep de besparing gaat hangt af van de vorm
Aandeel van de maandelijkse rekening bespaard, gemodelleerd per workload
Drie gemodelleerde workloads, overal dezelfde modellen. Chatbot: de aannames van deel 1 plus de drie hefbomen hierboven ($1,460 naar $673). Pipeline: 60,000 documenten per maand op Sonnet 4.6 ($3 / $15), een gedeeld instructieblok van 2,500 tokens (gecacht) plus een document van 3,000 tokens in en 500 tokens uit, 's nachts uitgevoerd via de Batch API ($1,440 naar $518). Agent: 100,000 async calls per maand op Opus 4.8 met een gedeeld contextpakket van 10,000 tokens warm gehouden, 200 in / 300 uit per call, gebatcht ($5,850 naar $675). Cache hits binnen Batch-runs zijn best effort, dus behandel de rechteruiteinden als plafonds.
Een live chatbot zit aan de bescheiden kant, omdat korte gesprekken laat cachen en geen van het live verkeer gebatcht kan worden. Een nachtelijke document-pipeline doet het beter: het instructieblok cachet perfect en elke token in de job krijgt de batchkorting. En de asynchrone agent met een groot gedeeld contextpakket is de vorm waarvoor de kortingen gemaakt zijn; negen tiende van zijn input wordt uit de cache gelezen en de hele run batcht, dus 88 procent van de rekening verdwijnt gewoon.
De geschiktheidscheck
Voordat je aan de modelstring komt, loop je workload één keer langs deze tabel af.
| Hefboom | Je workload heeft nodig | Realistische besparing | Let op |
|---|---|---|---|
| Prompt caching | Een stabiele prefix boven het modelminimum, hergebruikt binnen het cachevenster | ~90% korting op het herhaalde deel | Schrijfpremie werkt averechts onder 2-3 hergebruiken; korte chats cachen laat |
| Batch API | Tolerantie voor minuten-tot-uren latentie | Vaste -50% op de hele job | Nooit voor een wachtende gebruiker; cache hits binnen batches zijn best effort |
| Routing op moeilijkheid | Een deel van het verkeer dat een goedkoper model aantoonbaar aankan | Tot 5x op het gerouteerde deel | Verandert outputs; test eerst de kwaliteit en houd een escalatiepad |
| Output trim + effort | Outputzware rekeningen (output geprijsd op 5x input) | Evenredig aan de besparing | Te agressief komt over als kortaf, onvolledige antwoorden |
Voer de audit in deze volgorde uit: eerst caching als er context herhaalt, batch alles waar een gebruiker niet op wacht, trim de output die je toch nooit las, en routeer dan het aantoonbaar makkelijke deel. Pas als alle vier op hun plek staan, verdient de downgradevraag een antwoord, en dan is het een veel kleinere vraag. En als het getal waarop je landt nog steeds te hoog voelt voor wat de feature oplevert, is de vraag niet langer hoe je het goedkoper draait; het is of het eigenlijk wel zou moeten bestaan, en dat is precies waar deel drie voor is.
