GPT-6.1 Terra Caching: Fünf Cent pro Lesevorgang – und wann sich der Schreibvorgang auszahlt

Der Cache-Input-Preis von GPT-6.1 Terra liegt bei 0,05 $ pro Million Tokens – 95 % unter dem Standard-Input-Preis von 1,00 $ und der größte Einzelrabatt auf der gesamten Preiskarte. Der Haken liegt auf der anderen Seite der Bilanz: Das Schreiben in den Cache kostet 1,25 $ pro Million für 30 Minuten Vorhaltung oder 2,50 $ pro Million für 12 Stunden. Eine Arbeitslast, die denselben Prefix zweimal liest, kommt damit besser weg. Eine Arbeitslast, die ihren Prefix bei jedem Aufruf neu aufbaut, zahlt die Schreibgebühr und kassiert den Rabatt nie – und die Preiskarte verrät Ihnen nicht, welchen der beiden Fälle Sie gerade fahren.

Dieser Beitrag rechnet es durch: den exakten Break-even-Punkt, drei durchgerechnete Workloads in unterschiedlichen Größenordnungen, die Wechselwirkung mit der 272K-Long-Context-Klippe und die Prompt-Engineering-Gewohnheiten, die still und leise Caches zerstören.

Die vier Zahlen

• Standardeingabe — 1,00 $ pro Million Tokens.

• Zwischengespeicherte Eingabe — 0,05 $ pro Million, ein Rabatt von 95 %.

• Cache-Schreibvorgang, 30-minütige Aufbewahrung — 1,25 $ pro Million.

• Cache-Schreibvorgang, 12 Stunden Aufbewahrung — 2,50 $ pro Million.

Oberhalb von 272.000 Eingabe-Tokens verdoppelt sich alles: 2,00 $ für Eingabe, 0,10 $ für gecachte Eingabe, 2,50 $ für Cache-Schreiben. Die Long-Context-Klippe erhöht also nicht nur den Eingabetarif – sie verteuert gleichzeitig sowohl Caching als auch Schreiben.

Zum Vergleich: Der zwischengespeicherte Input von GPT-6.1 Sol kostet 0,10 $ und der von GPT-5.6 Terra 0,20 $. Terras Fünf-Cent-Lesen ist das günstigste in der Familie, und der Rabatt von 95 % ist es, der wiederholte Long-Context-Aufrufe überhaupt erst wirtschaftlich möglich macht.

Der exakte Break-even-Punkt

Nehmen Sie an, dass ein Präfix von P Tokens über N Aufrufe hinweg wiederverwendet wird, und ignorieren Sie die Ausgabe vorerst.

• Ohne Caching: N × P × $1.00.

• Mit Caching: ein Schreibvorgang zu $1,25 × P, dann N Lesevorgänge zu $0,05 × P.

Gleichsetzen ergibt: 0,95N = 1,25, also N ≈ 1,32. In der Praxis bedeutet das, dass der zweite Aufruf bereits profitabel ist: Der Schreibvorgang kostet 1,25 pro Million und jeder Lesevorgang spart 0,95, sodass zwei Lesevorgänge mehr als den Schreibvorgang wieder hereinholen. Bei einer Aufbewahrungsdauer von 12 Stunden kostet der Schreibvorgang 2,50 $ und der Break-even liegt bei 2,63 Lesevorgängen – der dritte Aufruf bezahlt ihn.

Das ist eine niedrigere Hürde, als die meisten Teams annehmen. Der verbreitete Mythos besagt, dass sich Caching nur bei sehr hoher Wiederverwendung lohnt; bei dieser Karte lohnt es sich ab der zweiten Anfrage, sofern das Präfix tatsächlich übereinstimmt.

Drei Workloads

Ein System-Prompt mit 50.000 Tokens über 10.000 kurze Anfragen hinweg. Ohne Caching: 10.000 × 50.000 × 1,00 $ pro Million = 500 $ nur für das Präfix. Mit Caching: ein Schreibvorgang von 50.000 × 1,25 $ pro Million = 0,0625 $, plus 10.000 Lesevorgänge zu 50.000 × 0,05 $ pro Million = 25 $. Insgesamt 25,06 $ — eine Einsparung von 95 % beim Präfix, und der Cache-Schreibvorgang ist ein Rundungsfehler.

Ein Repository mit 900.000 Token über 20 Fragen. Ohne Caching fällt jede Anfrage in den Langkontext-Tarif: 900.000 × 2,00 $ pro Million = 1,80 $ pro Aufruf, 36 $ für zwanzig. Mit Caching: ein Schreibvorgang von 900.000 × 2,50 $ pro Million = 2,25 $, dann zwanzig Lesevorgänge zu 900.000 × 0,10 $ pro Million = 0,09 $ jeweils, insgesamt 1,80 $. Zusammen 4,05 $ – eine Ersparnis von 89 %, und die 18-Dollar-Differenz ist bei manchen Produkten die gesamte Marge.

Ein Dokument mit 20.000 Tokens über drei Fragen hinweg, jede mit einer anderen Persona und anderen Anweisungen. Dies ist der Fall, in dem Caching fehlschlägt: Wenn sich das Präfix zwischen Aufrufen ändert – unterschiedlicher System-Prompt, unterschiedliche Reihenfolge der Anweisungen, eine oben interpolierte Benutzer-ID –, sieht das Modell drei verschiedene Präfixe und schreibt drei Caches. Ohne Cache und „mit Cache“ kosten gleich viel, außer dass Sie für Schreibvorgänge bezahlt haben. Die Lösung ist struktureller Art: Alles Variable kommt ans Ende des Prompts, und das Dokument sowie die stabilen Anweisungen bleiben am Anfang.

Was einen Cache zerstört/p> p>OpenAI-Prompt-Caching arbeitet auf dem unveränderten Präfix einer Anfrage. Alles, was sich früh im Prompt ändert, macht alles danach ungültig. Die üblichen Verdächtigen:/p> p>• Ein Zeitstempel oder eine Anfrage-ID im System-Prompt. Das ist die häufigste Ursache für eine Cache-Trefferquote von 0 %./p> p>• Personalisierung pro Benutzer, die oben statt unten eingefügt wird./p> p>• Umgeordnete Tool-Definitionen oder eine Tool-Liste, die sich zwischen Aufrufen ändert./p> p>• Ein Retrieval-Schritt, der Dokumente bei jedem Mal in einer anderen Reihenfolge verkettet./p> p>• Durch Templating-Engines verursachte Änderungen an Leerraum — es genügt, einen JSON-Block neu zu formatieren./p> p>• Ein Wechsel zwischen Chat Completions und Responses mitten in der Pipeline, wodurch sich das serialisierte Präfix ändert./p> p>Die Diagnose ist einfach: die ersten 2.000 Token jeder Anfrage protokollieren und hashen. Wenn sich der Hash zwischen Aufrufen ändert, die eigentlich identisch sein sollten, ist der Cache tot, und keinerlei Tuning wird ihn wiederbeleben./p> h2>Cache und die 272K-Klippe

Die beiden interagieren auf eine Weise, die leicht übersehen wird. Ein zwischengespeichertes Präfix mit 250.000 Token kostet $0,05 pro Million zum Lesen und $1,25 zum Schreiben. Wächst es auf 300.000 Token, verdoppelt sich jede Zahl: $0,10 zum Lesen, $2,50 zum Schreiben, und der nicht zwischengespeicherte Teil wird mit $2,00 abgerechnet. Eine Pipeline, die die Schwelle überschreitet, zahlt die Klippe sowohl auf der zwischengespeicherten als auch auf der nicht zwischengespeicherten Seite.

Das schafft einen nicht offensichtlichen Design-Anreiz: Wenn eine Workload knapp über 272K liegt, kann das Kürzen des Präfixes auf 270K die Rechnung halbieren, ohne die Aufgabe zu verändern. Einen Boilerplate-Abschnitt zu kürzen, einen unnötigen Retrieval-Block wegzulassen oder ein Beispiel aus dem System-Prompt herauszunehmen, ist an der Grenze mehr wert als irgendwo sonst auf der Karte.

Caching im Vergleich zu den Alternativen

• Caching — am besten geeignet, wenn derselbe lange Präfix innerhalb des Aufbewahrungsfensters viele Male wiederverwendet wird und der Präfix wirklich stabil ist.

• Chunking — am besten, wenn das Dokument groß ist, aber jede Frage nur einen kleinen Teil betrifft; Retrieval ist günstiger, als selbst zum Cache-Tarif 900K Tokens zu senden.

• Batch/Flex — 50 % Rabatt auf den Standardpreis, aber die Batch-Latenz wird in Stunden gemessen; es lässt sich mit Caching kombinieren, nicht mit Echtzeitprodukten.

• Ein günstigeres Modell – GPT-6 Luna zu $0,10/$0,50 kann bei einfachen Aufgaben Terras Cache-Tarif schlagen, weil Lunas nicht gecachter Input nur doppelt so hoch ist wie Terras gecachter Input.

Der letzte Vergleich ist der, den Teams vergessen. Caching ist ein Rabatt auf Terra, keine Garantie dafür, dass Terra der günstigste Weg ist, eine Frage zu beantworten. Für die Klassifizierung über einen Prompt mit 50.000 Token ist Luna mit Cache zu 0,01 US-Dollar pro Million gelesener Token immer noch die günstigere Variante, wenn die Aufgabe einfach genug ist.

Was Sie heute ausführen können

GPT-6.1 Terra ist zum Zeitpunkt des Verfassens nicht im OrcaRouter-Katalog, daher muss sein Cache-Verhalten direkt gegen OpenAI gemessen werden. Die Modelle, die live sind — GPT-6.1 Sol zu $2/$10 mit einer Cache-Rate von $0.10, GPT-5.6 Terra zu $2/$12 mit $0.20, GPT-6 Luna zu $0.10/$0.50 — können alle mit einem Schlüssel bei 0 % Aufschlag auf den Listenpreis des Anbieters getestet werden.

Die Kennzahl, die es aufzubauen gilt, ist nicht „funktioniert Caching?“ – das tut es –, sondern „welcher Anteil meines Traffics hat ein stabiles Präfix“. Dieser Anteil ist die einzige Zahl, die entscheidet, ob Terras Fünf-Cent-Lesevorgang für Ihre Rechnung relevant ist, und er ist eine Eigenschaft Ihrer Prompts, nicht des Modells.