Claude Fable und Mythos kosten doppelt so viel wie Opus. Für Agenten können sie günstiger sein

Alle haben dieselbe Schlagzeile gelesen: Claude Fable wurde rund 25 Prozent günstiger, bei agentischer Arbeit bis zu 45 Prozent. Danach war das Thema durch.

Fast niemand hat nachgesehen, welcher Preis sich bewegt hat. Der Basis-Input blieb gleich. Der Output blieb gleich. Die Cache-Writes blieben gleich. Genau eine Zahl hat sich geändert — und sie hat die Form des Kostenmodells verändert, nicht seine Größe.

Hier die Fußnote aus Anthropics Preistabelle, im Wortlaut:

Cache hits and refreshes on Claude Fable 5.1 and Claude Mythos 5.1 are priced at 0.025x the base input price. All other models use the standard 0.1x multiplier.

Jedes Claude-Modell berechnet einen Cache-Read mit einem Zehntel des Basis-Inputs. Die Fable- und Mythos-Linie berechnet ihn mit einem Vierzigstel. Es ist die einzige Ausnahme in der gesamten Tabelle — und sie erzeugt ein Ergebnis, das wie ein Tippfehler aussieht.

Die Inversion

Stellen wir die beiden Frontier-Modelle nebeneinander.

Preise pro Million Token, aus Anthropics veröffentlichter Preisseite, geprüft am 4. September 2026.

Lesen Sie die Cache-Read-Spalte gegen die Basis-Input-Spalte. Fables Basis-Input ist doppelt so hoch wie der von Opus 5. Sein Cache-Read ist halb so hoch.

Das ist kein Rundungsartefakt. Zweieinhalb Prozent von zehn Dollar sind fünfundzwanzig Cent; zehn Prozent von fünf Dollar sind fünfzig. Das Premium-Modell hat den günstigeren Read, und zwar um den Faktor zwei.

Für alles, was bei jedem Zug einen großen Kontext neu liest — und genau das ist ein Agent —, macht die Read-Spalte den größten Teil der Rechnung aus. Also kippt die Rangfolge.

Die 100:1-Regel

Nehmen wir einen Agentenzug im eingeschwungenen Zustand: Der Prefix ist bereits gecacht, das Modell liest ihn, denkt nach und erzeugt Output. Den Write lassen wir zunächst außen vor; wir kommen darauf zurück, denn er ist die andere Hälfte der Geschichte.

Die Kosten dieses Zugs bestehen aus einem Cache-Read des gesamten Prefix plus dem erzeugten Output:

kosten_pro_zug = R * cache_read + O * output_preis

  R = gecachter Prefix, in Token
  O = Output, in Token

Fable schlägt Opus 5, sobald seine Seite des Vergleichs kleiner ist:

  R * 0.25 + O * 50   <   R * 0.50 + O * 25
  O * 25              <   R * 0.25
  R / O               >   100

Sobald Ihr gecachter Kontext mehr als das Hundertfache des Outputs pro Zug beträgt, ist das teure Modell das günstige.

Die allgemeine Form ist es wert, festgehalten zu werden — Preise bewegen sich, dieser Artikel soll es nicht:

R / O  >  (output_fable - output_opus) / (cache_read_opus - cache_read_fable)
       =  (50 - 25) / (0.50 - 0.25)
       =  100

Setzen Sie ein, was die Preistabelle an dem Tag sagt, an dem Sie das lesen.

Dasselbe als nachrechenbare Zahlen:

Der Schnittpunkt bei 200K Prefix und 2K Output ist ein exaktes Unentschieden — eine schöne Plausibilitätsprüfung für die Algebra.

# Kosten eines Agentenzugs im eingeschwungenen Zustand, der einen gecachten Prefix liest.
def turn_cost(cached_tokens, output_tokens, cache_read, output_price):
    return (cached_tokens * cache_read + output_tokens * output_price) / 1_000_000

FABLE = {"cache_read": 0.25, "output_price": 50.0}
OPUS_5 = {"cache_read": 0.50, "output_price": 25.0}

for prefix, out in ((200_000, 1_000), (200_000, 2_000), (200_000, 5_000), (500_000, 2_000)):
    f = turn_cost(prefix, out, **FABLE)
    o = turn_cost(prefix, out, **OPUS_5)
    print(f"{prefix:>7} ctx {out:>5} out  fable ${f:.4f}  opus ${o:.4f}")

Welche Workloads liegen über 100:1? Refactoring über ganze Codebasen, lange Recherchen, Arbeit an Dokumenten und Tabellen, alles mit großer Tool-Oberfläche — genau die Formen, für die Anthropic die Linie beschreibt. Welche liegen darunter? Chat, Textentwürfe, Zusammenfassungen in langen Output, alles, wo das Modell mehr schreibt als es liest.

Die andere Hälfte: die teuersten Writes im Lineup

Der Rabatt gilt ausschließlich für Reads. Writes haben ihre Standard-Multiplikatoren behalten — 1,25x bei 5-Minuten-TTL, 2x bei 1-Stunden-TTL — angewandt auf eine Basis von zehn Dollar. Daraus ergeben sich die höchsten Cache-Write-Preise im aktiven Lineup.

Nun das Verhältnis zwischen beiden:

Jedes andere Modell im Lineup liegt bei 12,5. Die Fable-Linie liegt bei 50.

Ein Cache-Miss auf Fable kostet Sie fünfzig Reads. Auf jedem anderen Modell zwölfeinhalb. Mit 1-Stunden-TTL sind es achtzig.

Das ist der Punkt, an dem aus einer Preisnotiz eine Architekturbedingung wird. Auf anderen Modellen ist Prefix-Stabilität ein Feintuning-Detail mit überschaubarer Ersparnis. Auf dieser Linie ist Ihre Cache-Trefferquote viermal so viel wert — und ein Workload, der seinen Prefix ständig zerstört, kann auf Fable am Ende mehr zahlen als auf Opus, selbst bei einem Leseverhältnis von 250:1.

Wie viele Züge, bis es sich rechnet

Die 100:1-Regel ist der Grenzwert im eingeschwungenen Zustand. Sie unterstellt, dass der Write längst bezahlt und auf null amortisiert ist. Echte Sitzungen sind endlich, die ehrliche Frage lautet also: Wie viele Züge braucht es, bis die günstigeren Reads den teureren Write überholen?

Prefix einmal schreiben, dann N Züge dagegen fahren:

total_fable = R * 12.50 + N * (R * 0.25 + O * 50)
total_opus  = R *  6.25 + N * (R * 0.50 + O * 25)

Fable gewinnt, wenn:
  R * 6.25  <  N * (R * 0.25 - O * 25)
  R / O     >  25 / (0.25 - 6.25 / N)

Der Nenner wird unterhalb von 25 Zügen negativ. Unter 25 Zügen auf einem gecachten Prefix reicht kein Kontextverhältnis aus — Opus 5 gewinnt jedes Mal. Darüber fällt die Hürde rasch:

Zwei dieser Zeilen sind exakte Unentschieden, die Sie von Hand prüfen können. Bei 50 Zügen mit 200K Prefix und 1K Output kommen beide Modelle auf 7,50 $. Bei 100 Zügen mit 200K und 1,5K Output kommen beide auf 15,00 $.

Das setzt voraus, dass der Prefix einmal geschrieben wird — am Stück oder inkrementell im Lauf der Konversation — und dann überlebt. Jede Verdrängung setzt die Amortisation zurück; das ist der Punkt des vorigen Abschnitts aus einer anderen Richtung.

Die praktische Lesart: Langlaufende Coding- und Recherche-Sitzungen nehmen diese Hürde mühelos, weil sie Hunderte Züge gegen einen Prefix fahren. Request-Response-Dienste, die bei jedem Aufruf einen frischen Kontext zusammenbauen, nehmen sie nie — egal, wie groß dieser Kontext ist.

Was den Prefix tatsächlich zerstört

Vor diesem Hintergrund lohnt es sich, genau zu wissen, was einen gecachten Prefix invalidiert. Aus der Caching-Dokumentation:

• Tool-Definitionen — jede Änderung an Name, Beschreibung oder Parametern invalidiert alles: Tools, System und Messages
• Websuche- oder Zitat-Schalter sowie die Speed-Einstellung — invalidieren System- und Message-Caches
• tool_choice — invalidiert Message-Blöcke
• Bilder — eines irgendwo im Prompt hinzuzufügen oder zu entfernen invalidiert Message-Blöcke
• Thinking-Konfiguration und output_config.effort — invalidieren immer Message-Blöcke, auf manchen Modellen zusätzlich Tool- und System-Caches

Und der Fehlerfall, der am meisten kostet und dabei nach Funktion aussieht: ein Breakpoint auf einem Block, der sich bei jeder Anfrage ändert. Legen Sie einen Zeitstempel oder die eingehende Nutzernachricht in den gecachten Block, unterscheidet sich der Prefix-Hash jedes Mal. Sie zahlen bei jeder einzelnen Anfrage einen frischen Write und bekommen nie einen Read. Auf Fable sind das 12,50 $ pro Million Token, dauerhaft, für einen Cache, der nie trifft.

Hinzu kommt ein Lookback-Fenster von 20 Blöcken. Schiebt eine wachsende Konversation Ihren Breakpoint 20 oder mehr Blöcke hinter den letzten Write, findet der Lookback den früheren Eintrag gar nicht und Sie zahlen den vollen Input-Preis. Die Lösung ist ein zweiter Breakpoint, von Anfang an näher an dieser Position platziert, damit sich dort ein Write ansammelt, bevor Sie ihn brauchen.

Wer überhaupt Tools an Agenten anbindet, findet hier viel Überschneidung mit dem, was ich unter MCP-Server sicher bauen und betreiben beschrieben habe — jedes angebundene Tool ist Prefix, dessen Stabilität Sie ab jetzt bezahlen.

Drei Hebel, die kaum jemand nutzt

Systemanweisungen nach messages verlagern. Auf der Fable- und Mythos-Linie sowie auf Opus 5 und Opus 4.8 können Sie eine {"role": "system"}-Nachricht an messages anhängen, statt das system-Feld auf oberster Ebene zu ändern. Der gecachte Prefix bleibt intakt. Auf Sonnet 5 nicht verfügbar.

Effort ändern, ohne dafür zu zahlen. output_config.effort zu ändern invalidiert normalerweise Message-Blöcke. Auf Modellen mit Per-Message-Effort lässt die Änderung, in genau dieser In-messages-Systemnachricht übermittelt, den gecachten Prefix unangetastet. Auf einer Linie, wo ein Miss fünfzig Reads kostet, ist das keine Mikro-Optimierung.

Mit max_tokens: 0 vorwärmen. Die API liest Ihren Prompt, schreibt den Cache an Ihrem Breakpoint und kehrt sofort mit leerem content-Array und null berechneten Output-Token zurück. Feuern Sie das beim Start oder nach Zeitplan, damit die erste echte Anfrage die Cache-Miss-Latenz nicht abbekommt. Die Write-Gebühr fällt trotzdem an — also einmal vorwärmen und warm halten, nicht bei jeder Anfrage.

Zwei kleinere Punkte: Der minimal cachebare Prefix liegt auf dieser Linie bei 512 Token, dem niedrigsten Wert im Lineup (Sonnet 5 braucht 1.024, Haiku 4.5 braucht 4.096). Und bei 1-Stunden-TTL zahlt sich ein einziger vermiedener Re-Write bereits aus, da die Mehrkosten beim Write 0,75x der Basis betragen, gegenüber einem 1,25x-Re-Write, den Sie sonst wiederholen würden.

Gilt das auch auf Vertex AI und Bedrock?

Auf Google Cloud ja — exakt. Die globale Preistabelle von Vertex AI veröffentlicht dieselben Zahlen wie die First-Party-API:

Die Inversion überlebt bis in den Batch-Tarif: Ein gebatchter Cache-Hit kostet 0,125 $ auf Fable gegen 0,25 $ auf Opus 5 — derselbe Faktor zwei.

Zwei Vertex-spezifische Details lohnen sich. Keines der beiden Modelle trägt einen Long-Context-Aufschlag; die Spalte oberhalb von 200K ist identisch mit der darunter, was nicht für jedes Claude-Modell dort gilt (Sonnet 4.5 verdoppelt). Und regionale oder Multi-Region-Endpunkte tragen einen Aufschlag von 10 Prozent gegenüber global — über alle Token-Kategorien inklusive Cache-Reads. Das Verhältnis bleibt, die absoluten Zahlen wandern.

Auf AWS gibt es zwei verschiedene Produkte. Claude Platform on AWS rechnet den Tokenverbrauch zu denselben Standardsätzen ab und rechnet ihn dann in Claude Consumption Units zu 0,01 $ je CCU um — die Arithmetik bleibt gleich, nur die Rechnungseinheit ändert sich. Amazon Bedrock wird vom Partner betrieben und veröffentlicht eigene Sätze; ich konnte von dieser Seite keine maschinenlesbaren Zahlen ziehen und zitiere daher keine. Prüfen Sie sie gegen Ihren eigenen Account, bevor Sie sich dort auf das Verhältnis verlassen.

Vorbehalte, die die Rechnung verändern

Der Tokenizer. Claude 4.7 und neuere nutzen einen neueren Tokenizer, der für denselben Text rund 30 Prozent mehr Token erzeugt. Ihr Prefix ist in Token größer als der entsprechende Prefix auf Sonnet 4.6, Vergleiche pro Token über Modellgenerationen hinweg untertreiben die neueren Modelle also. Das spricht gegen die obige Rechnung und gehört ins Modell, nicht in die Fußnoten.

Multiplikatoren stapeln sich. Der 50-Prozent-Rabatt der Batch-API und der Faktor 1,1 für US-Datenresidenz gelten obendrauf, auch auf Cache-Reads.

Kosten sind nicht die einzige Achse. Anthropics eigene Vergleichstabelle führt Fables Latenz als Slower, Opus 5 dagegen als Moderate. Adaptive Thinking ist immer an, der Default-Effort ist high. Und Fast Mode — die Premium-Stufe, die Geld gegen Geschwindigkeit tauscht — gibt es auf Opus 5 und Opus 4.8, auf Fable überhaupt nicht. Auf einem latenzkritischen Pfad kann das Modell mit den geringeren Kosten pro Zug trotzdem die falsche Wahl sein, und Opus hat einen Geschwindigkeitshebel, den Fable nicht hat.

Anthropic empfiehlt Fable nicht als Standard. Die eigene Modelldokumentation rät, für die meisten Workloads mit Opus 5 zu beginnen und Fable für anspruchsvolles Reasoning und langlaufende agentische Arbeit zu wählen. Nichts hier widerspricht dem. Der Punkt ist enger: Wer Fable für einen kontextlastigen Agenten aus Preisgründen ausgeschlossen hat, hat ihn aus dem falschen Grund ausgeschlossen.

Das Fazit

Der interessante Schritt war kein Rabatt. Es war eine Änderung der Form der Kostenfunktion: ein Multiplikator um den Faktor vier gesenkt, ausschließlich auf Reads, beim teuersten Modell im Lineup.

Das bewirkt dreierlei. Es macht Agenten mit langem Kontext oberhalb einer messbaren Schwelle strukturell günstiger auf dem Frontier-Modell als auf dem Mittelklassemodell. Es macht Cache-Misses relativ zu Hits viermal teurer als anderswo. Und es macht Prefix-Stabilität — welche Tools Sie anbinden, ob sich ein Bild in den Prompt schleicht, wo Ihr Breakpoint sitzt — zu einer Kostenentscheidung erster Ordnung statt zu einem Feintuning-Durchgang.

Bevor Sie irgendetwas umstellen, messen Sie zwei Zahlen, die Sie längst haben. Die API liefert in jeder Antwort cache_read_input_tokens und cache_creation_input_tokens. Ihr Verhältnis sagt Ihnen, ob diese Preisstruktur für Sie oder gegen Sie arbeitet.