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

Claude Fable 5 hat in unserem Eval bei 11 von 44 Turns eines Coding-Agents mitten im Tool-Call abgebrochen – bei Aufgaben so banal wie dem Reparieren eines Config-Defaults. Die Verweigerung kommt als stop_reason: "refusal" an, während die Tool-Argumente noch generiert werden. Die abgeschnittenen Argumente lassen sich trotzdem als gültiges JSON parsen, und eine Agent-Loop, die Tool-Calls ausführt, ohne den stop_reason zu prüfen, schreibt bereitwillig eine halbfertige Datei auf die Platte. Dieses Verhalten – nicht der Preis – ist das Erste, um das man herumbauen muss, wenn man Fable 5 in einen Agent steckt.

TL;DR

• Claude Fable 5 lieferte bei banalen Agent-Aufgaben (ein Config-Default-Fix, eine Meetingraum-Buchung) mitten im Tool-Call ein stop_reason: "refusal". Die abgeschnittenen write_file-Argumente ließen sich trotzdem parsen, sodass eine Loop, die den stop_reason nicht prüft, halbfertige Dateien schreibt.
• Fable 5s Thinking ist adaptiv und lässt sich nicht abschalten: enabled und disabled werden beide abgelehnt. Gesteuert wird über output_config.effort.
• Der Kostenaufschlag von Fable 5 hängt von der Form ab: eine Coding-Aufgabe über vier Turns kostete 0,045 $ gegenüber 0,003 $ bei glm-5.2 (15x), bei warmer Batch-Arbeit aber nur 5x sonnet-5.
• Fable 5 erfordert eine 30-tägige Datenaufbewahrung.

Alles Folgende wurde am 2026-07-05 über das Synthorai-Gateway mit einem kleinen Szenario-Harness gemessen: fünf Formen von Agent-Workloads (eine Coding-Loop mit Tool-Nutzung, RAG-Frage-Antwort, tool-lastige Orchestrierung, Batch-Klassifikation und eine Konversation über 15 Turns), ausgeführt gegen claude-fable-5, claude-opus-4-8, claude-sonnet-5 und glm-5.2, mit drei Durchläufen pro Aufgabe dort, wo die Varianz eine Rolle spielt. Die Aufgaben sind bewusst trivial; die Pass-Raten sind ein Sanity-Check, kein Capability-Benchmark. Die Kosten sind die vom Gateway abgerechneten usage.cost.

Vor der Ausführung von Tool-Calls das stop_reason prüfen

Vor diesem Fehler warnt die Doku nicht, und er korrumpiert den State. Der Agent liest app.py, entscheidet sich für den Fix und beginnt, einen write_file-Call auszugeben. Mitten im Dateiinhalt bricht der Stream ab:

{
  "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 daran signalisiert “ich habe zu früh aufgehört”. Wenn der Vertrag deiner Loop lautet “Tool-Calls erhalten, also ausführen”, hast du app.py gerade mit einem 38 Zeichen langen Fragment überschrieben, das mitten in einem Dictionary endet und nicht mehr als Python parst. Der nächste Turn ist ebenfalls ein Refusal, und die Loop endet mit korruptem Workspace.

Aus den Daten lassen sich drei Dinge ableiten:

• Es tritt bei banaler Arbeit auf. Refusals gab es beim Fixen eines KeyError in einem Config-Lookup, beim Implementieren einer slugify-Funktion, beim Buchen eines Meetingraums und beim Erstellen eines Rechnungsentwurfs. Nichts Dual-Use, nichts Heikles.
• Es ist reproduzierbar, nicht zufällig. Ein Coding-Task löste in allen drei Runs einen Refusal aus, mit und ohne Streaming. Andere Tasks nie. Über alle Bedingungen hinweg bestanden 58–75 % unserer trivialen Coding-Episoden auf Fable 5, gegenüber 100 % bei claude-opus-4-8, claude-sonnet-5 und glm-5.2. Jeder einzelne Fehlschlag geht auf einen Refusal zurück, nicht auf falschen Code.
• Ist ein Refusal einmal in der Conversation, ist die Episode vorbei. Folge-Turns lieferten stop_reason: "refusal" mit leerem Output. Ein Retry im selben Kontext half nicht.

Der Auslöser ist nicht der Inhalt des Tasks, und die Daten sind hier eindeutig. Der Task, der bei jedem Run refuste, war ein neunzeiliger KeyError-Fix in einem Config-Dictionary, keine Credentials, keine Exploits. Im Batch-Szenario klassifizierte das Modell dagegen Support-Tickets zu Cryptomining, geleakten Stripe-Keys und Phishing-Seiten ohne einen einzigen Refusal, und das RAG-Szenario beantwortete Fragen über Dokumente voller AES-256-GCM-Secrets und Breach-Response-Prozeduren, ebenfalls sauber. Jeder Refusal landete in den beiden Multi-Turn-Szenarien mit Tool-Ausführung; die drei Single-Shot-Szenarien refusten kein einziges Mal, obwohl sie schwereren Inhalt trugen. Das Muster liegt in der Form der Agent-Loop, nicht in den Wörtern. Das heißt: Deine Inputs zu bereinigen verhindert es nicht.

Der Fix ist eine Zeile vor deinem Tool-Ausführungsschritt:

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 die Mechanik: Ein Refusal, der vor jeglichem Output greift, liefert ein leeres content-Array und wird nicht abgerechnet; ein Refusal mitten im Stream berechnet den bereits gestreamten Output, und die Empfehlung lautet, den Teil zu verwerfen. Die Response enthält außerdem ein stop_details-Objekt mit einer Kategorie (etwa cyber oder bio, oder null), sodass sich Classifier-Blocks von gewöhnlichen Ablehnungen unterscheiden lassen. Was die Doku nicht ausformuliert, ist das Zusammenspiel mit Tool-Use, das wir oben getroffen haben: Der Refusal kann mitten in der Argument-Generierung landen, und die Teil-Argumente sind von vollständigen nicht zu unterscheiden.

Es gibt auch einen offiziellen Recovery-Pfad. In der Claude API führt der Beta-Parameter fallbacks (betas: ["server-side-fallback-2026-06-01"], fallbacks: [{"model": "claude-opus-4-8"}]) einen abgelehnten Request innerhalb desselben Calls auf einem Fallback-Modell erneut aus, wobei die Ablehnung selbst nicht abgerechnet wird, wenn sie vor dem Output griff. Auf Amazon Bedrock, Vertex AI und Microsoft Foundry steht das nicht zur Verfügung; dort liefern die SDKs stattdessen eine clientseitige Fallback-Middleware. Welcher Pfad auch greift, der Guard oben kommt trotzdem zuerst: Führe niemals Tool-Calls aus einem Turn aus, dessen Stop-Reason ein Refusal ist.

Was fünf Agentenformen kosten

Median-Kosten pro abgeschlossener Einheit (Task, Query, Item oder Konversation), gleiche Prompts, gleicher Tag:

Aus dieser Tabelle sind zwei Beobachtungen wichtiger als jede einzelne Zelle:

• Das billigste Modell wechselt mit der Form. glm-5.2 gewinnt die Loops und die lange Konversation, aber claude-sonnet-5 ist der günstigste Batch-Klassifikator im Feld, noch unter glm-5.2. Grund ist der Einführungspreis, der bei warmem Scaffold-Prompt auf einem Cache-Read-Anteil von 97% aufsetzt.
• Auch der Aufpreis von Fable 5 hängt von der Form ab: 15x glm-5.2 im Coding-Loop, 11x in der Konversation, aber nur 5x sonnet-5 bei warmen Batch-Items, wo das Caching den Großteil des Prompts abfängt.

Der Rest des Kostenbilds handelt davon, diese Zahlen zu kontrollieren, und dann von zwei Dingen, die sie klammheimlich wieder nach oben treiben.

Die Rechnung eines Agenten niedrig halten

Caching ist der größte einzelne Hebel, und bei Fable 5 bleibt der Vertrag unverändert. Die Agenten-Daten zeigen, was er wert ist: Ohne cache_control-Marker kostete derselbe Coding-Task das 2,0-fache, warme Batch-Items das 6,8-fache. Bei opus-4-8 liest sich dieselbe Ablation als 3,8-fach und 6,9-fach. In einem Loop ist das Muster mit dem gleitenden Marker keine Optimierung, sondern der Unterschied zwischen einer tragbaren Rechnung und keiner.

Die Prompt-Reihenfolge ist der zweite Hebel, und er hielt bei jedem Modell, das wir getestet haben. Stabile Regeln vor den Query-spezifischen Kontext zu setzen (statt dahinter) machte RAG-Queries bei allen vier Modellen 26-37% billiger; bei der Claude-Reihe zahlt die falsche Reihenfolge zusätzlich den Cache-Write-Aufschlag von 1,25x auf jeden Call. Die Mechanik steht im LangChain-Caching-Post; die Zahlen hier bestätigen nur, dass sie unverändert für Fable 5 gilt.

Fable 5 bringt außerdem zwei eigene Hebel mit. Der erste: Die Untergrenze für Cache-Eligibilität ist auf 2.048 Token gefallen, halb so viel wie die 4.096 von Opus 4.8. Das klingt nach Trivia, bis man sich erinnert, woher die Einsparungen eines Agenten kommen: Das wiederholte Scaffold (System-Prompt, Tool-Definitionen, das gleitende Konversations-Präfix) ist das, was gecacht wird, aber nur, wenn es die Untergrenze überschreitet. Ein tool-lastiger Agent, dessen Präfix pro Turn zwischen 2.048 und 4.096 Token lag, bekam auf Opus 4.8 gar kein Caching und beginnt auf Fable 5 zu cachen, wodurch aus einem Präfix zum vollen Preis bei jedem folgenden Turn ein Cache-Read zu etwa 10% des Preises wird. Es wirkt aber auch andersherum: Ein Präfix, das aufgeblasen wurde, um die alte Grenze von 4.096 zu überschreiten, trägt jetzt womöglich totes Gewicht mit sich. Lies cache_read_input_tokens aus einer echten Response ab, statt es anzunehmen, denn bei Fable 5 beginnt der Rabatt früher.

Der zweite sind Task-Budgets (Beta, Header task-budgets-2026-03-13), die genau das Problem adressieren, das dieser Vergleich immer wieder zutage fördert: Ein Fable-5-Loop treibt die Rechnung schnell in die Höhe, und max_tokens hilft nicht. Das ist ein hartes Limit pro Response, das das Modell nicht sieht, also plant das Modell, als hätte es unbegrenzt Platz, und wird dann mitten im Gedanken abgeschnitten. Ein Task-Budget funktioniert anders. Du gibst dem Loop eine Token-Obergrenze (mindestens 20.000), die das Modell als laufenden Countdown sieht und gegen die es sich selbst dosiert, sodass es sauber zum Abschluss kommt statt abgeschnitten zu werden. Gezählt wird, was das Modell generiert, plus die Tool-Ergebnisse, die es im jeweiligen Turn liest, nicht die gesamte History, die du bei jedem Request erneut mitschickst. Bei einem Modell, dessen Coding-Loop-Turn 15x glm-5.2 kostet, ist ein Budget, gegen das sich das Modell selbst mäßigt, das billigste Sicherheitsgeländer, das du anbauen kannst.

Zwei Kostenüberraschungen, vor denen die Docs nicht warnen

Mit gesetzten Stellschrauben verschoben zwei kleinere Dinge unsere Rechnung in Richtungen, vor denen die Dokumentation nicht warnt.

“Low” effort war nicht billiger. Die Denk-Tiefe von Fable 5 wird über output_config.effort gesteuert, und intuitiv würde man annehmen, dass low weniger kostet. Tat es nicht. Mit effort: "low" lief unser Coding-Loop bei $0,0478 pro Task statt $0,0451 im Default – und zwar mit mehr Output-Tokens, nicht weniger. Dasselbe Muster sahen wir bei GLM 5.2, wo die effort-Namen ebenfalls nicht zu den Token-Zahlen passen. Bei beiden Modell-Linien gilt: Miss die Stellschraube an deinem eigenen Workload, bevor du davon ausgehst, dass “low” auch “weniger” bedeutet. Ein Grund, warum die Zahl schwer vorhersagbar ist: Der Anteil des adaptiven Denkens an den Output-Tokens schwankte am selben Tag mit demselben Modell zwischen 2 % beim Coding-Loop, 30 % bei RAG-Antworten und 52 % bei Batch-Klassifikation. Budgetiere Output-Tokens pro Workload-Form, nicht pro Modell.

Spiel reasoning_content niemals erneut ein. Bei OpenAI-kompatiblen Modellen ist das reasoning-Feld kein Teil der Konversationshistorie. DeepSeeks API verlangt, es zu entfernen; bei GLM 5.2 ist das erneute Einspielen erlaubt, wird aber abgerechnet. Es zurück in die Message-Historie zu geben, blähte unsere GLM-Loop-Kosten um etwa 28 % auf, bis wir es entfernten. Anthropics eigene thinking-Blöcke sind anders: Beim selben Modell musst du sie unverändert erneut einspielen, aber ein Fable-5-thinking-Block, der an ein anderes Modell geleitet wird (etwa bei einem Fallback auf Opus), wird automatisch aus dem Prompt entfernt und nicht abgerechnet – es gibt also nichts zu strippen.

Was sich an der Request-Oberfläche geändert hat

Fable 5 teilt sich den Großteil seiner Request-Oberfläche mit Opus 4.7/4.8 und Sonnet 5. Was laut Docs weggefallen ist:

• thinking: {type: "enabled", budget_tokens: N} liefert einen 400. Extended Thinking mit Token-Budget – der Mechanismus von Claude 3.7 Sonnet bis zur 4.5-Familie – wurde in der gesamten 4.7+-Linie zugunsten von adaptivem Denken abgeschaltet.
• thinking: {type: "disabled"} liefert einen 400, und das ist einzigartig für Fable 5. Bei Opus 4.7/4.8 und Sonnet 5 lässt sich das Denken weiterhin abschalten; bei Fable 5 nicht.
• temperature, top_p und top_k werden bei jedem Nicht-Default-Wert abgelehnt.
• Assistant-Message-Prefills (ein abschließender assistant-Turn) liefern einen 400.

Die Entfernungen von temperature/top_p/top_k und Prefill sind die beiden, die einen portierten Request am häufigsten beißen; die Änderungen an Thinking und Retention sind oben und im Retention-Post abgedeckt.

Fazit

Fable 5 in einem Agenten ist ein Engineering-Problem, bevor es ein Budget-Problem ist. Behandle stop_reason: "refusal", bevor du Tool-Calls ausführst, sonst korrumpiert ein abgeschnittener Write den State – bei einer so banalen Aufgabe wie einem Config-Fix. Behandle die Kosten dann als etwas, das du formst: Caching ist die größte Stellschraube, die Untergrenze für Eligibility liegt jetzt bei 2.048 Tokens, prüf also deinen Prefix erneut, ein Task-Budget hält einen Loop davon ab, die höchste Per-Turn-Rechnung in diesem Vergleich aufzutürmen, und effort: "low" ist nicht der Rabatt, den der Name suggeriert. Budgetiere auch nach Workload-Form: Dasselbe Modell kostet beim Coding-Loop das 15-fache von glm-5.2 und bei warmer Batch-Arbeit das 5-fache von sonnet-5. All das sagt nicht, ob du es nutzen sollst oder nicht; es sagt, dass die Defaults nicht neutral sind und sowohl die Rechnung als auch die Fehlermodi davon abhängen, wie dein Agent geformt ist.

FAQ

Verweigert Fable 5 häufig Tool-Calls? Das Verhalten hing an bestimmten Tasks: Ein Config-Fix-Task verweigerte bei jedem Durchlauf, andere nie, und dieselben Tasks reproduzierten das Verhalten sowohl bei streamenden als auch bei nicht-streamenden Calls. Es ist also kein seltener Aussetzer, den man mit einem Retry umgehen kann. Bei deiner Workload werden die Raten anders ausfallen; die technische Konsequenz bleibt dieselbe: 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 output_config.effort ist die einzige Stellschraube; in unserem Loop hat low effort die Kosten nicht gesenkt.

Ist Fable 5 jemals die günstige Option? In diesem Set nicht. Den kleinsten Aufschlag hat es bei Batch-Arbeit mit viel Warm-Cache, etwa 5x sonnet-5, wo ein warmer Cache den Großteil des Prompts abfängt. Bei den Loops und der langen Konversation ist es das teuerste Modell, das wir laufen ließen.

Verifikation: Alle Zahlen gemessen am 05.07.2026 gegen https://synthorai.io/ (Anthropic-natives /v1/messages für die Claude-Reihe, /v1/chat/completions für glm-5.2), 505 Episoden und 1.022 Calls über fünf Szenario-Formen, drei Durchläufe pro Task, wo Varianz eine Rolle spielt. Die Kosten sind die vom Gateway gemeldeten usage.cost; gezeigt werden Mediane. Die Tasks sind bewusst einfach gehalten, Pass-Raten sind also ein Sanity-Check, kein Capability-Benchmark; wir veröffentlichen keine Capability-Behauptungen, die wir nicht gemessen haben. Das Verweigerungsverhalten reproduzierte sich sowohl im Streaming- als auch im Non-Streaming-Modus. Deine Zahlen variieren je nach Prompts, Region und Last.

← Zurück zum Blog