Claude Fable 5.1 のプロンプティング

モデルの機能、APIの変更点、価格、提供状況については、Claude Fable 5.1 の新機能を参照してください。Claudeモデル全般に適用できるテクニックについては、プロンプティングのベストプラクティスを参照してください。

既存の Claude Fable 5 向けプロンプトは、変更なしでも Claude Fable 5.1 で良好に動作するはずですが、知っておくべき動作上の違いがいくつかあります。観察された現象に合致するセクションから始めてください。

• どのエフォートレベルで実行すべきか分からない、またはタスクに見合わないほどレイテンシやコストが高い：すべてのエフォートレベルを検討する
• ツール呼び出しの間にテキストがほとんど、またはまったく出力されない：ユーザー向けの進捗更新を求める
• エージェントループで1ターンにつき1回しかツールを呼び出さない：エージェントループで独立したツール呼び出しをバッチ化する
• リクエストが bound to a different conversation で失敗する、またはハーネスがリクエスト間で以前のターンを編集している：会話履歴を追記専用に保つ
• 文章が長く密度が高い：文章の密度
• チャットの返信に、内容が必要とするほどの構造がない：チャットでのフォーマット
• 要約が、引用であることを示さずにソースの文言を再現する：取得したソースの引用
• 作業が終わる前にターンが終了する、またはすでに依頼した作業についてモデルが許可を求める：タスク全体を完了させる
• クライアント側のコンパクション要約で制約、決定事項、正確な詳細が抜け落ちる：コンパクション要約で何を保持すべきかをモデルに伝える
• 依頼していない修正や拡張、またはタスクが求める以上のテストファイルがコミットされる：変更とテストをタスクが求める範囲に留める
• 低エフォートで検索せずに記憶から回答する：低エフォートでの検索のトリガー
• 無害なコーディングリクエストが stop_reason: "refusal" を返す：セーフガードの誤検知を減らす
• 小さな変更のためにファイル全体が書き直される：ファイル全体の書き直しよりも対象を絞った編集を優先する
• xhigh または max エフォートでの長い成果物に時間がかかる、または max_tokens に達する：xhigh および max エフォートで長い出力のための余地を残す
• サブエージェントの実行中にリードエージェントがアイドル状態になる：サブエージェントの実行中もリードエージェントに作業を続けさせる
• チャートや密度の高い画像に関する回答で詳細が見落とされる：ビジョン作業にクロップとズームのツールを与える

すべてのエフォートレベルを検討する

デフォルトの「effort」（エフォート）レベルである high から始め、その後、他のレベル（low、medium、xhigh、max）を独自の評価でテストしてください。エフォートは、Claude Fable 5.1 において知能、レイテンシ、コストのトレードオフを調整するための主要な制御手段です。Claude Fable 5 ですでにスイープを実行済みであっても、再度実行してください。エフォートレベルの名前は、モデル間で同じ思考量に対応しているわけではありません。

Claude Fable 5 に対する Claude Fable 5.1 の能力向上はすべてのエフォートレベルで現れ、高い設定で最も大きくなります。medium では、結果はより低いコストで Claude Fable 5 とほぼ同等になるため、評価で品質が維持されることが示される場合は medium または low に下げてください。low では、Claude Fable 5.1 はタスクあたりのコストで Claude Opus や Claude Sonnet モデルと競合できることが多く、しかもスコアは高くなります。そのため、より小さなモデルをより高いエフォートレベルで実行しようとしている場面では、必ず比較対象に含めてください。

エフォート固有の2つの動作については、それぞれ独自のセクションがあります。low では、Claude Fable 5.1 は検索・取得ツールを呼び出す頻度が低くなります（低エフォートでの検索のトリガーを参照）。また、xhigh と max では、長い成果物を書く前により長く思考することがあります（xhigh および max エフォートで長い出力のための余地を残すを参照）。

ユーザー向けの進捗更新を求める

Claude Fable 5.1 のデフォルトの動作では、長いツール呼び出しターンの間に書かれるユーザー向けの更新が Claude Fable 5 よりも少なくなります。これはエフォートが高いほど、またツールチェーンが長いほど顕著になります。ユーザーからは、エージェントが数分間沈黙したり、最終メッセージがタスク全体ではなく最後のステップだけを扱っているように見えます。

まず、クライアントがそもそも進捗更新を受信しているかを確認してください。ツール呼び出しの間にモデルが書く短いメモ（直前に見つけたことや次に行うこと）は、進捗更新の thinking ブロックとして返されますが、これらのブロックはデフォルトの thinking.display である "omitted" では空になります。display: "updates"（ベータ、thinking-display-updates-2026-08-18 ヘッダー）を設定して空でない各 thinking ブロックをステータス行としてレンダリングするか、"summarized" を設定して要約された推論とともに受信してください。これらをリクエストしていない場合、モデルの更新が単にユーザーに届いていないだけかもしれません。

次に、ナレーションを抑制する指示がプロンプトに含まれていないか点検してください。以前の一部のモデルは作業中に熱心に更新を出していたため、「すべての発見事項は最終応答まで保留すること」のようなシステムプロンプトの行が書かれることがありました。何かを追加する前に、そのような行を削除してください。

それでもさらに多くの更新が必要な場合、たとえばペアプログラミングやその他のヒューマンインザループの作業では、モデルからユーザー向けテキストがいつ欲しいのか、各更新に何を含めるべきかを示す短いシステムプロンプトの行を追加してください。

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own — what you found, what you did, and what's next — so a reader who only sees the last message has the full picture.

プロダクトがツール出力を折りたたんだり非表示にしたりする場合は、そのことをモデルに伝えてください。そうしないと、UIが決して表示しない出力をユーザーに「見せる」ためにコマンドを実行することがあります。このメモはターンスコープのシステムメッセージ（clear_at: "next_user_message"、ベータ）で渡してください。

Only you see that command's output — the user's terminal shows at most a few lines of it. If the user needs to read any of it, put it in your reply.

エージェントループで独立したツール呼び出しをバッチ化する

Claude Fable 5.1 は通常、期待どおりに並列ツール呼び出しを発行します。リクエストが取得すべき複数の対象を挙げている場合、それらの呼び出しを並列に発行します。例外は、次の独立した呼び出しが明示的に要求されるのではなくタスクから暗示されるコーディングループやコンピュータ使用ループ（カスタムコーディングエージェント、bashとエディタのハーネス、コンピュータ使用）です。そこでは、1ターンにつき1つずつ発行することがあります。これは回答の品質には影響しませんが、余分なターンごとにトークン、ラウンドトリップ、実時間のコストがかかります。現在のリクエストの末尾に一文のナッジを加えることで対処できます。

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

ツール結果を送り返すたびに、そのユーザーメッセージの後にターンスコープのシステムメッセージとして追記してください。つまり、messages 内の role: "system" エントリに clear_at: "next_user_message" を付けたものです。後続のユーザーメッセージが存在するようになると、APIは以前のコピーをクリアするため、モデルは最新のものだけを読みます。ターンスコープのシステムメッセージはベータ版であり、ベータヘッダー mid-conversation-system-clear-at-2026-08-21 が必要です。ベータを使用しない場合は、代わりに同じユーザーメッセージ内の tool_result ブロックの後のテキストブロックにこの文を配置してください。

毎ターン新しいコピーを追記し、以前のコピーはバイト単位でそのまま残してください。それらは配列内に残りますが、クリアされた後はモデルには見えず、入力トークンのコストもかかりません。それらを削除したり書き換えたりすることは以前のターンへの編集にあたります。その時点からプロンプトキャッシングのキャッシュが再開始され、それ以降の thinking ブロックが無効になります（会話履歴を追記専用に保つを参照）。

次のループはこの配置を示しています。各アシスタントターンは返されたとおりに正確に戻され、各ユーザーターンはツール結果のみを含み、その後にナッジの新しいターンスコープのコピーが続きます。

import anthropic
from anthropic.types.beta import (
    BetaMessageParam,
    BetaToolParam,
    BetaToolResultBlockParam,
)

client = anthropic.Anthropic()

BATCH_NUDGE = (
    "First privately list what you need next; then request every item "
    "that doesn't depend on another's result in this one response."
)
# In-memory files stand in for a working directory so the sample runs anywhere.
FILES = {
    "pyproject.toml": """\
[project]
name = "demo"
version = "0.1.0"
description = "Demo project for the batching example"
""",
    "README.md": """\
# demo

A small demo project. Run `demo --help` for usage.
""",
}
tools: list[BetaToolParam] = [
    {
        "name": "read_file",
        "description": "Read a UTF-8 text file from the working directory.",
        "input_schema": {
            "type": "object",
            "properties": {"path": {"type": "string"}},
            "required": ["path"],
        },
    }
]
messages: list[BetaMessageParam] = [
    {"role": "user", "content": "Summarize pyproject.toml and README.md."}
]

while True:
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        betas=["mid-conversation-system-clear-at-2026-08-21"],
        tools=tools,
        messages=messages,
    )
    # Append the assistant turn exactly as returned, thinking blocks included.
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break
    tool_results: list[BetaToolResultBlockParam] = []
    for block in response.content:
        if block.type == "tool_use":
            raw_path = block.input.get("path")
            path = raw_path if isinstance(raw_path, str) else ""
            if path in FILES:
                tool_results.append(
                    {
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": FILES[path],
                    }
                )
            else:
                tool_results.append(
                    {
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": f"File not found: {path}",
                        "is_error": True,
                    }
                )
    # Send the tool results as the user turn, then a fresh copy of the nudge as a
    # turn-scoped system message. Leave earlier copies in place: the API clears them,
    # so the model sees only the newest one.
    messages.append({"role": "user", "content": tool_results})
    messages.append(
        {"role": "system", "content": BATCH_NUDGE, "clear_at": "next_user_message"}
    )

print(next((block.text for block in response.content if block.type == "text"), ""))

会話履歴を追記専用に保つ

各アシスタントターンは、thinking ブロックを含め、APIが返したとおりに正確に履歴へ追記し、リクエスト間で以前のターンを編集しないでください。2026年8月31日以降に作成された新規アカウントでは、Claude Fable 5.1 の thinking ブロックはそれを生成した会話そのものの中でのみ有効です。プレフィックス（システムプロンプト、ツールリスト、または以前のメッセージのいずれか）が変更された後に thinking ブロックを再送するリクエストは 400 を返します。または、thinking.block_binding.prefix_mismatch_behavior: "drop_block"（ベータ、thinking-binding-controls-2026-08-01 ヘッダー）を設定している場合は、影響を受けるブロックが削除されます。将来のモデルではすべてのアカウントに対してこのチェックが適用される見込みのため、現時点で自分のアカウントに適用されていなくても、今からこのパターンを採用してください。

このチェックに引っかかる履歴編集は、プロンプトキャッシングのキャッシュを再開始させるものと同じです。ターンごとのリマインダーの挿入と削除、古いターンのその場での要約、セッション途中でのシステムプロンプトの変更などです。ターンごとのリマインダーはターンスコープのシステムメッセージとして送信し、指示やツールの変更は system や tools を書き換えるのではなく会話途中のシステムメッセージで行い、トリミングはサーバー側のコンパクションまたはコンテキスト編集に任せてください。クライアント側でコンパクションを行う場合、最も単純な形は、履歴全体を1つの要約メッセージと新しいユーザーターンに置き換え、それ以外は何も再送しないことです。thinking ブロックは引き継がれないため何も失敗せず、モデルはコンパクションされた会話について新たに思考します（クライアント側でのカスタムコンパクションを参照）。キャッシュ読み取りが安くなったため（価格を参照）、コスト削減のために早めにコンパクションすることは、Claude Fable 5.1 ではもはや適切なコストと知能のトレードオフではない可能性があります。より遅いコンパクションポイントを試してみてください。

ハーネスがすでに行っている編集を見つけるには、統合が影響を受けるかどうかを判断する方法で説明されているように、prefix_mismatch_behavior: "drop_block" を設定してセッションを実行し input_transformations をログに記録するか、通常の数ターンにわたって送信される正確なリクエストをキャプチャし、連続するリクエストが追記されたターンまでバイト単位で同一であることを確認してください。

文章の密度

Claude Fable 5.1 の文章は、以前のClaudeモデルから全般的に一段向上しており、定型句が少なく、説明のない専門用語も減っています。ただし場合によっては、その文章は Claude Fable 5 よりも密度が高くなります。文が長くなり、段落の区切りが少なくなります。アンチパターンである「mannered prose」（気取った文章）を定義する指示が役立ちます。ユーザーメッセージ（推奨）またはシステムプロンプトに追加してください。

Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying," the mannered writer produces "a dial worth turning." Instead of "this point still matters," they write "this point earns its keep." The phrases exist to display the writer, not to convey the idea, and readers can tell. That is why mannered prose irritates: it makes the reader work harder so the writer can perform. It is also imprecise. Metaphors drag in connotations the writer did not choose and cannot control. The fix is to say what you mean. When a literal phrase is available, use it.

短いバージョンでも効果がある傾向があります。

Please remove all mannered prose.

チャットでのフォーマット

以前のモデルはチャットで箇条書きや太字を使いすぎており、多くのプロンプトにはそれを抑えるために書かれたフォーマット抑制ルールが含まれています。Claude Fable 5.1 は逆の傾向があります。太字の使用が少なく、見出し、リスト、引用符を使おうとする可能性も低くなっています。プロンプトにフォーマット抑制の文言が含まれている場合は、それを削除するか、次のように特定のフォーマットがいつ適切かを示すルールに置き換えてください。

Use lists and bullet points when asked to, or when the content is multifaceted enough that they help with clarity. If the person explicitly requests minimal formatting, always format your responses without bullet points, headers, lists, or bold emphasis, as requested. In conversational, personal, or emotional exchanges, keep to plain prose.

取得したソースの引用

ドキュメントを要約する際、Claude Fable 5.1 は Claude Fable 5 よりも、引用であることを示さずにソーステキストの一節を再現する可能性が高くなっています。これに対処するには、正しい応答の完全な例を1つシステムプロンプトに追加してください。ユーザーのリクエスト、応答、そしてその応答がなぜ正しいのかを説明する一文です。

<example>
<user>look up how the Riverton Ledger and the Coast Dispatch each covered the Harbor Bridge closure and compare their reporting</user>
<response>
[web_search: Harbor Bridge closure Riverton Ledger]
[web_search: Harbor Bridge closure Coast Dispatch]
Both outlets agree on the basics: the bridge closed on March 3 after inspectors found cracked welds, and the state expects repairs to take about eight months. Where they differ is emphasis. The Ledger treats it as a local-economy story. The Dispatch frames it as a funding failure; its editorial calls the closure "entirely foreseeable." Read together, the Ledger explains who is affected now and the Dispatch explains how it came to this — neither account alone gives the whole picture.
</response>
<rationale>CORRECT: The response is organized around where the two outlets agree and differ, not as a walk through either article. Each outlet's reporting is conveyed in one or two sentences of the assistant's own indirect speech. One short marked phrase from one source; every other claim is reworded. The response is still specific and complete.</rationale>
</example>

2つの [web_search: ...] の行は独自のツール名に置き換えてください。そうすることで、モデルはそれらを出力すべきリテラルテキストではなく、テンプレート化されたツール出力として読み取ります。

タスク全体を完了させる

Claude Fable 5.1 は、特に目標が明確な場合、方法論についてあまり指示がなくても非常に長いタスクを実行できます。ただし、複雑な非同期ワークロードでは、作業が終わる前にターンを終了しないようナッジしてください。ナッジがないと、モデルは次に行うことを実行する代わりに説明したり（「次に、…します」）、元のリクエストですでにカバーされているステップについて許可を求めて停止したり（「これを適用しましょうか？」）することがあります。ユーザーは「続けて」や「進めて」と返信しなければならず、これはペアプログラミングやその他のヒューマンインザループの作業には適していますが、モデルの長期的なタスク遂行能力を十分に活用できません。

2つのシステムプロンプトへの追加を組み合わせることで、これを軽減できます。両方を適用してください。プロンプトの長さを制限する必要がある場合は、効果の大部分を維持できる1つ目だけを使用してください。1つ目は、すでに依頼された作業について質問しないこと、そして自ら述べた次のステップを実行することをモデルに伝えます。

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to…?' or 'Shall I…?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.

Exception: when the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one.

Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ('I'll…', 'let me know when…'), do that work now with tool calls. That includes retrying after errors and gathering missing information yourself. Do not stop because the context or session is long. End your turn only when the task is complete or you are blocked on input only the user can provide.

Before running a command that changes system state (such as restarts, deletes, or config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.

ユーザーが見ていないことをモデルに伝える冒頭の文が、効果の多くを担っています。書かれているとおりに保持してください。プロダクトで特定の確認のためにモデルを停止させる必要がある場合は、その後にそれらを列挙する文を追加してください。このブロックは、曖昧なリクエストについてモデルが質問する可能性も下げることがあるため、そのトレードオフを独自のタスクで確認してください。

2つ目は、ユーザーのリクエストを成果物のスコープとして定義します。

# Delivering work
The user's request — or the plan they approved — sets the scope, and the scope is the deliverable: don't quietly narrow, widen, or swap it. Read ambiguity the way a careful colleague would: make routine judgment calls yourself, and check in only when different readings would lead to materially different work. If you see a real problem with the task as specified, say so in a sentence or two and keep building under stated assumptions; if the user hears the concern and reaffirms, that is their decision, so deliver the full request.

If a question comes up partway, first do everything that doesn't depend on the answer; then state the assumption you made, or — when going ahead on a wrong guess would be unsafe or would make the work useless — put the question at the end of a turn that also delivers that progress. If one part turns out to be blocked, complete every other part in full and say exactly what you left out and why — the whole task is the deliverable, and scaling it down is the user's call, not yours. A step you have decided on is something to run, not to announce: describing the next step and ending the turn leaves it undone until the user replies.

Keep changes to what the request needs. Something else you notice worth doing — cleanup or documentation the task didn't call for, a change to a file the task didn't require — is a suggestion to make at the end, not a change to make; actions clearly beyond what the ask implies, and risky or destructive ones, still need the user's go-ahead.

コンパクション要約で何を保持すべきかをモデルに伝える

Claude Fable 5.1 は、長い会話がコンパクションされる際に要約が何を保持しなければならないかを明示的に伝えられると、よく応答します。サーバー側のコンパクションはすでにこれを行っています。クライアント側でコンパクションを行う場合は、次の要約指示を使用してください。

Summarize the transcript inside <summary></summary> tags. Include relevant information in the summary such that this conversation will be continued by a new context window without needing to redo work or be reprovided with relevant constraints or context. Be sure to preserve: (1) any difficulties or problems that came up, and how they were handled or resolved; (2) any possibilities, options, or approaches that were raised, tried, or set aside, and why; (3) anything that was asked for, decided, agreed, ruled out, or established as a preference, constraint, or boundary — stated exactly; (4) exactly where things stand now — what has been covered, settled, or completed so far; (5) anything still open, unresolved, promised, or expected to happen next; (6) specific details that would be hard to reconstruct — names, numbers, dates, exact wording, links or references — kept exactly. Be complete on these even at the cost of length; keep everything else concise. Weight the two voices differently: keep what the user said, asked for, shared, or established carefully and close to their own words; your own explanations and reasoning can be condensed much further, to what they concluded or produced — as long as nothing in the six items above is dropped.

変更とテストをタスクが求める範囲に留める

オープンエンドな機能の実装を依頼されると、Claude Fable 5.1 は依頼されたものを提供し、時にはそれ以上のことを行います。近くのコードを修正したり、タスクで言及されていない動作を拡張したり、変更に見合う以上のテストファイルをコミットしたりすることがあります。何を除外すべきかについての明示的な指示にはよく応答します。次の指示を使用すると、依頼していない追加やコミットされるテストコードが大幅に減少し、タスクの成功率に測定可能な変化はありません。

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Where the task is ambiguous, implement the reading its wording and the surrounding code most directly support, state that assumption in your summary, and don't build for the other readings as well. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files — roughly one focused test per stated behavior — and don't turn scratch checks into additional permanent test files. This is about extras only: implement every behavior the task asks for, completely.

低エフォートでの検索のトリガー

low エフォートでは、Claude Fable 5.1 は Claude Fable 5 よりも検索・取得ツールを呼び出す可能性が低く、記憶から回答する可能性が高くなります。場合によっては、最も簡単な修正は、会話全体ではなく影響を受けるターンのエフォートを上げることです。会話途中でエフォートを変更するを参照してください。

その他の場合には、検証を促すプロンプトのナッジが役立ちます。システムプロンプトで、名前を認識していることはその現在の状態を知っていることと同じではないこと、そしてそのような名前はユーザーが書いたとおりに検索すべきであることを伝えてください。

When a query centers on a name you do not confidently recognize, or recognize from a fast-moving area like AI models and developer tools where the landscape shifts within months, the name itself is the thing to verify: search before answering, and include the name as the user wrote it in at least one query alongside any reformulations. This holds even when you have some background on it — partial background is exactly what makes an out-of-date answer sound authoritative, so familiarity is not a reason to skip the search.

セーフガードの誤検知を減らす

Claude Fable 5.1 の安全性分類器は、Claude Fable 5 のリリース時よりも誤検知が少なく、ソースコード内の脆弱性の発見は許可されています。誤検知は依然として発生し、ブロックされたリクエストは stop_reason: "refusal" を返します（拒否、フォールバック、課金を参照）。次の3つの状況で誤検知が起こりやすくなります。

• コンパイルチェックの言い回し：「このプログラムはエラーなしでコンパイルできますか？」の代わりに、「このプログラムにバグはありますか？」と尋ねてください。
• あまり知られていないプログラミング言語： その言語が何であり、どのように動作するかについてのコンテキストをモデルに与えてください。たとえば、その言語のドキュメントへのアクセスを与えます。
• ツール出力内のBase64： base64エンコードされたデータをモデルのコンテキストに返すツールは誤検知を引き起こす可能性があるため、それらを削除することが推奨される修正です。

ファイル全体の書き直しよりも対象を絞った編集を優先する

Claude Fable 5.1 が小さな変更のためにファイル全体を書き直す場合は、次の指示をシステムプロンプトまたは最初のユーザーメッセージに追記してください。Claude Fable 5.1 は Claude Fable 5 よりも、対象を絞った編集を行うのではなくテキストファイル全体を書き直す可能性が高くなっています。結果として得られるファイルは通常同じですが、ファイルが短いか大部分が変更される場合を除き、書き直しにはより多くの出力トークンと時間がかかります。この指示により、小規模および中規模の変更について Claude Fable 5.1 は Claude Fable 5 と同等の動作に戻ります。

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

xhigh および max エフォートで長い出力のための余地を残す

xhigh、特に max エフォートでは、Claude Fable 5.1 は返信を書き始める前により長く思考することがあります。単一のリクエストで長いドキュメントの全面的な書き直しのような長い成果物を求めると、その成果物の大部分を思考の中で下書きし、その後返信として再度書き出すことがあります。これは待ち時間が長くなり、出力トークンが増えることを意味します。最も簡単なアプローチは、このようなリクエストを推奨される出発点である high で実行し、品質の向上を測定できた場合にのみ xhigh または max に移行することです（すべてのエフォートレベルを検討するを参照）。xhigh または max で実行する場合は、次のようにしてください。

• max_tokens は、期待する返信の長さだけでなく、思考と返信の両方の余地を残すように設定してください。
• ユーザーメッセージの末尾に次のメモを追記してください。これにより、文章やコードのリクエストでの思考が大幅に短くなります。[max_tokens] はリクエストの実際の max_tokens の値（たとえば 64,000）に置き換えてください。

Everything produced in one reply, including any reasoning or drafting it does before the reply, counts toward a single limit of about [max_tokens] tokens. If that limit is reached before the reply is finished, the person receives a cut-off response and has to start over. Composing an entire output or deliverable in full as reasoning and then again as a reply would double the length of the turn without improving the result, so don't do that.

Instead, when the person has asked for a long or effort-intensive deliverable such as a multi-section document, a large table or dataset, or a complete code file, spend extra effort on understanding the request, checking the inputs the answer depends on, settling the structure and other difficult decisions, and otherwise using the reasoning space to reason and the output space to write an output. Usually it is not needed to draft an output multiple times.

サブエージェントの実行中もリードエージェントに作業を続けさせる

コーディングエージェントで Claude Fable 5.1 がサブエージェントに作業を委任できる場合、リードエージェントに各サブエージェントを停止して待つことを強制しないでください。コーディングタスクでは、サブエージェントの実行中にリードが作業を続けられるようにすると、同等の品質、トークン使用量、コストで平均完了時間が短縮されます。これを設定するには、次のようにします。

• サブエージェントを開始するツールが即座に戻るようにします。
• 各サブエージェントの結果は、準備ができたら後続の user メッセージでリードに渡します。
• 結果を待ちたいときに呼び出せる別のツールをリードに与えます。

モデルは依然として待つことを選ぶことがよくあります。時間の節約は、モデルが他の作業を続行する実行から得られます。

ビジョン作業にクロップとズームのツールを与える

Claude Fable 5.1 はそのままでも優れたビジョン機能を備えており、密度の高いチャートのような複雑な視覚入力では、見ているものを反復的に分析、クロップ、視覚的に検証できるときに最高の成果を発揮します。その恩恵を十分に受けるには、生の画像や動画を保持し、基本的な画像処理ライブラリ（PIL や OpenCV など）がプリインストールされたコンテナにアクセスできるエージェントとしてモデルを実行してください。コンテナの実行がオーバーヘッドとして大きすぎる場合は、画像クロップツールだけでも向上の大部分が得られます。画像の選択した領域をクロップして拡大して返すツールがあれば、モデルは特定の詳細をより深く調べることができ、画像トークンによってテスト時の計算量をスケールできます。クロップツールのレシピに動作する定義があります。