Agent-Fleet-Tokenökonomie ist Cache-Ökonomie: Der 60-fache Dollar-Spread im Detail zerlegt

Eine der am meisten zitierten Agenten-Ökonomiezahlen des Septembers 2026 ist eine Geschichte, die ein CEO in einem Podcast erzählt: Matt Barrie, Gründer und CEO von Freelancer.com, betrieb eine Flotte von rund 44 selbst gebauten Agenten, verbrannte an einem einzigen Tag etwa 4 Milliarden Tokens und zahlte dafür rund 1.300 Dollar — davon gingen etwa 900 Dollar an Anthropics Sonnet, der Rest an andere Routen —, während er angab, derselbe Tag koste auf einem Opus-Klasse-Modell ohne Caching etwa 80.000 Dollar¹²³.

Jede Zahl in diesem Satz ist selbst berichtet, single-day und ungeprüft. Drei der vier Milliarden Tokens waren Prompt-Cache-Lesezugriffe — Agenten-Loops, die ihren eigenen Kontext neu lesen, keine frische Arbeit². Genau dieses Detail macht die Geschichte einer Zerlegung wert: Anders als die Dollar-Summen sind die Mechaniken vollständig aus öffentlichen Preislisten verifizierbar — der Spread ist Arithmetik, keine Entdeckung. Dieser Leitfaden rechnet das Ganze gegen live Provider-Preise nach, zerlegt die Lücke in ihre multiplikativen Faktoren und macht daraus eine Capacity-Planungs-Checkliste. Er führt die Mathe-Kette aus unserem Inferenz-Kostenguide und der RAG-Retrieval-Mathematik fort.

Alles aus dem Ankerfall ist als berichtet, nicht verifiziert zu markieren: ein Betreiber, ein Tag, kein Audit. Die Zerlegung unten steht für sich, unabhängig davon, ob der Tag exakt so ablief wie erzählt.

Der Ankerfall, seziert

Von der tatsächlichen Preisliste ausgehen⁴ — pro 1M Tokens, live zum Schreibzeitpunkt:

Nun der berichtete Tag, als abrechenbare Mengen zusammengefasst:

• Gesamt: ~4,0 Mrd. Tokens, ~1.300 $, davon ~900 $ auf Sonnet²
• ~3,0 Mrd. dieser Tokens waren Prompt-Cache-Lesezugriffe — ein Looping-Anteil von 75 %
• ~1,0 Mrd. Tokens waren frisch: neue Eingaben, die tatsächlich ungecached zum Modell kamen, plus generierter Output

Arithmetischer Plausibilitätscheck gegen die Preisliste, rein auf Sonnet: 3,0 Mrd. Cache-Lesezugriffe zu 0,20 $/1M sind 600 $. Für frisches Input plus Output bleiben 300 $ des 900-$-Sonnet-Budgets. Zum Beispiel ~100 Mio. frische Input-Tokens (200 $) plus ~10 Mio. Output-Tokens (100 $) landen exakt bei 300 $. Der berichtete Totalbetrag ist nicht nur plausibel — er ist gewöhnlich: Ein Tag, der zu drei Vierteln eigenen Kontext neu liest, wird abgerechnet wie ein Tag, der zu drei Vierteln rabattierten Kontext enthält. Die 1.300 $ beschreiben keine 4 Milliarden Tokens Arbeit, sondern rund 1 Milliarde Tokens Arbeit plus das eigene Echo, zum Zehntel abgerechnet.

Das Kontrafaktikum, ehrlich gerechnet

Bei den 80.000 Dollar muss die Skepsis am härtesten ansetzen, denn es handelt sich um ein Kontrafaktikum, nicht um eine Rechnung. Nachrechnen:

Alles Opus, ungecached, nur Input:  4,0 Mrd. / 1M x $5   = 20.000 $
Alles Opus, ungecached, + 1,0 Mrd. Output: + 1,0 Mrd. / 1M x $25 = 45.000 $
Alles Opus, ungecached, + ~2,4 Mrd. Output:             ≈ 80.000 $

Die saubere Preislisten-Untergrenze für „denselben Tag, Opus, ohne Cache" sind 20.000 $ — nur die Input-Zeile. Um 80.000 $ zu erreichen, muss man annehmen, dass der Tag zusätzlich rund 2,4 Mrd. Output-Tokens zu Opus' 25 $/1M trug — eine deutlich output-lastigere Form, als die 900-$-Sonnet-Zerlegung nahelegt. Die 80.000 $ sind also als berichtet, nicht als verifiziert zu behandeln: erreichbare Arithmetik unter einer ungenannten Output-Token-Annahme, aber nicht die Zahl, die die Preisliste allein hergibt. Die verifizierbare Aussage lautet: dieselben Tokenmengen, komplett auf Opus ohne Cache umgeroutet, kosten mindestens 20.000 $ — bereits ein ~15-facher Spread über 1.300 $.

Der Spread, faktorisiert

Teilt man den berichteten Spread, 80.000 / 1.300 ≈ 61,5x, in Faktoren, die jeweils als Zeile auf einer öffentlichen Preisliste oder als Eigenschaft der Workload-Form existieren:

Das ist der Anti-Hype-Punkt in einer Tabelle: rund 7,7x des Spreads sind öffentliche Arithmetik — ein Preislisten-Verhältnis mal ein Cache-Multiplikator, wirkend auf den Looping-Anteil. Die verbleibenden ~8x stehen auf keiner Preisliste; sie stecken in der Output-Mix-Annahme des Kontrafaktikums. Der Spread ist dramatisch, aber keine Entdeckung. Den sauberen Teil kann jeder in zwei Minuten in einer Tabellenkalkulation reproduzieren.

Und die Frisch-vs-Cache-Aufteilung ist die eigentliche Workload-Beschreibung: Von 4 Mrd. Tokens waren rund 25 % — etwa 1 Mrd. — frische Inferenz. Der Rest war die Flotte, die ihr eigenes Transkript rabattiert vorlas.

Der Looping-Anteil ist die echte Zahl

Warum sollten 75 % der Tokens einer Agenten-Flotte Cache-Lesezugriffe sein? Wegen der Bauweise von Agenten-Loops. Jeder Tool-Aufruf im Zyklus eines Agenten sendet dem Modell den gesamten bisherigen Verlauf — System-Prompt, Tool-Definitionen, bisherige Tool-Ergebnisse, das eigene bisherige Reasoning — plus genau ein neues Element. Der Präfix ist von Aufruf zu Aufruf nahezu identisch; nur der Schwanz wächst. Ein Agent, der 50 Schritte gelaufen ist, sendet seine ersten 49 Schritte 50-mal neu.

Das ist exakt die Radix-Prefix-Cache-Ökonomie, die unsere Serving-Engine-Artikel beschreiben: ein KV-Präfix-Cache erlaubt der Serving-Engine, die Attention-Keys und -Values eines identischen Präfixes wiederzuverwenden, statt den Prefill neu zu berechnen — der Mechanismus aus KV-Cache erklärt und die Tiering-Strategien für genau dieses agentische Zugriffsmuster in Agentische Inferenz: KV-Tiering. Auf Provider-Seite wird diese Wiederverwendung abgerechnet: Cache-Treffer zu 0,1x Basiseingabe bei Anthropic-Modellen, 0,25x–0,5x je nach Provider anderorts, Schreibzugriffe zu 1,25x–2x⁴⁵.

Die Konsequenz ist strukturell, nicht beiläufig:

• Ohne den Cache-Rabatt skaliert der Preis mit der Anzahl der Loops, nicht mit der erledigten Arbeit. Ein 50-Schritt-Loop fakturiert Schritt eins fünfzigmal. Zum vollen Input-Preis dominiert die Wiederholung die Rechnung einer Flotte; der Provider-Rabatt ist das, was die Rechnung wieder proportional zu den tatsächlich neuen Tokens macht.
• Cache-Kompatibilität ist ein Budgetposten, kein Detail. Caches haben TTLs (standardmäßig 5 Minuten, auf 1 Stunde verlängerbar beim Anthropic-Routing), minimal cachebare Prompt-Größen (1.024–4.096 Tokens je nach Modell) und providerspezifisches Reset-Verhalten — explizites Caching via cache_control-Breakpoints bei Anthropic, implizites Caching über 1.024 Tokens bei OpenAI, sticky Provider-Routing nötig, um Treffer über ein Gateway warm zu halten⁵. Ein Agent-Harness, der Provider pro Anfrage wechselt, seinen System-Prompt pro Aufruf neu schreibt oder schlicht langsamer läuft als die TTL, zahlt vollen Input-Preis für dieselbe Arbeit.

Rechnet der Ankerfall also 1.300 $ für einen Tag ab, der ungecached-input-only 20.000 $ kosten würde, dann ist die Flotte nicht clever — sie ist typisch. Die 75 % Cache-Anteil ist, wie Agenten-Workloads aussehen, wenn die Cache-Schicht funktioniert.

Die 85-%-Selbstoptimierungs-Behauptung, skeptisch

Der Ankerfall berichtet zudem, eine einzige Anweisung — die Agenten anzuweisen, ihren eigenen Token-Verbrauch zu prüfen und zu optimieren — habe den Verbrauch um weitere 85 % gesenkt¹³. Zu verifizieren ist nur, dass das behauptet wurde, nicht dass es wie versprochen funktionierte. Zwei Probleme:

Erstens ist die Literatur zu Prompt-Level-Kostenkontrolk ein Qualitätsminenfeld. Brevity-getriebenes Prompting verkürzt Antworten nachweislich und senkt bei faktischen Anfragen die Energie um 25–60 %, aber dieselben Evaluationen warnen, dass Output-Kompression für Langform-Aufgaben ungeeignet ist⁶. Kostenoptimierte Prompt-Forschung stellt ausdrücklich fest, dass statische längenbeschränkte Prompts bei schweren Problemen versagen und das Reasoning degradieren — Modelle überschreiten Token-Limits häufig, und erzwungene Kompression lässt Reasoning-Modelle Schritte auslassen⁷. Ein um 85 % gesenkter Verbrauch durch einen einzigen Satz ist plausibel gedeutet: Agenten, die weniger schreiben, weniger denken oder weniger neu erkunden — jede Deutung kann für die Aufgaben der Flotte genau richtig oder genau falsch sein.

Zweitens begleitet keine Evaluation die Behauptung. Es gibt keine Vorher-Nachher-Messung der Aufgabenerledigung, keine Fehlerrate-Prüfung, gar kein Eval in den öffentlichen Aufzeichnungen — nur den Token-Zähler, und der ist die eine Metrik, die eine Kosten-Anweisung garantiert verbessert.

Der Urteilsrahmen dieser Seite: Kosten pro erledigter Aufgabe ist die einzige Metrik, die den Kontakt mit Qualitätsregressionen übersteht. Kosten pro Tag optimiert den falschen Nenner; eine Flotte, die ihre Rechnung halbiert, indem sie still eine Fünftel ihrer Warteschlange verpatzt, sieht auf einem Verbrauchschart identisch aus. Wer Prompt-Level-Kostenkontrolle ausprobiert (man sollte — sie ist gratis), muss sie koppeln: festen Eval-Satz vorher und nachher laufen lassen und die Token-Reduktion als unbewiesene Ersparnis behandeln, bis die Erfolgsquoten der Aufgaben halten.

Flotten-Extrapolation: was sich potenzieriert, was flach bleibt

Barries erklärter Plan ist, die Flotte 10x zu skalieren, dann nochmal¹. Nun die Arithmetik, ehrlich gerechnet — denn die zwei Achsen verhalten sich unterschiedlich:

• Agenten skalieren linear. 40 Agenten zu 1.300 $/Tag ergeben 400 Agenten zu ~13.000 $/Tag bei konstanter Cache-Trefferrate. In der Agentenzahl potenzieriert sich nichts; jede Agentenrechnung ist weitgehend unabhängig.
• Kontexttiefe ist, wo die Kosten überlinear wachsen. Pro Aufgabe sendet ein Agent, der n Schritte mit L-Token-Schrittinkrement läuft, über seine Lebensdauer einen Präfix mit im Mittel n·L/2 Tokens erneut: das Neu-Lese-Volumen wächst rund mit dem Quadrat der erledigten Schritte. Langlebige Agenten werden mit wachsender Tiefe cache-abhängiger — der Cache-Anteil wächst also mit der Kontexttiefe, und mit ihm die Anfälligkeit für TTL-Verfälle und Cache-Resets. Eine Flotte von Agenten mit je 500 Schritten ist weitaus cache-elastischer als eine Flotte mit 20.
• Was sich tatsächlich potenzieriert: nichts in diesem Kostenmodell. Der Token-Preis steigt nicht mit dem Volumen; Cache-Rabatte verfallen nicht mit Skalierung; der einzige superlineare Term ist die Loop-Tiefe pro Aufgabe, begrenzt durch Kontextfenster und Kompressionspolitik. Flottenkosten sind linear in Agentenzahl mal quadratisch-in-Schritten pro Aufgabe — die Hebel sind Schritt-Budgets und Kontext-Kompression, nicht Preisverhandlungen mit dem Provider.

Für Größenordnung: OpenRouters wöchentlicher Token-Verbrauch — die Routing-Schicht, über die die Anker-Flotte abrechnet — wurde mit 126,2 Billionen Tokens pro Woche berichtet, ein Anstieg von mehr als 25.000 % gegenüber ~0,5T im Januar 2025⁸. Dieselbe Analyse, die das Chart vorstellte, führt das Wachstum nicht auf mehr Nutzer zurück, sondern auf Reasoning-Denktokens und unoptimierte Agenten-Loops⁸ — der Looping-Anteil, im Planetenmaßstab sichtbar. Barries 4 Mrd./Tag sind 0,0032 % dieses Wochenflusses: ein begeisterter Betreiber ist Rauschen; eine Million davon sind die Kurve.

Die 30-Terawatt-Zahl, nachgerechnet

Der Ankerfall bietet eine Extrapolation aufs Weltmaß: Wenn alle ~8 Milliarden Menschen 4 Mrd. Tokens pro Tag verbrannten, brauchte die Welt etwa 30 Terawatt — rund das Zehnfache der globalen Stromerzeugung³. Statt dem zu vertrauen, aus genannten Annahmen nachrechnen:

Tokens:      4e9 Tok/Tag/Person x 8e9 Personen         = 3,2e19 Tokens/Tag
FLOPs/Token: 2 x aktive Parameter, 100-300 Mrd. aktiv   = 2e11-6e11 FLOP/Token
Effizienz:   1-3 effektive TFLOPS pro Wand-Watt
                                        (geliefert, inkl. Overhead)
Compute/Tag  = 3,2e19 x (2...6)e11                      = 6,4e30-1,9e31 FLOP/Tag
Leistung     = Compute / 86400 / (1...3)e12             = 24,7-222 TW
mit 75 % Cache-geservtem Prefill übersprungen (nahe null marginale FLOPs): x 0,25
                                                     = 6,2-56 TW

Ehrlich klammern: 6–56 TW je nach Modellgröße und Silizium-Effizienz, gegen ~3,4 TW durchschnittlicher weltweiter Stromerzeugung — die „30 TW" liegen also innerhalb des nachgerechneten Bandes, und „das Zehnfache der Weltproduktion" ist die richtige Größenordnung. Die Zahl ist eine grobe Überschlagsrechnung, keine Messung, und allein der Cache-Übersprung-Term bewegt sie um 4x — dieselbe Elastizität, im planetaren Maßstab, die auch die Tagesrechnung der Flotte dominiert. Zu beachten bleibt, was das Gedankenexperiment versteckt: 4 Mrd. Tokens/Tag/Person ist ein schwerer Basteltag eines einzigen CEOs, der aktiv eine Flotte aufbaute — extrapoliert auf alle, für immer. Sowohl der Dollar-Spread als auch die Terawatt-Zahl picken sich ihren Tag heraus.

Praktisch: Capacity-Planungs-Checkliste für eine interne Flotte

Alles Obige verdichtet sich zu fünf Punkten zur Prüfung, bevor ein Budget für eine Agenten-Flotte festgelegt wird:

1. Kosten gegen die Cache-Trefferrate modellieren, nicht gegen den Listenpreis. Bei einem 0,1x-Cache-Leserabatt ist der Kostenmultiplikator 1 − 0,9 × h, wobei h die Trefferrate ist: h=0,50 senkt die Input-Kosten auf 0,55x, h=0,75 auf 0,325x, h=0,90 auf 0,19x. h aus der Provider-Telemetrie messen (cached_tokens im Usage-Objekt bei über OpenRouter gerouteten Anfragen⁵), bevor irgendeine Flotten-Kostenprojektion geglaubt wird. Eine Projektion, die h=0 annimmt, hat bei typisch agentischer Form schon um 3x zu hoch gerechnet.
2. Die Provider-x-Cache-Kompatibilitätsmatrix aufbauen, bevor das Modell gewählt wird. Explizite cache_control-Breakpoints vs. implizites Caching; 5-Minuten- vs. 1-Stunden-TTL vs. backendabhängiger Verdrängung; 1.024–4.096 Token minimale cachebare Präfixe; Sticky-Routing-Verlust bei manueller Provider-Sortierung⁵. Ein Modell, das pro 1M $1 billiger ist, aber den Cache bei jedem Request-Wechsel resettet, ist das teure.
3. Nach Posten budgetieren, mit Cache-Lesezugriffen ganz oben. Die Budgetierungsheuristik: Auf agentischen Workloads ist Cache-Lese-Ausgabe der größte Einzelposten — 75 % der Tokens zu einem Zehntel sind bei Sonnet-Preisen immer noch das 3-Fache der Frisch-Input-Zeile (600 $/Cache-Lesezugriffe gegen 200 $/frischen Input im obigen Rechenbeispiel). Weder die Intuition „gecacht = gratis" noch die Schlagzeile „4 Mrd. Tokens!" darf das verstecken — nur 1 Mrd. waren Arbeit.
4. Loop-Tiefe pro Aufgabe begrenzen. Da das Neu-Lese-Volumen ~quadratisch mit den Schritten wächst, bringt ein Schritt-Budget plus regelmäßige Kontext-Kompression mehr als jede Preisverhandlung. Die maximale Schrittzahl zu halbieren senkt den Neu-Lese-Term etwa 4x.
5. Jede Kostenoptimierung hinter Kosten-pro-erledigter-Aufgabe koppeln. Prompt-Level-Kostenanweisungen⁶⁷, Zusammenfassungs-Kompression, günstigeres Modell im Loop — vor und nach jeder Änderung den Eval-Satz laufen lassen. Die Metrik, die Qualitätsregressionen übersteht, sind Dollar pro erledigter, verifizierter Aufgabe. Kosten pro Tag ist die Metrik, die still mitgespielt wird — von den eigenen Agenten, wenn man sie anweist, sie zu spielen.

Urteil, mit beiden Versagensmodi benannt

Der Ankerfall ist reale Arithmetik, gewickelt um einen ungeprüften Tag. Der verifizierbare Kern: Agenten-Flotten werden von Präfix-Neulesen dominiert; der Provider-Cache-Rabatt bei 0,1x ist das, was die Ökonomie trägt; die dramatischen Dollar-Spreads zerlegen sich in öffentliche Preislisten-Verhältnisse und eine Workload-Form-Zahl; und die ehrliche ungecachte Kontrafaktikum-Untergrenze liegt bei ~20.000 $, nicht bei den berichteten 80.000 $ — die Differenz ist Kontrafaktikum-Wahl.

Beide Hype-Versagensmodi liegen denselben Monat auf dem Tisch: „$5/Monat-Personal-Agent"-Geschichten picken sich Gratis-Tier-Routing heraus und ignorieren Flotten-Looping, während der 80.000-gegen-1.300-Dollar-Spread sich einen schweren Basteltag und ein output-lastiges Kontrafaktikum herauspickt. Beide sind wahre Aussagen über ihren je eigenen Tag. Keines generalisiert. Was generalisiert, ist die Form: Flottenkosten sind Cache-Elastizität — die Rechnung ist frische_Arbeit × Preis + Neulesen × 0,1 × Preis, und jede ernsthafte Capacity-Planung misst zuerst den zweiten Term, weil er die größte Zahl auf der Seite ist.

Fußnoten