2026-09-01、Anthropic が Claude Fable 5.1（モデル ID claude-fable-5-1）を出した。同日、Cursor スタッフの Colin が「Cursor でも使える」とフォーラムに書いている。CursorBench 3.2 で 73.4%。数字だけ見ると「いちばん新しいやつに切り替えれば、その数字が自分のエディタにも来る」ように見える。

来ない。

73.4% は max effort の数字だ。Anthropic のデフォルト effort は high で、max ではない。しかも Privacy Mode をオンにしているチームは、Dashboard で 30 日保持のポリシーを承認するまで、ピッカーにモデルが出てこない。レバーは「最新モデルを選ぶ」ではなく、(1) そもそも使える状態か、(2) effort をどこまで上げるか、(3) 日常作業のデフォルトを Opus 5 のままにするか、の三つだ。

月曜にやることだけ先に書く。

Privacy Mode / Enterprise なら Cursor Dashboard を開いて、Anthropic の 30 日保持（学習用途ではない、危害防止用）をチームとして承認するかどうかを決める。承認するまでリクエストは失敗する。
日常の小さな編集に max effort を常時オンにしない。73.4% はそこまで上げたときの数字で、デフォルトは high。遅い・高い。
Anthropic の公式アドバイスどおり、大半の仕事は Claude Opus 5 をデフォルトにする。Fable 5.1 は長いエージェント作業・重い推論、あるいは Opus 5 を高めの effort にしても評価が足りないときに上げる。
API を自分で叩いているなら、会話履歴は append-only。途中のターンを編集しない。effort を変えたいときは、編集ではなく per-message effort（ベータ）で変える。キャッシュも壊れない。

以下、一次情報だけを根拠に、何がレバーで何がレバーでないかを整理する。

何が出たか（スペックは公式どおり）

Anthropic のモデル概要によると、Claude Fable 5.1 は 2026-09-01 リリース。コンテキスト 1M、最大出力 128K。入力 $10 / MTok、出力 $50 / MTok。Fable 5 と同じ。変わったのはキャッシュ読みで、$0.25 / MTok。これはベース入力の 0.025 倍で、他の Claude モデルが 0.1 倍なのに対して四分の一。5 分キャッシュ書きは $12.50、1 時間は $20。

Adaptive thinking は常時オン。effort で深さを舵取りする。thinking をオフにはできない。thinking: disabled も budget_tokens 付きの enabled も 400 になる。

公式の位置づけははっきりしている。大半のワークロードは Claude Opus 5 から始めよ。 Fable 5.1 は、要求の高い推論と long-horizon なエージェント作業向け。あるいは Opus 5 を高めの effort で回しても評価が足りないとき。Fable 5 からの差分も、effort が高いほど広がると書いてある。long agentic coding、複数ファイルの機能追加、リファクタ、長時間のデバッグとコードレビュー、ドキュメント／スプレッドシート／スライド、多段の調査、1M コンテキストをまたいだ接続、コンピュータ利用。

逆に low effort では、記憶から答えがちで、検索・取得ツールを呼びにくくなる。新鮮な情報が要るターンは effort を上げるか、プロンプト側で検証を促す、というのが公式の注意だ。

73.4% は「最新にした結果」ではない

Colin の投稿（2026-09-01）はこうだ。Cursor で使える。CursorBench 3.2 では max effort で 73.4%。自分の作業を検証するのが上手い、と。

ここで切り取るべきは「73.4%」ではなく「at max effort」の四語だ。Anthropic API のデフォルト effort は high。Cursor 側も、ドキュメントでは strongest results には high thinking variant を推奨している。max を常時にする話ではない。ベンチの頂点と、日常のデフォルトは別物だ。

Fable 5 や Opus 5 の CursorBench 数字を横に並べたくなるが、Colin の一次投稿が明示しているのはこの 73.4%（max effort）だけなので、ここではそれに留める。二次報道の比較表は使わない。

「最新にした」だけでは、ベンチの条件（max effort）も、公式の使い分け（Opus 5 がデフォルト）も、Privacy Mode のゲートも、全部スキップしている。スコアはモデル ID ではなく、effort と前提条件の関数だ。

公式の価格・effort 比較

Anthropic の How it compares から、現行ラインの要点だけ抜く。価格は / MTok、入力 / 出力。

モデル	コンテキスト	最大出力	価格	レイテンシ	Thinking	デフォルト effort
Claude Fable 5.1	1M	128K	$10 / $50	遅め	Adaptive（常時オン）	`high`
Claude Opus 5	1M	128K	$5 / $25	中程度	Adaptive	`high`
Claude Sonnet 5	1M	128K	$2 / $10	速い	Adaptive	`high`

Fable 5.1 の入力・出力は Opus 5 のおよそ倍。Cursor ドキュメントも「about twice Claude Opus 5」と書いている。キャッシュ読みだけが例外で安い。Anthropic 側は 0.025× ベース入力（他モデルは 0.1×）。Cursor ドキュメントは Fable 5 比で言い換えていて、キャッシュ読み $0.25 対 Fable 5 の $1.00、つまり 75% 安い。キャッシュ書きは $12.50 / MTok のまま（Anthropic の 5 分書きと同じ数字。1 時間書き $20 は API 側の表）。

Cursor のプランでは、Fable 5.1 は third-party の Other Models プールから引かれる。入力 $10、キャッシュ書き $12.5、キャッシュ読み $0.25、出力 $50（いずれも / MTok）。「最新にした」あとに請求が跳ねるのは、このプールと、max effort で思考トークンが伸びることの両方だ。

Privacy Mode だと、ピッカー以前の話がある

Colin も Cursor ドキュメントも、同じことを繰り返している。Fable 5.1 のプライバシー扱いは他の Fable と同じ。Anthropic が危害防止のためにエージェント入出力を保持する。学習や製品改善には使わない。30 日で自動・恒久削除（安全調査やリーガルホールドを除く）。デフォルトでは人が読めない。他顧客とは共有しない。

Anthropic 側のモデル概要では、30-day data retention、ZDR では原則使えない（明示的に認可された場合を除く）、Covered Model。

Cursor 側の運用はこうなる。

Privacy Mode がアカウント／チーム／組織でオン、または Enterprise は、管理者がオプトインするまでオフ。Enterprise は Cursor Privacy Mode の設定に関係なく、デフォルトオフ。
ポリシー承認までリクエストは失敗する（privacy-and-data-governance の文言どおり）。
オプトインは チーム全体 に効く。
Teams はポリシー承認が Team 全体。Enterprise は Organization レベルで承認したうえで、team / group の Model Access で誰が選べるかを絞れる。
Fable 5.1 を有効にしても、Cursor の Privacy Mode 設定も、Cursor 自身の保持も変わらない。変わるのは「Anthropic が危害防止用に I/O を 30 日持つことを、チームとして飲んだか」だけ。
Privacy Mode がオフの個人／Team では、デフォルトでオン。

「モデルを最新にしたのに出てこない」は、だいたいこのゲートだ。ピッカーをいじる前に Dashboard を開け。

Cursor ドキュメントのもう一つの実務情報。Fable 5.1 のセキュリティガードレールに引っかかると、Cursor が自動で Claude Opus にルーティングする。自分でリトライしたりモデルを切り替えたりしなくてよい。作業は途切れない。API を直接叩く場合の refusal / fallback（許可されたフォールバック先は Opus 4.8 と Opus 5）とは別レイヤなので、混ぜない。

Cursor での手順（ピッカーと Dashboard）

順番を逆にしない。使える状態にしてから、モデルと thinking を選ぶ。

1. Dashboard でポリシーを決める

https://cursor.com/dashboard/ を開く。
Team Settings へ。Fable 5.1 の Data Retention Policy を表示できる。
Privacy Mode / Enterprise なら、承認するかどうかをチームで決める。承認は Team 全体。Enterprise は org 承認のあと、Model Access でグループ単位に落とす。
承認しないなら、そのチームでは Fable 5.1 は使えない。Opus 5 / Sonnet 5 で足りるかが本題になる。承認しても Privacy Mode はオフにならない。

2. ピッカーでは「最新」ではなく「役割」で選ぶ

Cursor ドキュメント上のモデル ID は claude-fable-5-1。Anthropic API 側のコンテキストは 1M が default かつ maximum。Cursor の料金は Other Models プールから引かれ、入力・出力は Fable 5 と同じ $10 / $50。

推奨の使い分けは公式のままが安全だ。

日常の編集・短い質問: Opus 5（価格 $5 / $25、レイテンシ中程度）。Anthropic も「most workloads は Opus 5」と書いている。
長時間のエージェント、複数ファイルの移行、自分の成果物を検証しながら最後まで走らせたい仕事: Fable 5.1。Colin も「verifying its own work」が得意だと言っている。
さらにベンチの頂点が欲しいときだけ max effort。Cursor は strongest results には high thinking variant を推奨している。thinking variant はある。常時 max ではない。

「Fable に上げたのに遅い・高い」は仕様に近い。比較表の Latency は Slower。デフォルト effort は high。thinking はオフにできない。

API を叩く人向け: effort は途中で変えてよい。履歴は編集するな

Fable 5 から上げるときの破壊的変更は三つ（What's new）。

tool_choice の any / tool は 400。auto と none は従来どおり。thinking が常時オンなので、強制ツール呼び出しは思考を飛ばしてしまう、というのが理由。スキーマは strict: true か structured outputs へ。
以前のモデルは Fable 5.1 の thinking ブロックを読めない。Fable 5.1 は以前のモデルの thinking を読める（一方通行）。途中で Opus 5 などに落とすルータは、そのターンの思考を失う。
以前のターンを編集すると thinking が無効化される。 system、tools、過去メッセージをいじると、次リクエストがエラーになるか、オプトインすればブロックが落とされる。会話は append-only。

additive なほうで、月曜の運用に効くのが per-message effort（ベータ）だ。ヘッダは mid-conversation-output-config-2026-07-01。会話の途中で effort を変えても プロンプトキャッシュは無効化されない。難しいステップだけ上げ、定型は下げる。公式ドキュメントの例を短くすると、こうだ。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: mid-conversation-output-config-2026-07-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 4096,
    "output_config": {"effort": "high"},
    "messages": [
      {"role": "user", "content": "Plan a migration from SQLite to PostgreSQL in three short steps."},
      {"role": "assistant", "content": "1. Export. 2. Create schema. 3. Import and verify."},
      {"role": "system", "content": [], "output_config": {"effort": "low"}},
      {"role": "user", "content": "Summarize the plan in one sentence."}
    ]
  }'

effort-only の system メッセージが、次の user ターンから新しいレベルを効かせる。過去ターンは触っていない。キャッシュも thinking の binding も、これなら保つ、と公式は書いている。

やってはいけないのは、リマインダを過去ターンに注入して次リクエストで消す、system / tools を会話の途中で組み直す、古いターンを並べ替える、thinking ブロックを先頭以外から抜く、あたり。append-only を崩すと、The block is bound to a different conversation の 400 が来る（チェックが効くアカウント・設定の場合）。

批評: 最新モデルはレバーではない

Fable 5.1 自体は、公式が言うとおり long-horizon 向けに伸びている。Colin の「自分の作業を検証する」も、その系統の話だ。キャッシュ読みが四分の一（Cursor ドキュメントなら Fable 5 比 75% 安）なのも、長いエージェントセッションでは実質的な値下げだ。

ただし「Cursor のモデル一覧で一番上を選ぶ」は、次のどれも満たさない。

73.4% の条件（max effort）を再現しない。デフォルトは high。
Anthropic が勧める使い分け（Opus 5 が既定、Fable は足りないとき）を逆転させる。Fable は遅く、入力・出力は Opus の約倍。
Privacy Mode チームでは、承認なしにモデルが存在しない。承認はチーム全体で、30 日保持を飲むことになる。
API 利用者は、履歴編集という「普通のチャット UI がやりがちなこと」で thinking を壊す。effort 変更は壊さない。レバーはそっち。

だから月曜の作業は、モデル ID の書き換えではない。Dashboard の意思決定、effort を常時 max にしないこと、Opus 5 をデフォルトに残すこと、履歴を append-only にすること。その四つをやったあとで、長い仕事にだけ Fable 5.1 を載せる。73.4% が欲しくなったら、そのとき初めて max effort を検討すればいい。

一次情報