GPT-6.1 Terra Caching: vijf cent per leesactie, en wanneer de schrijfactie loont

Het gecachte invoertarief van GPT-6.1 Terra is $0.05 per miljoen tokens — 95% onder het standaard invoertarief van $1.00, en de grootste afzonderlijke korting op de hele tariefkaart. Het addertje zit aan de andere kant van de balans: schrijven naar de cache kost $1.25 per miljoen voor 30 minuten retentie of $2.50 per miljoen voor 12 uur. Een workload die hetzelfde prefix twee keer leest, komt er voordelig uit. Een workload die zijn prefix bij elke call opnieuw opbouwt, betaalt de schrijfkosten en strijkt de korting nooit op, en de tariefkaart vertelt je niet welke van de twee je gebruikt.

Dit stuk rekent het uit: de exacte break-even, drie uitgewerkte workloads op verschillende schalen, de interactie met de 272K long-context-cliff, en de prompt-engineeringgewoonten die caches geruisloos vernietigen.

De vier getallen

• Standaardinvoer — $1,00 per miljoen tokens.

• Gecachte invoer — $ 0,05 per miljoen, een korting van 95%.

• Cache schrijven, bewaartermijn van 30 minuten — $1,25 per miljoen.

• Cache-schrijven, 12 uur bewaartermijn — $2,50 per miljoen.

Boven 272.000 invoertokens verdubbelt alles: $2,00 voor invoer, $0,10 voor gecachet, $2,50 voor cache-schrijven. De long-context-cliff verhoogt dus niet alleen het invoertarief — hij verhoogt tegelijkertijd de prijs van zowel cachen als schrijven.

Ter vergelijking: de gecachte invoer van {{1}}GPT-6.1 Sol{{/1}} is {{2}}$0,10{{/2}} en die van {{3}}GPT-5.6 Terra{{/3}} is {{4}}$0,20{{/4}}. {{5}}Terra's leesprijs van vijf cent{{/5}} is de goedkoopste in de familie, en {{6}}de korting van 95%{{/6}} is wat herhaalde aanroepen met een lange context überhaupt economisch mogelijk maakt.

Het exacte break-evenpunt

Neem aan dat een prefix van P tokens bij N aanroepen wordt hergebruikt, en negeer de output even.

• Zonder caching: N × P × $1,00.

• Met caching: één schrijfactie voor $1,25 × P, daarna N leesacties voor $0,05 × P.

Als we ze gelijkstellen: 0,95N = 1,25, dus N ≈ 1,32. In de praktijk betekent dat dat de tweede aanroep al winstgevend is: de schrijfactie kost 1,25 per miljoen en elke leesactie bespaart 0,95, dus twee leesacties leveren meer op dan de schrijfactie. Met 12 uur retentie kost de schrijfactie $2,50 en ligt het break-evenpunt op 2,63 leesacties — de derde aanroep betaalt dat terug.

Dat is een lagere drempel dan de meeste teams aannemen. De gangbare mythe is dat caching alleen loont bij zeer veel hergebruik; op deze kaart loont het al vanaf de tweede aanvraag, mits het prefix daadwerkelijk overeenkomt.

Drie workloads

Een systeemprompt van 50.000 tokens verdeeld over 10.000 korte verzoeken. Zonder cache: 10.000 × 50.000 × $1,00 per miljoen = $500 alleen voor het prefix. Met cache: één schrijving van 50.000 × $1,25 per miljoen = $0,0625, plus 10.000 leesacties van 50.000 × $0,05 per miljoen = $25. Totaal $25,06 — een besparing van 95% op het prefix, en de cacheschrijving is een afrondingsfout.

Een repository van 900.000 tokens verspreid over 20 vragen. Zonder cache valt elke aanvraag onder het tarief voor lange context: 900.000 × $2,00 per miljoen = $1,80 per aanroep, $36 voor twintig. Met cache: één schrijfactie van 900.000 × $2,50 per miljoen = $2,25, daarna twintig leesacties tegen 900.000 × $0,10 per miljoen = $0,09 per stuk, $1,80 totaal. Totaal $4,05 — een besparing van 89%, en het verschil van achttien dollar is de volledige marge op sommige producten.

Een document van 20.000 tokens verdeeld over drie vragen, elk met een andere persona en instructies. Dit is het geval waarin caching faalt: als het prefix tussen aanroepen verandert — een andere systeemprompt, een andere volgorde van instructies, een gebruikers-ID die bovenaan wordt ingevoegd — ziet het model drie verschillende prefixen en schrijft het drie caches. Niet-gecacht en "gecacht" kosten evenveel, behalve dat je hebt betaald voor het schrijven. De oplossing is structureel: zet alles wat variabel is aan het eind van de prompt, en houd het document en de stabiele instructies aan het begin.

Wat een cache ongeldig maakt/p> p>OpenAI's promptcaching werkt op het ongewijzigde prefix van een verzoek. Alles wat vroeg in de prompt verandert, maakt alles daarna ongeldig. De gebruikelijke boosdoeners:/p> p>• Een tijdstempel of verzoek-ID in de systeemprompt. Dit is de meest voorkomende oorzaak van een cachehitpercentage van 0%./p> p>• Personalisatie per gebruiker die bovenin wordt ingevoegd in plaats van onderin./p> p>• Herordende tooldefinities of een toollijst die tussen aanroepen verandert./p> p>• Een retrievalstap die documenten elke keer in een andere volgorde samenvoegt./p> p>• Witruimtewijzigingen door templating-engines — het opnieuw formatteren van een JSON-blok is al genoeg./p> p>• Tussen Chat Completions en Responses wisselen midden in de pipeline, waardoor het geserialiseerde prefix verandert./p> p>De diagnose is eenvoudig: log de eerste 2.000 tokens van elk verzoek en hash ze. Als de hash verandert tussen aanroepen die identiek zouden moeten zijn, is de cache dood en kan geen enkele tuning hem weer tot leven brengen./p> h2>Cache en de 272K-klif

De twee werken op een manier samen die makkelijk te missen is. Een gecachte prefix van 250.000 tokens kost $0,05 per miljoen om te lezen en $1,25 om te schrijven. Maak je het 300.000 tokens groter, dan verdubbelt elk getal: $0,10 lezen, $2,50 schrijven, en het niet-gecachte deel wordt tegen $2,00 gefactureerd. Een pipeline die de drempel overschrijdt, betaalt de prijssprong zowel aan de gecachte als aan de niet-gecachte kant.

Dit creëert een ontwerpstimulans die niet vanzelfsprekend is: als een werklast net boven 272K ligt, kan het verkleinen van de prefix naar 270K de rekening halveren zonder de taak te veranderen. Een standaardtekstsectie inkorten, een onnodig retrieval-blok weglaten of een voorbeeld uit de systeemprompt halen is op de grens meer waard dan waar dan ook elders op de kaart.

Caching versus de alternatieven

• Caching — het beste wanneer dezelfde lange prefix binnen het retentievenster vele malen wordt hergebruikt en de prefix echt stabiel is.

• Chunking — het meest geschikt wanneer het document groot is, maar elke vraag maar een klein deel ervan raakt; ophalen is goedkoper dan zelfs tegen het cachetarief 900K tokens te verzenden.

• Batch/Flex — 50% korting ten opzichte van standaard, maar batchlatentie wordt in uren gemeten; het stapelt met caching, niet met realtimeproducten.

• Een goedkoper model — GPT-6 Luna tegen $0,10/$0,50 kan voor eenvoudige taken Terra's cachetarief verslaan, omdat Luna's niet-gecachte invoer slechts twee keer Terra's gecachte invoer is.

De laatste vergelijking is degene die teams vergeten. Caching is een korting op Terra, niet een garantie dat Terra de goedkoopste manier is om een vraag te beantwoorden. Voor classificatie over een prompt van 50.000 tokens is Luna met caching tegen $0,01 per miljoen gelezen tokens nog steeds de goedkopere optie als de taak eenvoudig genoeg is.

Wat je vandaag kunt uitvoeren

GPT-6.1 Terra staat op het moment van schrijven niet in de OrcaRouter-catalogus, dus zijn cachegedrag moet direct bij OpenAI worden gemeten. De modellen die live zijn — GPT-6.1 Sol voor $2/$10 met een gecacht tarief van $0,10, GPT-5.6 Terra voor $2/$12 met $0,20, GPT-6 Luna voor $0,10/$0,50 — kunnen allemaal met één sleutel worden getest tegen 0% opslag over de listprijs van de provider.

De meting die je moet opzetten is niet “werkt caching?” — dat werkt — maar “welk deel van mijn verkeer heeft een stabiel prefix”. Die fractie is het enige getal dat bepaalt of Terra's leesactie van vijf cent iets betekent voor je rekening, en het is een eigenschap van je prompts, niet van het model.