2026年9月1日公開のモデル。実験は9月
2026年9月1日に Anthropic が Claude Fable 5.1 を出した。
出典元：Introducing Claude Fable 5.1 and Claude Mythos 5.1 \ Anthropic \ Anthropic
Tomoya個人開発で毎日のモデルにする話ではないと感じるコストの高さ。
しかし使わないのもどうかと思う。。。
Cursor のPlan(計画モード)に1通だけ載せ、実装はしない、という使い方を、公開中のサイト( 旅情コンシェルジュ )で試した。
※役割の分け方自体は、すでに どのモデルが効率的に使えるか に書いてあるので参考にしてほしい。
- 公開中のサイトを対象に、Cursorの計画モードに1通だけ投げた
- モデルは
claude-fable-5-1。Effort は High。 - 作業は約6分。Proの使用量は 19% → 24%（+5ポイント）
- Fable側は約46万トークン。うち大半がキャッシュ読み。入力は14トークン
- 調査役の Composer 2.5 は別枠で約93万トークン。
短い定義と、使う／使わない
今回検証するClaude Fable 5.1 は Anthropic の Mythos クラスで、一般向けに出ている一番上のモデルだ。
主な特徴は、長いコーディングと調査向け。ちなみに同じ中身の Mythos 5.1 は審査制なので、個人開発の話からは外す。
公式の位置づけは明確で、ほとんどの仕事は Claude Opus 5 から始め、Fable 5.1 は Opus 5 の high でも足りないとき、または長いエージェント作業向け、と書いてある。
Tomoya公式からしてもオーバースペックと感じているのでしょうか？
Opus5でも対応できない大規模プロジェクト関係に活躍しそうですね。
Cursor でも Fable は Other Models 枠で、表示価格は入力 $10 / 出力 $50（100万トークン）。
Fable 5 から変わった主因はキャッシュ読みが $0.25 になったことだ。
- 使う（今回の前提）：
-
- 公開中プロダクトの方針。実装はさせない
- 複数ファイルにまたがるが、新規ページは作らない
- Opus や Composer で道筋が描けないときの計画だけ
- 使わない：
-
- 日常の小さな修正（実行は Composer 2.5）
- 長時間の Agent / Cloud Agent 放置（丸投げの実測 とは別物）
- 全チャットの default 指定
- Cursor の計画モードは、モデルを自動では分けない。Fable に切り替えるのは手動。
- 日本語でよく出る「Plan は Fable、実装は Sonnet」は Claude Code の fableplan で、Cursor の計画モードとは別物。
実験：公開中の旅情、計画1通、Build しない
Tomoya新デモは作っていない。公開中のサービスで、実装せずに方針だけ出した。
検証環境
| 項目 | 内容 |
|---|---|
| 日付 | 2026年9月2日 |
| 対象 | 公開中のサイト(旅情コンシェルジュ) |
| モード | 計画モード（Plan） |
| モデル | claude-fable-5-1 |
| Effort | High（Max は使っていない） |
| 通数 | 1通 |
| Build | 未実行 |
| プラン | Cursor Pro |
- やった事：
-
- 計画を3件に閉じた
- リファクタは禁止した
- 気になる画面、絶対やらないこと、受け入れたい見た目や言葉を、自分の意見としてプロンプトに足した
- やらなかった事：
-
- 実装
- リファクタ
- 新規デモの作成
- Max
- Agent への丸投げ
約6分で、使用量は5ポイントだけ増えた計画が返ってくるまで、作業時間は約6分だった。
Settings の使用量は 19% から 24%。増加は 5ポイント。
Fable側のトークンは、合計で約46万だった。内訳はこうなっている。
| 内訳 | 量 |
|---|---|
| 入力 | 14トークン |
| 出力 | 約2万トークン |
| キャッシュ読み | 約35万トークン |
| キャッシュ書き | 約8万トークン |
| Fable合計 | 約46万トークン |
Tomoya入力が14トークン、という点が今回いちばん意外だった。万単位ではない。
5.1 で単価が下がったのが、まさにこの部分である。
実体はキャッシュ読みの約35万だ。
調査はサブエージェントの Composer 2.5 が担い、約93万トークンだった。これは Fable の枠ではないので、46万には足していない。Cursorでの設定どおり、計画中のコード調査・クロールは安いモデル側の枠だ。
上の数字は、公開中のサイト(旅情)に対する計画モード1通・Effort High・Buildなし、の1回分です。
リポジトリの規模、指示の長さ、Effort、通数で変わります。コストの保証ではありません。
円換算はしない。今回の5ポイントは「変更3件、リファクタ禁止」という制限つきの1回で、計画だけならいつも5%という意味ではない。
5.1 で変わったこと（公式）
Fable 5 との表示価格は同じで、入力 $10 / 出力 $50。安いのはキャッシュ読み $0.25（Fable 5 の4分の1）。
Anthropic は典型的な仕事で Fable 5 比 約25%、エージェント寄りの仕事で最大 約45% 安くなる、と説明している。
※これは公式の見積もりで、今回の1回から導いた数字ではない。
今回の使い方で向いていること
向いている
- 公開中のサービスで、触る範囲を先に決めたいとき
- 実装の前に、やらないことを言語化する。範囲を限定してやる
- Proの使用量を、計画だけに使いたいかどうかを自分の数字で見たいとき
向いていない
- その場で直してほしいとき
- 仕様がまだ口頭のままのとき(一つにまとめる)
- 「最高モデルだから全部見てくれたはず」で終わりにしたいとき
Cursor でピッカーに出ないときは、Privacy Mode やチーム設定で Data Retention への同意が先、とドキュメントにある。セーフガードに掛かると Opus へフォールバックし、その分は Fable 料金にならない。
出典:
- Introducing Claude Fable 5.1 and Claude Mythos 5.1
- Claude Fable 5.1の新機能
- Claude Fable 5.1 | Cursor Docs
まとめ：計画にだけ載せた、という実測が欲しかった
やりたかったことは単純で、Fable 5.1 を「全部の工程の主役」にはしない、という自分の使い方を、公開中のサービスで1回測ることだった。
これは無駄な使用量の節約である。個人開発で最高モデルで作業するのは夢でもあるが現実はそう上手くはいかない。
限られたリソースの中でどう成果を出せるのかを検証していく必要があると思う。
モデルの性能が向上していく中でどこにリソースを使うのか、自身での見極めも大事になってくる。
- 2026年9月1日公開の Fable 5.1 を、計画モードだけに使った
- 公開中の旅情で、実装せずに方針を出した。新規デモは作っていない
- 約6分、使用量 +5ポイント。Fable約46万トークンの大半はキャッシュ読み。入力は14トークン
- 調査役の Composer 2.5 は別枠。実行するなら、別セッションで Composer 2.5
親記事の「計画は最高性能、実行は Composer」を、Fable 5.1 の初日以降に一度通した、という記録です。
※本記事は2026年9月時点の、計画モード1回分の実測です。Cursor と Anthropic の仕様・料金は変わります。
今回の検証サイト：
よくある質問
Fable 5.1 は Agent でも使いましたか？
使っていません。今回は計画モードのみです。本文の生成も Fable の Agent には渡していません。
Max にした方が良いですか？
今回は High のままです。Max は試していません。High と Max の差は、この記事では分かりません。
実装はいつやるのですか？
やるなら別セッションです。計画を Build せず、実行は Composer 2.5 に渡す、という親記事の分担のままです。
使用量の5ポイントは安いと言えますか？
この1回が +5ポイントだった、以上のことは言えません。しかし計画範囲を限定する事で消費を抑えて使用できる事が明確になりました。
コメント
コメント一覧 （5件）
[…] CursorのPlanだけFable 5.1 […]
[…] ※2026/9/1 に Fable 5.1登場。計画だけに載せる使い方は こちら […]
[…] 計画役は Fable 5.1、実行が Composer 2.5。計画だけ試した記録 […]
[…] Build しない使い方は、計画モードに Fable 5.1 を1通 […]
[…] Planモードで最新モデルを使った使用量の検証はこの記事から：Fable 5.1 の計画1通 […]