Claude Fable 5 for Agents: Tool-Call Refusals, Cost vs GLM 5.2

Claude Fable 5 refused mid-tool-call on 11 of 44 coding-agent turns in our eval, on tasks as mundane as fixing a config default. The refusal arrives as stop_reason: "refusal" partway through generating the tool arguments, the truncated arguments still parse as valid JSON, and an agent loop that executes tool calls without checking the stop reason will happily write a half-finished file to disk. That behavior, not the price tag, is the first thing to engineer around when you put Fable 5 in an agent.

TL;DR

• Claude Fable 5 returned stop_reason: "refusal" mid-tool-call on mundane agent tasks (a config-default fix, a meeting-room booking); the truncated write_file arguments still parsed, so a loop that doesn't check the stop reason executes half-written files.
• Fable 5's thinking is adaptive, with no off switch: enabled and disabled are both rejected; the control is output_config.effort.
• Fable 5's cost premium is shape-dependent: a four-turn coding task ran $0.045 vs $0.003 on glm-5.2 (15x), but only 5x sonnet-5 on warm batch work.
• Fable 5 requires 30-day data retention.

Everything below was measured on 2026-07-05 through the Synthorai gateway with a small scenario harness: five agent workload shapes (a tool-using coding loop, RAG question answering, tool-heavy orchestration, batch classification, and a 15-turn conversation), run against claude-fable-5, claude-opus-4-8, claude-sonnet-5, and glm-5.2, three runs per task where variance matters. The tasks are deliberately trivial; pass rates are a sanity gate, not a capability benchmark. Costs are the gateway's billed usage.cost.

Check stop_reason before executing tool calls

This is the failure the docs don't warn you about, and it corrupts state. The agent reads app.py, decides to write the fix, and starts emitting a write_file call. Partway through the file content, the stream stops:

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

The input object is complete, parseable JSON. Nothing about it says "I stopped early." If your loop's contract is "got tool calls, run them," you just overwrote app.py with a 38-character fragment that ends mid-dictionary and no longer parses as Python, and the next turn is a refusal too, so the loop ends with the workspace corrupted.

Three things we can say from the data:

• It triggers on mundane work. The tasks that drew refusals were fixing a KeyError in a config lookup, implementing a slugify function, booking a meeting room, and creating a draft invoice. Nothing dual-use, nothing sensitive.
• It is repeatable, not random. One coding task drew a refusal on all three runs, streaming and non-streaming alike. Other tasks never drew one. Across conditions, 58-75% of our trivial coding episodes passed on Fable 5 versus 100% for claude-opus-4-8, claude-sonnet-5, and glm-5.2, and every single failure traces to a refusal, not to wrong code.
• Once a refusal is in the conversation, the episode is done. Follow-up turns returned stop_reason: "refusal" with empty output. Retrying within the same context did not recover.

The trigger is not the task content, and the data is blunt about it. The task that refused every run was a nine-line KeyError fix in a config dictionary, no credentials, no exploits. Meanwhile the batch scenario classified support tickets about cryptomining, leaked Stripe keys, and phishing pages without a single refusal, and the RAG scenario answered over docs full of AES-256-GCM secrets and breach-response procedures, also clean. Every refusal landed in the two multi-turn, tool-executing scenarios; the three single-shot scenarios never refused once, even carrying heavier content. The pattern is the agent-loop shape, not the words, which means sanitizing your inputs won't prevent it.

The fix is one line before your tool-execution step:

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 documents the mechanics: a refusal that fires before any output returns an empty content array and is not billed; a mid-stream refusal bills the already-streamed output, and the guidance is to discard the partial. The response also carries a stop_details object with a category (such as cyber or bio, or null) so you can tell classifier blocks from ordinary declines. What the documentation doesn't spell out is the interaction with tool use we hit above: the refusal can land inside argument generation, and the partial arguments are indistinguishable from complete ones.

There is also an official recovery path. On the Claude API, the beta fallbacks parameter (betas: ["server-side-fallback-2026-06-01"], fallbacks: [{"model": "claude-opus-4-8"}]) re-runs a declined request on a fallback model inside the same call, with the decline itself unbilled when it fired pre-output. It is not available on Amazon Bedrock, Vertex AI, or Microsoft Foundry, where the SDKs ship a client-side fallback middleware instead. Whichever path applies, the guard above still comes first: never execute tool calls from a turn whose stop reason is a refusal.

What five agent shapes cost

Median cost per completed unit (task, query, item, or conversation), same prompts, same day:

Two readings of that table matter more than any single cell:

• The cheapest model changes with the shape. glm-5.2 wins the loops and the long conversation, but claude-sonnet-5 is the cheapest batch classifier in the set, under glm-5.2, because its introductory price rides on a 97% cache-read share once the scaffold prompt is warm.
• Fable 5's premium is shape-dependent too: 15x glm-5.2 on the coding loop, 11x on conversation, but only 5x sonnet-5 on warm batch items, where caching absorbs most of the prompt.

The rest of the cost picture is about controlling those numbers, and then about two things that quietly push them back up.

Keeping an agent's bill down

Caching is the single biggest lever, and on Fable 5 its contract is unchanged. The agent data shows what it is worth: with cache_control markers removed, the same coding task cost 2.0x more, and warm batch items 6.8x more. On opus-4-8 the same ablation reads 3.8x and 6.9x. In a loop, the sliding-marker pattern is not an optimization, it is the difference between a viable bill and not.

Prompt order is the second lever, and it held up across every model we ran. Putting stable rules before per-query context (instead of after it) made RAG queries 26-37% cheaper on all four models; on the Claude line, the wrong order additionally pays the 1.25x cache-write premium on every call. The mechanics are in the LangChain caching post; the numbers here just confirm they apply unchanged to Fable 5.

Fable 5 also adds two levers of its own. The first is that the cache-eligibility floor dropped to 2,048 tokens, half of Opus 4.8's 4,096. That reads like trivia until you remember where an agent's savings come from: the repeated scaffold (system prompt, tool definitions, the sliding conversation prefix) is what caches, and only if it clears the floor. A tool-heavy agent whose per-turn prefix sat between 2,048 and 4,096 tokens got no caching at all on Opus 4.8, and starts caching on Fable 5, turning a full-price prefix into a roughly 10%-of-price cache read on every subsequent turn. It cuts the other way too: a prefix padded to clear the old 4,096 floor may now be carrying dead weight. Read cache_read_input_tokens off a live response rather than assuming, because on Fable 5 the discount begins earlier.

The second is task budgets (beta, header task-budgets-2026-03-13), which address the exact problem this comparison keeps surfacing: a Fable 5 loop runs up a bill fast, and max_tokens does not help. It is a hard per-response cap the model cannot see, so the model plans as if it has unlimited room, then gets cut off mid-thought. A task budget is different. You give the loop a token ceiling (minimum 20,000) that the model sees as a running countdown and paces itself against, wrapping up gracefully instead of being truncated. It counts what the model generates plus the tool results it reads on the turn, not the full history you resend each request. On a model whose coding-loop turn costs 15x glm-5.2, a budget the model self-moderates toward is the cheapest guardrail you can bolt on.

Two cost surprises the docs won't flag

With the levers set, two smaller things still moved our bill in directions the documentation doesn't warn you about.

"Low" effort was not cheaper. Fable 5's thinking depth is controlled by output_config.effort, and the intuition is that low costs less. It didn't. Setting effort: "low" ran our coding loop at $0.0478 per task versus $0.0451 at the default, with more output tokens, not fewer. We saw the same pattern on GLM 5.2, where the effort names don't track token counts either. On both model lines, measure the knob on your own workload before assuming "low" means "less." One reason the number is hard to predict: adaptive thinking's share of output tokens swung from 2% on the coding loop to 30% on RAG answers to 52% on batch classification, same model, same day. Budget output tokens per workload shape, not per model.

Never replay reasoning_content. On OpenAI-compatible models, the reasoning field is not conversation history. DeepSeek's API requires stripping it; on GLM 5.2 replaying it is legal but billed. Feeding it back into the message history inflated our GLM loop cost by about 28% until we stripped it. Anthropic's own thinking blocks are different: on the same model you must replay them unchanged, but a Fable 5 thinking block routed to a different model (say, on a fallback to Opus) is dropped from the prompt automatically and not billed, so there's nothing to strip.

What changed in the request surface

Fable 5 shares most of its request surface with Opus 4.7/4.8 and Sonnet 5. What's gone, per the docs:

• thinking: {type: "enabled", budget_tokens: N} returns a 400. Extended thinking with a token budget, the mechanism from Claude 3.7 Sonnet through the 4.5 family, is retired across the 4.7+ line in favor of adaptive thinking.
• thinking: {type: "disabled"} returns a 400, and this one is unique to Fable 5. Opus 4.7/4.8 and Sonnet 5 still let you switch thinking off; Fable 5 does not.
• temperature, top_p, and top_k are rejected at any non-default value.
• Assistant-message prefills (a trailing assistant turn) return a 400.

The temperature/top_p/top_k and prefill removals are the two that most often bite a ported request; the thinking and retention changes are covered above and in the retention post.

Bottom line

Fable 5 in an agent is an engineering problem before it is a budget problem. Handle stop_reason: "refusal" before executing tool calls, or a truncated write will corrupt state on a task as boring as a config fix. Then treat the cost as something you shape: caching is the biggest lever, the eligibility floor is now 2,048 tokens so re-check your prefix, a task budget keeps a loop from running up the highest per-turn bill in this comparison, and effort: "low" is not the discount its name implies. Budget by workload shape, too: the same model is 15x the cost of glm-5.2 on a coding loop and 5x sonnet-5 on warm batch work. None of this says use it or don't; it says the defaults are not neutral, and the bill and the failure modes both depend on how your agent is shaped.

FAQ

Does Fable 5 refuse tool calls often?
It concentrated on specific tasks: one config-fix task refused on every run, others never did, and the same tasks reproduced under both streaming and non-streaming calls. So it is not a rare flake you can retry past. Rates on your workload will differ; the engineering answer is the same either way: check stop_reason before executing tool calls.

Can I turn Fable 5's thinking off?
No. thinking.type.disabled and enabled are both rejected. Thinking is adaptive by default and output_config.effort is the only control; in our loop, low effort did not reduce cost.

Is Fable 5 ever the cheap option?
Not in this set. Its smallest premium is on warm cache-heavy batch work, about 5x sonnet-5, where a warm cache absorbs most of the prompt. On the loops and the long conversation it is the most expensive model we ran.

Verification: all figures measured 2026-07-05 against https://synthorai.io/ (Anthropic-native /v1/messages for the Claude line, /v1/chat/completions for glm-5.2), 505 episodes and 1,022 calls across five scenario shapes, three runs per task where variance matters. Costs are the gateway-reported usage.cost; medians shown. Tasks are deliberately simple, so pass rates are a sanity gate, not a capability benchmark; we don't publish capability claims we haven't measured. Refusal behavior reproduced in both streaming and non-streaming modes. Your numbers will vary with prompts, region, and load.