Claude Fable 5 für Agents: Tool-Call-Refusals, Kosten vs GLM 5.2

Claude Fable 5 brach in unserem Eval 11 von 44 Turns eines Coding-Agents mitten im Tool Call mit einer Refusal ab. Betroffen waren selbst banale Aufgaben wie das Korrigieren eines Standardwerts in einer Konfiguration. Während die Tool-Argumente noch generiert werden, endet die Ausgabe mit stop_reason: "refusal". Die abgeschnittenen Argumente sind trotzdem gültiges JSON. Führt ein Agent-Loop Tool Calls aus, ohne vorher den Stop-Grund zu prüfen, schreibt er dadurch problemlos eine unvollständige Datei auf die Festplatte. Wer Fable 5 in einem Agent einsetzt, muss zuerst dieses Verhalten absichern, nicht den Preis.

TL;DR

• Claude Fable 5 lieferte bei alltäglichen Agent-Aufgaben mitten im Tool Call stop_reason: "refusal" zurück, etwa beim Korrigieren eines Konfigurations-Defaults oder beim Buchen eines Besprechungsraums. Die abgeschnittenen write_file-Argumente ließen sich weiterhin parsen. Ein Loop, der den Stop-Grund nicht prüft, führt den Call aus und schreibt unvollständige Dateien.
• Das Thinking von Fable 5 ist adaptiv und lässt sich nicht abschalten: Sowohl enabled als auch disabled werden abgelehnt. Gesteuert wird es über output_config.effort.
• Der Kostenaufschlag von Fable 5 hängt vom Workload ab: Eine Coding-Aufgabe mit vier Turns kostete $0.045 gegenüber $0.003 auf glm-5.2, also das 15-Fache. Bei warmem Batch-Processing waren es dagegen nur 5x gegenüber sonnet-5.
• Fable 5 setzt eine Datenspeicherung von 30 Tagen voraus.

Alle folgenden Messungen liefen am 2026-07-05 über das Synthorai-Gateway mit einem kleinen Szenario-Harness. Getestet wurden fünf typische Agent-Workloads: ein Coding-Loop mit Tool-Nutzung, RAG-Fragebeantwortung, Tool-lastige Orchestrierung, Batch-Klassifizierung und eine Unterhaltung über 15 Turns. Verglichen wurden claude-fable-5, claude-opus-4-8, claude-sonnet-5 und glm-5.2. Wo die Varianz relevant war, wurde jede Aufgabe dreimal ausgeführt. Die Aufgaben sind bewusst trivial. Die Erfolgsquote dient nur als Plausibilitätsprüfung, nicht als Capability-Benchmark. Als Kosten verwenden wir den vom Gateway abgerechneten Wert unter usage.cost.

Vor dem Ausführen von Tool Calls stop_reason prüfen

Vor diesem Fehler warnt die Dokumentation nicht, obwohl er den Zustand beschädigen kann. Der Agent liest app.py, beschließt, den Fehler zu korrigieren, und beginnt mit der Ausgabe eines write_file-Calls. Mitten im Dateiinhalt stoppt der Stream:

{
  "stop_reason": "refusal",
  "content": [{
    "type": "tool_use",
    "name": "write_file",
    "input": {
      "path": "app.py",
      "content": "DEFAULTS = {\n    \"timeout_s\": 30,\n    "
    }
  }]
}

Das input-Objekt ist vollständiges, parsebares JSON. Nichts darin signalisiert, dass die Generierung vorzeitig abgebrochen wurde. Lautet der Vertrag deines Loops schlicht „Tool Calls erhalten, also ausführen“, überschreibt er app.py mit einem 38 Zeichen langen Fragment. Die Datei endet mitten im Dictionary und ist kein gültiges Python mehr. Der nächste Turn endet ebenfalls mit einer Refusal. Der Loop bricht ab und hinterlässt einen beschädigten Workspace.

Aus den Daten lassen sich drei Punkte ableiten:

• Das passiert bei alltäglichen Aufgaben. Refusals traten beim Beheben eines KeyError in einem Konfigurations-Lookup, beim Implementieren einer Slugify-Funktion, beim Buchen eines Besprechungsraums und beim Erstellen eines Rechnungsentwurfs auf. Keine dieser Aufgaben war Dual-Use oder sensibel.
• Das Verhalten ist reproduzierbar, nicht zufällig. Eine Coding-Aufgabe führte in allen drei Durchläufen zu einer Refusal, sowohl mit als auch ohne Streaming. Andere Aufgaben waren nie betroffen. Je nach Testbedingung wurden 58-75% unserer trivialen Coding-Episoden mit Fable 5 erfolgreich abgeschlossen. Bei claude-opus-4-8, claude-sonnet-5 und glm-5.2 waren es jeweils 100%. Jeder einzelne Fehler ging auf eine Refusal zurück, nicht auf falschen Code.
• Sobald eine Refusal im Gesprächsverlauf steht, ist die Episode beendet. Nachfolgende Turns lieferten stop_reason: "refusal" mit leerer Ausgabe. Ein Retry im selben Kontext führte nicht zur Erholung.

Der Inhalt der Aufgabe ist nicht der Auslöser. Die Daten sind hier eindeutig. Die Aufgabe, die in jedem Durchlauf abgelehnt wurde, war ein neun Zeilen langer Fix für einen KeyError in einem Konfigurations-Dictionary, ohne Zugangsdaten oder Exploits. Gleichzeitig klassifizierte das Batch-Szenario Support-Tickets zu Cryptomining, geleakten Stripe-Keys und Phishing-Seiten ohne eine einzige Refusal. Auch das RAG-Szenario beantwortete Fragen anhand von Dokumenten voller AES-256-GCM-Secrets und Abläufen zur Reaktion auf Sicherheitsverletzungen problemlos. Sämtliche Refusals traten in den beiden mehrstufigen Szenarien mit Tool-Ausführung auf. Die drei Single-Shot-Szenarien lieferten trotz heiklerer Inhalte nie eine Refusal. Das Muster hängt von der Form des Agent-Loops ab, nicht von einzelnen Begriffen. Eine Bereinigung der Eingaben verhindert es daher nicht.

Vor der Tool-Ausführung genügt diese eine Prüfung:

if response.stop_reason == "refusal":
    # do NOT execute tool calls from this turn: arguments may be truncated
    raise AgentInterrupted("model refused; restart episode or escalate")

Anthropic dokumentiert den Ablauf: Erfolgt die Refusal vor der ersten Ausgabe, enthält die Antwort ein leeres content-Array und wird nicht abgerechnet. Bei einer Refusal mitten im Stream wird die bereits ausgegebene Antwort berechnet; das Teilstück soll verworfen werden. Die Response enthält außerdem ein stop_details-Objekt mit einer Kategorie wie cyber oder bio, gegebenenfalls auch null. Damit lassen sich Blockierungen durch einen Classifier von gewöhnlichen Ablehnungen unterscheiden. Die Dokumentation erklärt allerdings nicht, wie sich das auf Tool-Nutzung auswirkt: Eine Refusal kann mitten in der Generierung der Argumente auftreten, und die unvollständigen Argumente lassen sich nicht von vollständigen unterscheiden.

Es gibt außerdem einen offiziellen Fallback-Mechanismus. In der Claude API führt der Beta-Parameter fallbacks (betas: ["server-side-fallback-2026-06-01"], fallbacks: [{"model": "claude-opus-4-8"}]) eine abgelehnte Anfrage innerhalb desselben Calls erneut mit einem Fallback-Modell aus. Erfolgt die Ablehnung vor der Ausgabe, wird sie nicht abgerechnet. Auf Amazon Bedrock, Vertex AI und Microsoft Foundry ist diese Funktion nicht verfügbar. Dort enthalten die SDKs stattdessen eine clientseitige Fallback-Middleware. Unabhängig vom verwendeten Weg gilt zuerst die obige Absicherung: Tool Calls aus einem Turn mit einer Refusal als Stop-Grund dürfen nie ausgeführt werden.

Kosten der fünf Agent-Workloads

Median der Kosten pro abgeschlossener Einheit, also Aufgabe, Anfrage, Item oder Unterhaltung, mit denselben Prompts am selben Tag:

Zwei Erkenntnisse aus dieser Tabelle sind wichtiger als einzelne Werte:

• Welches Modell am günstigsten ist, hängt vom Workload ab. Bei den Loops und der langen Unterhaltung gewinnt glm-5.2. Für die Batch-Klassifizierung ist dagegen claude-sonnet-5 das günstigste Modell im Vergleich und unterbietet glm-5.2. Der Grund ist sein Einführungspreis in Verbindung mit einem Cache-Read-Anteil von 97%, sobald der Scaffold-Prompt warm ist.
• Auch der Aufpreis von Fable 5 hängt vom Workload ab: Beim Coding-Loop kostet es 15x so viel wie glm-5.2, bei der Unterhaltung 11x. Bei warmen Batch-Items sind es dagegen nur 5x gegenüber sonnet-5, weil der Cache den größten Teil des Prompts abdeckt.

Für den Rest der Kostenbetrachtung geht es zunächst darum, diese Werte zu steuern. Danach folgen zwei Faktoren, die sie unbemerkt wieder erhöhen.

Kosten eines Agents begrenzen

Caching ist der mit Abstand größte Hebel. Bei Fable 5 ist der Caching-Vertrag unverändert. Die Agent-Daten zeigen den Effekt: Ohne cache_control-Marker kostete dieselbe Coding-Aufgabe 2.0x so viel, warme Batch-Items 6.8x so viel. Bei opus-4-8 lagen die Faktoren im gleichen Test bei 3.8x beziehungsweise 6.9x. In einem Loop ist das Sliding-Marker-Muster keine optionale Optimierung. Es entscheidet darüber, ob die Kosten überhaupt tragbar sind.

Die Reihenfolge im Prompt ist der zweitgrößte Hebel und zeigte bei allen getesteten Modellen denselben Effekt. Standen stabile Regeln vor dem anfragespezifischen Kontext statt dahinter, waren RAG-Anfragen bei allen vier Modellen 26-37% günstiger. Bei den Claude-Modellen führt die falsche Reihenfolge zusätzlich dazu, dass bei jedem Call der 1.25x-Aufschlag für Cache Writes anfällt. Die technischen Details stehen im Beitrag zu LangChain-Caching. Unsere Messwerte bestätigen, dass sie unverändert für Fable 5 gelten.

Fable 5 bringt außerdem zwei eigene Stellschrauben mit. Erstens ist die Mindestgröße für Cache-Fähigkeit auf 2,048 Tokens gesunken, also auf die Hälfte der 4,096 Tokens von Opus 4.8. Das wirkt nebensächlich, ist für Agents aber relevant: Die Einsparungen entstehen durch den wiederholten Scaffold aus System-Prompt, Tool-Definitionen und dem gleitenden Präfix der Unterhaltung. Dieser Teil wird nur gecacht, wenn er die Mindestgröße erreicht. Ein Tool-lastiger Agent mit einem Präfix zwischen 2,048 und 4,096 Tokens erhielt bei Opus 4.8 überhaupt kein Caching. Bei Fable 5 wird dasselbe Präfix gecacht. Nach dem ersten Turn wird daraus bei jedem weiteren Turn ein Cache Read, der nur ungefähr 10% des regulären Preises kostet. Der Effekt kann auch in die andere Richtung gehen: Ein Präfix, das künstlich auf die alte Schwelle von 4,096 Tokens aufgefüllt wurde, enthält möglicherweise unnötigen Ballast. Lies cache_read_input_tokens aus einer echten Response aus, statt Annahmen zu treffen. Bei Fable 5 greift der Rabatt früher.

Zweitens gibt es Task Budgets als Beta-Funktion mit dem Header task-budgets-2026-03-13. Sie lösen genau das Problem, das in diesem Vergleich immer wieder sichtbar wird: Ein Loop mit Fable 5 verursacht schnell hohe Kosten, und max_tokens hilft dabei nicht. max_tokens ist ein hartes Limit pro Response, das dem Modell nicht bekannt ist. Es plant daher mit unbegrenztem Platz und wird anschließend mitten im Gedankengang abgeschnitten. Ein Task Budget funktioniert anders. Der Loop erhält ein Token-Limit von mindestens 20,000, das dem Modell als laufender Countdown bekannt ist. Dadurch kann es seine Ausgabe entsprechend einteilen und sauber abschließen, statt abgeschnitten zu werden. Gezählt werden die vom Modell generierten Tokens plus die Tool-Ergebnisse, die es im jeweiligen Turn liest. Der bei jeder Anfrage erneut übertragene vollständige Verlauf zählt nicht. Bei einem Modell, dessen Coding-Loop-Turn 15x so viel kostet wie bei glm-5.2, ist ein vom Modell selbst berücksichtigtes Budget die günstigste nachrüstbare Schutzmaßnahme.

Zwei unerwartete Kostentreiber, vor denen die Dokumentation nicht warnt

Auch bei korrekt gesetzten Stellschrauben beeinflussten zwei kleinere Faktoren unsere Kosten in einer Weise, auf die die Dokumentation nicht hinweist.

„Low“ Effort war nicht günstiger. Die Thinking-Tiefe von Fable 5 wird über output_config.effort gesteuert. Naheliegend wäre, dass low weniger kostet. In unseren Tests war das nicht der Fall. Mit effort: "low" kostete der Coding-Loop $0.0478 pro Aufgabe gegenüber $0.0451 mit dem Default und erzeugte mehr Output-Tokens, nicht weniger. Dasselbe Muster zeigte sich bei GLM 5.2, wo die Effort-Bezeichnungen ebenfalls nicht mit der Token-Anzahl korrelieren. Bei beiden Modellreihen solltest du die Einstellung mit deinem eigenen Workload messen, statt „low“ automatisch mit „weniger“ gleichzusetzen. Die Werte sind auch deshalb schwer vorherzusagen, weil der Anteil des adaptiven Thinkings an den Output-Tokens stark schwankte: 2% beim Coding-Loop, 30% bei RAG-Antworten und 52% bei der Batch-Klassifizierung, jeweils mit demselben Modell am selben Tag. Plane Output-Tokens pro Workload, nicht pro Modell.

reasoning_content nie erneut mitsenden. Bei OpenAI-kompatiblen Modellen ist das Reasoning-Feld kein Bestandteil des Gesprächsverlaufs. Die DeepSeek API verlangt, dass es entfernt wird. Bei GLM 5.2 darf es erneut gesendet werden, wird dann aber abgerechnet. Das Zurückschreiben in die Message-History erhöhte die Kosten unseres GLM-Loops um etwa 28%, bis wir das Feld entfernten. Anthrops eigene Thinking-Blöcke verhalten sich anders: Beim selben Modell müssen sie unverändert erneut gesendet werden. Wird ein Thinking-Block von Fable 5 dagegen an ein anderes Modell weitergeleitet, etwa bei einem Fallback auf Opus, wird er automatisch aus dem Prompt entfernt und nicht abgerechnet. Dort muss also nichts manuell entfernt werden.

Änderungen an der Request-Schnittstelle

Fable 5 verwendet größtenteils dieselbe Request-Schnittstelle wie Opus 4.7/4.8 und Sonnet 5. Laut Dokumentation wurden folgende Funktionen entfernt:

• thinking: {type: "enabled", budget_tokens: N} liefert einen 400-Fehler. Extended Thinking mit einem Token-Budget, wie es von Claude 3.7 Sonnet bis zur 4.5-Familie verwendet wurde, ist in der gesamten 4.7+-Reihe durch adaptives Thinking ersetzt worden.
• thinking: {type: "disabled"} liefert ebenfalls einen 400-Fehler. Das gilt nur für Fable 5. Bei Opus 4.7/4.8 und Sonnet 5 lässt sich Thinking weiterhin abschalten, bei Fable 5 nicht.
• temperature, top_p und top_k werden bei jedem Wert abgelehnt, der vom Default abweicht.
• Prefills über eine Assistant-Message, also einen abschließenden assistant-Turn, liefern einen 400-Fehler.

Beim Portieren bestehender Requests verursachen vor allem die entfernte Unterstützung für temperature/top_p/top_k und für Prefills Probleme. Die Änderungen bei Thinking und Datenspeicherung wurden oben sowie im Beitrag zur 30-tägigen Datenspeicherung behandelt.

Fazit

Bei Fable 5 in einem Agent ist zuerst die technische Absicherung relevant, erst danach das Budget. Prüfe stop_reason: "refusal", bevor du Tool Calls ausführst. Andernfalls kann ein abgeschnittener Schreibvorgang selbst bei einer so banalen Aufgabe wie einem Konfigurations-Fix den Zustand beschädigen. Anschließend musst du die Kosten aktiv steuern: Caching ist der größte Hebel. Die Mindestgröße liegt jetzt bei 2,048 Tokens, weshalb du dein Präfix erneut prüfen solltest. Ein Task Budget verhindert, dass ein Loop die höchsten Kosten pro Turn in diesem Vergleich unkontrolliert weiter erhöht. Und effort: "low" bietet nicht den Rabatt, den der Name vermuten lässt. Auch die Budgetierung sollte nach Workload erfolgen: Dasselbe Modell kostet beim Coding-Loop 15x so viel wie glm-5.2 und bei warmem Batch-Processing 5x so viel wie sonnet-5. Daraus folgt weder, dass man Fable 5 einsetzen sollte, noch dass man darauf verzichten muss. Die Defaults sind jedoch nicht neutral. Sowohl die Kosten als auch die Fehlermodi hängen von der Struktur des Agents ab.

FAQ

Verweigert Fable 5 häufig Tool Calls? Die Refusals konzentrierten sich auf bestimmte Aufgaben: Eine Konfigurationskorrektur wurde in jedem Durchlauf abgelehnt, andere Aufgaben nie. Dasselbe Verhalten ließ sich mit und ohne Streaming reproduzieren. Es handelt sich also nicht um einen seltenen Ausreißer, den ein Retry zuverlässig behebt. Die Häufigkeit wird bei deinem Workload anders ausfallen. Die technische Konsequenz bleibt gleich: Prüfe stop_reason, bevor du Tool Calls ausführst.

Kann ich das Thinking von Fable 5 abschalten? Nein. Sowohl thinking.type.disabled als auch enabled werden abgelehnt. Thinking ist standardmäßig adaptiv und lässt sich nur über output_config.effort steuern. In unserem Loop reduzierte low Effort die Kosten nicht.

Ist Fable 5 in manchen Fällen die günstige Option? Nicht in diesem Vergleich. Der geringste Aufpreis entstand bei warmem, Cache-lastigem Batch-Processing. Dort kostete Fable 5 etwa 5x so viel wie sonnet-5, weil der warme Cache den größten Teil des Prompts abdeckte. Bei den Loops und der langen Unterhaltung war es das teuerste getestete Modell.

Verifizierung: Alle Werte wurden am 2026-07-05 über https://synthorai.io/ gemessen. Für die Claude-Modelle kam der Anthropic-native Endpoint /v1/messages zum Einsatz, für glm-5.2 /v1/chat/completions. Insgesamt umfasste der Test 505 Episoden und 1,022 Calls über fünf Szenarien; bei relevanter Varianz wurde jede Aufgabe dreimal ausgeführt. Die Kosten entsprechen dem vom Gateway gemeldeten Wert unter usage.cost; angegeben sind Mediane. Die Aufgaben sind bewusst einfach. Die Erfolgsquoten dienen daher als Plausibilitätsprüfung, nicht als Capability-Benchmark. Wir veröffentlichen keine Capability-Aussagen, die wir nicht gemessen haben. Das Refusal-Verhalten ließ sich sowohl mit als auch ohne Streaming reproduzieren. Deine Werte können je nach Prompts, Region und Auslastung abweichen.

← Zurück zum Blog