Agent 向け Claude Fable 5：tool call の拒否と GLM 5.2 とのコスト比較

今回の評価では、Claude Fable 5 が coding agent の 44 turn 中 11 turn で、tool call の生成途中に処理を拒否した。config の default 値を直すだけの単純な task でも発生した。tool の argument を生成している途中で stop_reason: "refusal" が返るが、打ち切られた argument は有効な JSON として parse できる。stop reason を確認せず tool call を実行する agent loop では、書きかけの file がそのまま disk に保存される。Fable 5 を agent に組み込むなら、price より先にこの挙動へ対処する必要がある。

TL;DR

• Claude Fable 5 は、config の default 値修正や meeting room の予約といった単純な agent task でも、tool call の途中に stop_reason: "refusal" を返した。打ち切られた write_file の argument は parse できるため、stop reason を確認しない loop では未完成の file が書き込まれる。
• Fable 5 の thinking は adaptive で、無効にはできない。enabled と disabled はどちらも拒否され、制御には output_config.effort を使う。
• Fable 5 のコスト差は workload の形態によって変わる。4 turn の coding task は glm-5.2 の $0.003 に対して $0.045 で 15 倍だったが、warm cache を使う batch 処理では sonnet-5 の 5 倍にとどまった。
• Fable 5 では 30 日間の data retention が必須となる。

以下はすべて、2026-07-05 に Synthorai gateway 経由で測定した。小規模な scenario harness を使い、tool を使う coding loop、RAG による質問応答、tool を多用する orchestration、batch classification、15 turn の会話という 5 種類の agent workload を、claude-fable-5、claude-opus-4-8、claude-sonnet-5、glm-5.2 で実行した。ばらつきが重要な task は 3 回ずつ測定している。task は意図的に単純にしてあり、pass rate は最低限の正常性確認にすぎず、性能 benchmark ではない。コストには gateway が請求した usage.cost を使った。

tool call を実行する前に stop_reason を確認する

これは document に注意書きがない一方で、state を壊す failure だ。agent は app.py を読み、修正内容を書き込むために write_file call の生成を始める。ところが file content の途中で stream が停止する。

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

input object は完全な JSON として parse できる。途中で止まったことを示す情報は object 内にない。loop の仕様が「tool call を受け取ったら実行する」だけなら、app.py は 38 文字の断片で上書きされる。dictionary の途中で終わっているため Python として parse できず、次の turn も refusal になる。そのまま loop が終了し、workspace だけが壊れる。

data から確認できた点は 3 つある。

• 単純な作業でも発生する。 refusal が出た task は、config 参照時の KeyError 修正、slugify function の実装、meeting room の予約、draft invoice の作成だった。dual-use でも sensitive な内容でもない。
• random ではなく再現する。 ある coding task では、streaming と non-streaming のどちらでも 3 回すべて refusal になった。他の task では一度も発生していない。条件ごとの差はあるが、単純な coding episode における Fable 5 の pass rate は 58〜75% だった。claude-opus-4-8、claude-sonnet-5、glm-5.2 は 100% で、Fable 5 の failure はすべて誤った code ではなく refusal が原因だった。
• 会話に refusal が入ると、その episode は終わる。 以降の turn は空の出力とともに stop_reason: "refusal" を返した。同じ context 内で retry しても回復しなかった。

trigger は task の内容ではない。data は明確だった。毎回 refusal になった task は、config dictionary 内の KeyError を直す 9 行の修正で、credential も exploit も含まれていない。一方、batch scenario では cryptomining、漏えいした Stripe key、phishing page に関する support ticket を一度も拒否せず分類した。RAG scenario でも AES-256-GCM の secret や breach response 手順を大量に含む document に対して問題なく回答した。refusal はすべて、multi-turn で tool を実行する 2 つの scenario で発生した。内容がより重い 3 つの single-shot scenario では一度も発生していない。pattern を決めているのは文言ではなく agent loop の形態なので、input を sanitize しても防げない。

対策は tool 実行前に 1 行追加するだけだ。

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 は仕組みを document に記載している。出力前に refusal が発生した場合、空の content array が返り、課金されない。streaming の途中で発生した場合は、すでに stream された出力が課金対象となり、partial output は破棄するよう案内されている。response には category を含む stop_details object もあり、cyber や bio、または null が設定される。これにより classifier による block と通常の decline を区別できる。ただし document には、上記の tool use との組み合わせが明記されていない。refusal は argument の生成途中でも発生し、partial argument と完全な argument を見分けられない。

公式の recovery 手段もある。Claude API では、beta の fallbacks parameter（betas: ["server-side-fallback-2026-06-01"]、fallbacks: [{"model": "claude-opus-4-8"}]）を使うと、decline された request を同じ call 内で fallback model に再実行できる。出力前に decline された場合、その decline 自体は課金されない。Amazon Bedrock、Vertex AI、Microsoft Foundry では利用できないが、各 SDK には client-side fallback middleware が用意されている。どちらを使う場合も、先に必要なのは上記の guard だ。stop reason が refusal の turn では、tool call を絶対に実行してはいけない。

5 種類の agent workload にかかったコスト

完了した 1 単位あたりの median cost。単位は task、query、item、または conversation で、prompt と測定日は同じである。

この表では、個々の数値よりも次の 2 点が重要だ。

• 最安の model は workload の形態によって変わる。 loop と長い conversation では glm-5.2 が最安だが、batch classifier では claude-sonnet-5 が glm-5.2 より安い。scaffold prompt が warm になると cache read の比率が 97% に達し、導入時の価格が効くためだ。
• Fable 5 の割高幅も workload の形態によって変わる。 coding loop では glm-5.2 の 15 倍、conversation では 11 倍だが、warm cache を使う batch item では sonnet-5 の 5 倍にとどまる。prompt の大半を caching で吸収できるためだ。

残るコストの論点は、これらの数値をどう抑えるかと、抑えた後にひそかにコストを押し上げる 2 つの要因だ。

agent の請求額を抑える

最も効果が大きいのは caching で、Fable 5 でも仕様は変わっていない。agent の測定結果からも効果は明らかだ。cache_control marker を外すと、同じ coding task のコストは 2.0 倍、warm batch item は 6.8 倍になった。opus-4-8 ではそれぞれ 3.8 倍と 6.9 倍だった。loop では sliding-marker pattern は単なる最適化ではない。現実的な請求額に収まるかどうかを分ける。

2 番目に効くのは prompt の順序で、測定したすべての model で同じ結果になった。query ごとの context より前に固定 rule を置くと、逆順にした場合より RAG query が 4 model すべてで 26〜37% 安くなった。Claude 系では、順序を誤ると call のたびに 1.25 倍の cache write premium もかかる。仕組みは LangChain の caching に関する記事で説明している。今回の数値から、Fable 5 でも同じように適用できることが確認できた。

Fable 5 には固有の調整手段も 2 つある。1 つ目は、cache 対象になる下限が Opus 4.8 の 4,096 token の半分にあたる 2,048 token まで下がったことだ。細かい変更に見えるが、agent の節約効果を左右する。cache されるのは system prompt、tool definition、sliding conversation prefix など、繰り返し使う scaffold であり、下限を超えた場合に限られる。turn ごとの prefix が 2,048〜4,096 token だった tool-heavy agent は、Opus 4.8 では一切 caching されなかった。Fable 5 では cache 対象になるため、以降の turn では full price の prefix が約 10% の価格の cache read に変わる。逆の見方もできる。以前の 4,096 token という下限を超えるために padding していた prefix には、不要な内容が残っている可能性がある。推測せず、実際の response から cache_read_input_tokens を確認する必要がある。Fable 5 では discount が始まる位置が早くなっている。

2 つ目は task budget（beta、header は task-budgets-2026-03-13）だ。この比較で繰り返し表れた問題に直接対処できる。Fable 5 の loop は短時間で請求額が膨らみ、max_tokens では防げない。max_tokens は model から見えない response ごとの hard cap なので、model は余裕が無制限にある前提で計画し、途中で突然打ち切られる。task budget は異なる。loop 全体に最低 20,000 の token 上限を設定すると、model は残量の countdown を見ながら処理量を調整し、途中で切断されずに終了できる。対象になるのは model が生成した token と、その turn で model が読んだ tool result であり、request ごとに再送する全 history ではない。coding loop の turn cost が glm-5.2 の 15 倍になる model では、model 自身が消費量を調整できる budget が、最も安価に追加できる guardrail になる。

document では分からない 2 つのコスト要因

各種の調整を行っても、document に注意書きのない 2 つの要因で請求額が増えた。

"low" effort の方が安いとは限らなかった。 Fable 5 の thinking depth は output_config.effort で制御するため、low なら安くなると考えやすい。実際はそうならなかった。coding loop に effort: "low" を設定すると、default の task あたり $0.0451 に対して $0.0478 となり、output token も減るどころか増えた。effort 名と token 数が対応しない GLM 5.2 でも同じ傾向を確認した。どちらの model 系でも、"low" が「少ない」ことを意味すると決めつけず、実際の workload で測定する必要がある。予測が難しい理由の 1 つは、adaptive thinking が output token に占める比率の変動だ。同じ model、同じ日でも、coding loop では 2%、RAG answer では 30%、batch classification では 52% だった。output token の budget は model 単位ではなく、workload の形態ごとに設定するべきだ。

reasoning_content は絶対に再送しない。 OpenAI-compatible model では reasoning field は conversation history ではない。DeepSeek API では除去が必須で、GLM 5.2 では再送できるものの課金対象になる。message history に戻していた間、GLM loop のコストは約 28% 増えた。Anthropic 自身の thinking block は扱いが異なり、同じ model では変更せず再送しなければならない。ただし、Fable 5 の thinking block を別の model に route した場合、たとえば Opus へ fallback した場合は、prompt から自動的に削除されて課金もされない。利用側で除去する必要はない。

request interface の変更点

Fable 5 の request interface は、大部分が Opus 4.7/4.8 および Sonnet 5 と共通している。document によると、次の機能は廃止された。

• thinking: {type: "enabled", budget_tokens: N} は 400 を返す。Claude 3.7 Sonnet から 4.5 系まで使われていた token budget 付きの extended thinking は、4.7 以降の全 model で廃止され、adaptive thinking に置き換えられた。
• thinking: {type: "disabled"} は 400 を返す。これは Fable 5 固有の変更だ。Opus 4.7/4.8 と Sonnet 5 では thinking を無効にできるが、Fable 5 ではできない。
• temperature、top_p、top_k に default 以外の値を指定すると拒否される。
• Assistant-message prefill、つまり末尾に assistant turn を置いた request は 400 を返す。

既存 request の移植で特に問題になりやすいのは、temperature、top_p、top_k の廃止と prefill の廃止だ。thinking と retention の変更は上記および retention に関する記事で説明している。

結論

Fable 5 を agent に組み込む場合、budget より先に engineering 上の対策が必要になる。tool call を実行する前に stop_reason: "refusal" を処理しなければ、config 修正程度の task でも途中で切れた write によって state が壊れる。その後でコストを workload に合わせて調整する。最も効くのは caching だ。cache 対象の下限は 2,048 token に下がったため、prefix を見直す必要がある。task budget を使えば、この比較で turn あたりの請求額が最も高い loop の暴走を防げる。effort: "low" も名前どおりの discount にはならない。budget は workload の形態ごとに考えるべきだ。同じ model でも、coding loop では glm-5.2 の 15 倍、warm cache を使う batch 処理では sonnet-5 の 5 倍になる。ここで Fable 5 を使うべきかどうかを断定する意図はない。default は中立ではなく、請求額と failure mode の両方が agent の形態に左右される。

FAQ

Fable 5 は tool call を頻繁に拒否しますか？ 特定の task に集中して発生した。ある config 修正 task は毎回拒否されたが、他の task では一度も発生しなかった。同じ task で streaming と non-streaming の両方に再現したため、retry で回避できるまれな一時障害ではない。実際の発生率は workload によって変わるが、必要な対策は同じだ。tool call を実行する前に stop_reason を確認する。

Fable 5 の thinking を無効にできますか？ できない。thinking.type.disabled と enabled はどちらも拒否される。thinking は default で adaptive になり、制御手段は output_config.effort だけだ。今回の loop では、low effort にしてもコストは下がらなかった。

Fable 5 が安い選択肢になることはありますか？ 今回の比較対象ではなかった。最も差が小さかったのは warm cache を多用する batch 処理で、sonnet-5 の約 5 倍だった。この workload では warm cache が prompt の大半を吸収する。loop と長い conversation では、測定した model の中で最も高かった。

検証条件：すべての数値は 2026-07-05 に https://synthorai.io/ で測定した。Claude 系には Anthropic-native の /v1/messages、glm-5.2 には /v1/chat/completions を使用した。5 種類の scenario 形態で合計 505 episode、1,022 call を実行し、ばらつきが重要な task は 3 回ずつ測定した。コストは gateway が報告した usage.cost で、表には median を掲載している。task は意図的に単純にしているため、pass rate は最低限の正常性確認であり、性能 benchmark ではない。未測定の性能に関する claim は公開していない。refusal の挙動は streaming と non-streaming の両方で再現した。数値は prompt、region、load によって変わる。

← ブログに戻る