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

In einem Interview im September 2026 beschrieb Freelancer.com-CEO Matt Barrie eine Flotte von rund 44 Agenten, etwa vier Milliarden abgerechnete Tokens an einem Tag und Kosten von ungefähr 1.300 $, darunter rund 900 $ für Anthropic Sonnet. Seinen Angaben zufolge waren drei Milliarden Tokens Prompt-Cache-Lesezugriffe; für denselben Tag ohne Cache mit einem Modell der Opus-Klasse schätzte er etwa 80.000 $¹. Das sind eigene Angaben und Schätzungen, keine unabhängig geprüften Rechnungen.

Öffentliche Preislisten erlauben es, mögliche Rechnungen zu prüfen. Ohne Aufschlüsselung nach Modell, gewöhnlichem Input, Cache-Schreibzugriffen, Cache-Lesezugriffen und Output lässt sich weder die 1.300-$-Rechnung noch das 80.000-$-Kontrafaktum rekonstruieren. Die drei Milliarden Cache-Tokens ergeben laut Aussage einen Anteil von 75 % an allen Tokens, nicht an Requests oder erledigter Arbeit. Diese Unterscheidung ist die Grundlage der folgenden Budgetrechnung. Die Mechanik des KV-Caches erklärt unser KV-Cache-Leitfaden.

Der Ankerfall und die Preisliste

Für ein illustratives Beispiel verwenden wir folgende Listenpreise von Anthropic für die konkret benannten Modelle Sonnet 5 und Opus 5 pro Million Tokens². Die Tabelle belegt nicht, welche Modelle, Routen oder Sonderpreise Barrie tatsächlich nutzte:

Aus dem Interview ergeben sich nur folgende aggregierte Mengen¹:

• Insgesamt rund 4,0 Mrd. Tokens und 1.300 $ Kosten, davon etwa 900 $ für Sonnet.
• Davon rund 3,0 Mrd. Cache-Lesezugriffe, verteilt auf nicht genauer bezeichnete Modelle und Routen.
• Die restlichen rund 1,0 Mrd. Tokens sind keine Cache-Lesezugriffe. Sie enthalten gewöhnlichen Input, eventuell Cache-Schreibzugriffe und Output; diese Aufteilung fehlt.

Bedingter Plausibilitätscheck: Wären alle 3,0 Mrd. Cache-Lesezugriffe Sonnet 5 zum Listenpreis von 0,20 $/M gewesen, kosteten sie allein 600 $. Von den berichteten 900 $ Sonnet-Kosten blieben 300 $, beispielsweise für 100 Mio. gewöhnliche Input-Tokens plus 10 Mio. Output-Tokens. Dieses Beispiel erklärt jedoch nur 110 Mio. der übrigen rund 1 Mrd. Tokens. Die verbleibenden etwa 890 Mio. müssten auf anderen Routen oder zu anderen Preisen abgerechnet worden sein. Die nötigen Routendaten fehlen. Alle vier Milliarden Tokens zum Sonnet-5-Listenpreis anzusetzen, ergibt die berichteten 1.300 $ nicht.

Das 80.000-Dollar-Kontrafaktum

Die 80.000 $ sind eine Schätzung ohne benannten Modell-SKU und ohne Input-Output-Aufteilung. Halten wir die berichteten vier Milliarden Gesamttokens fest und berücksichtigen, dass mindestens drei Milliarden Input-Tokens vorlagen (Cache-Lesezugriffe sind Input), dann ergeben die beispielhaften Opus-5-Preise ohne Cache:

Alle 4 Mrd. Tokens als Input:      4 Mrd. / 1M × 5 $                    = 20.000 $
3 Mrd. Input + 1 Mrd. Output:      3 Mrd. / 1M × 5 $ + 1 Mrd. / 1M × 25 $ = 40.000 $
Bei festem Gesamtvolumen:         20.000 $ + 20 $ × Output-Tokens/M     ≤ 40.000 $

20.000–40.000 $ ist also die Spanne dieses Opus-5-Szenarios mit konstanten Tokenmengen, vor etwaigen Sonderkonditionen. Die frühere Rechnung addierte 2,4 Mrd. Output-Tokens zu den vier Milliarden Gesamttokens und zählte damit den Workload doppelt. Barries „Opus-Klasse“ könnte andere Modelle, Preise, Workloads oder Tokenmengen meinen; das Transkript spezifiziert zu wenig, um 80.000 $ zu verifizieren. Auch die Spanne ist ein Szenario und keine rekonstruierte Rechnung.

Warum sich der 61,5-fache Abstand nicht zerlegen lässt

80.000 / 1.300 ≈ 61,5× vergleicht ein geschätztes Kontrafaktum mit einer selbstberichteten Rechnung für mehrere Modelle. Aus den veröffentlichten Aggregaten lassen sich Cache- und Modellbeitrag nicht getrennt messen. Ein engeres, reproduzierbares Nur-Input-Beispiel lautet:

7,69× ist keine Zerlegung des berichteten 61,5×-Abstands. Barries 75 % beziehen sich auf alle Tokens; das Rechenbeispiel benötigt den Cache-Anteil unter Input-Tokens. Dieser ist ohne Output-Aufschlüsselung unbekannt. Ebenso fehlen die Aufgabenzahl und die Ergebnisqualität.

Warum wiederholte Präfixe wichtig sind

Viele Agenten-Harnesses senden bei jedem Modellaufruf einen wachsenden Gesprächspräfix erneut: Systemanweisungen, Tool-Definitionen und bisherige Nachrichten bleiben gleich, während sich das Ende ändert. Bleibt der Präfix cachefähig und erreicht der Request rechtzeitig dieselbe kompatible Route, kann der Provider ihn als Cache-Treffer abrechnen. Andere Harnesses kürzen, komprimieren oder strukturieren Kontext neu. Die behaupteten 75 % sind daher kein allgemeiner Agentenwert³.

Anthropic gibt Cache-Lesezugriffe mit 0,1× des gewöhnlichen Input-Preises an, Schreibzugriffe je nach TTL mit 1,25× oder 2×; andere Provider haben andere Regeln²³. Gecachter Input ist billiger, aber nicht gratis. Fügt ein Loop in n Schritten jeweils L Tokens hinzu und kürzt nichts, können rund L·n(n−1)/2 erneut gesendete Präfix-Tokens entstehen. Dieses quadratische Modell für das Input-Volumen gilt nur unter den genannten Annahmen. Zur Rechnung gehören zusätzlich Cache-Erzeugung, Output, Routing und eventuelle Kompression.

Cache-TTL, minimale Präfixlänge und Provider-Routing beeinflussen die Trefferrate. OpenRouter dokumentiert bei Anthropic Optionen von fünf Minuten und einer Stunde und stellt auf unterstützten Routen cached_tokens in den Nutzungsdaten bereit³. Den eigenen Workload messen, statt Barries Anteil zu übernehmen.

Die behauptete Selbstoptimierung um 85 %

Barrie sagte außerdem, eine Anweisung zur Optimierung des Tokenverbrauchs habe diesen um weitere 85 % gesenkt¹. Das vom Podcast veröffentlichte Transkript enthält keine Vorher-Nachher-Evaluation für Aufgabenerfüllung oder Fehlerrate. Es bleibt eine ungeprüfte Verbrauchsangabe. Eine kürzere Ausführung kann nützliche Wiederholung vermeiden, weniger Output liefern, Versuche auslassen oder Aufgaben abbrechen. Erst Kosten pro erfolgreich erledigter und geprüfter Aufgabe zeigen, ob die Reduktion ohne Qualitätsverlust spart.

Eine Flotte skalieren

Barrie sprach davon, aus ungefähr 40 Agenten 400 zu machen¹. 1.300 $/Tag mit zehn zu multiplizieren ergibt 13.000 $/Tag nur dann, wenn Arbeit pro Agent, Modellmix, Preise und Cache-Trefferraten konstant bleiben. Innerhalb einer Aufgabe kann ein immer wieder gesendeter, ungekürzter Präfix ungefähr quadratisch mit der Schrittzahl wachsen; Kontextkompression und Fenstergrenzen verändern das. Schrittbudgets und gemessene Cache-Daten gehören deshalb zur Kapazitätsplanung.

Als Größenordnung: OpenRouter meldete im August 2026 mehr als zehn Billionen Tokens pro Tag. Vier Milliarden Tokens entsprächen bei diesem Volumen weniger als 0,04 % eines Plattformtages. Dieser Anteil sagt nichts über Barries Rechnung aus. Für eine weltweite Leistungsabschätzung bräuchte man einen gemessenen Workload-Mix, Modelloperationen, Hardwareeffizienz und Rechenzentrums-Overhead; die Tokenzahl aus dem Interview reicht nicht.

Checkliste für die Kapazitätsplanung

1. Tokenklassen je Modell und Route erfassen. Gewöhnlichen Input, Cache-Schreibzugriffe, Cache-Lesezugriffe und Output getrennt messen. Aus total_tokens allein lässt sich keine Rechnung rekonstruieren.
2. Für die Cache-Formel die Input-Trefferrate verwenden. Bei 0,1× Lesepreis und ohne Schreibaufschlag ist 1 − 0,9h der Nur-Input-Kostenfaktor, wenn h für gecachten Input geteilt durch gesamten Input steht. h=0,75 ergibt 0,325. Barries 75 % haben alle Tokens als Nenner und dürfen ohne Input-Output-Aufteilung nicht für h eingesetzt werden.
3. Kompatibilität und Ablauf messen. Stabile Präfixe, Cache-Mindestlänge, TTL und Sticky Routing verändern die tatsächliche Trefferrate³. Cache-Schreibzugriffe können vorübergehend mehr kosten als gewöhnlicher Input.
4. Aufgabentiefe begrenzen und Kompression testen. In einem Loop mit festem Tokenzuwachs und ohne Kürzung reduziert eine Halbierung der Schritte die Präfixwiederholung ungefähr auf ein Viertel. Die Erfolgsquote dabei prüfen.
5. Kosten pro erledigter Aufgabe vergleichen. Vor und nach Änderungen an Modellrouting, Promptlänge oder Cache-Regeln denselben Testsatz verwenden.

Fazit

Das Interview belegt Barries Aussagen, aber keine aufgeschlüsselte Abrechnung. Öffentliche Preise stützen für vier Milliarden feste Tokens mit mindestens drei Milliarden Input-Tokens das bedingte Opus-5-Szenario von 20.000–40.000 $ ohne Cache. Sie belegen weder die geschätzten 80.000 $ noch rekonstruieren sie die gemischte 1.300-$-Rechnung. Prompt-Caching kann Input-Kosten deutlich senken; wie viel es hier beigetragen hat, erfordert die fehlende Tokenklassen-Aufschlüsselung.

Fußnoten