How to Prompt Claude Fable 5 Efficiently: A Practical Guide

At $10 per million input tokens and $50 per million output tokens, Claude Fable 5 (model ID claude-fable-5) is the most expensive way in the Claude lineup to send a vague prompt. It is also, prompted well, the model most likely to finish a hard job in one turn instead of five. That combination changes what efficient prompting means. In the launch analysis I covered what Fable 5 is and when it earns its premium; this post is the follow-up for the day you actually point traffic at it. Everything below is runnable: front-loaded briefs, effort sweeps, prompt caching, task budgets, and refusal fallbacks, with the token math to show why each one pays.

Efficiency has a different shape on this model

On earlier Claude generations, efficiency work meant tuning numbers: a temperature here, a thinking budget there, a max_tokens ceiling as an improvised brake. Fable 5 removes all of it. Sampling parameters return a hard 400, manual thinking budgets return a 400, and unlike Opus 4.8 you cannot even send an explicit thinking: {"type": "disabled"}; thinking is simply always on, and the model decides how much each task needs. What remains is exactly two levers: the words in your prompt and output_config.effort. That sounds like less control. In practice it moves the efficiency work to where it always belonged, the quality of the brief you write and one honest measurement of how much depth your task actually requires.

Write the whole brief up front

The single biggest efficiency win costs nothing: put the entire job in the first message. Fable 5 is tuned for long, autonomous turns, and its planning is only as good as the specification it plans against. A drip-fed conversation ("now also add tests", "oh, and keep the API stable") forces the model to re-reason after every correction, and on interactive workloads it reasons hard after each user turn. Five short turns routinely cost more than one complete brief, and produce a worse result. A complete brief has five parts: the context (why this matters), the goal, the constraints, the expected output format, and a checkable definition of done.

# efficient_brief.py
# pip install anthropic
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

BRIEF = """Context: I maintain a Laravel blog whose custom search endpoint
has slowed to ~900ms p95 as the posts table passed 50K rows.

Goal: propose and implement the smallest change that gets p95 under 150ms.

Constraints: MySQL 8 only, no new services, migrations must be reversible,
and the public JSON response shape cannot change.

Deliver: the migration, the changed query code, and one paragraph on the
root cause. Definition of done: EXPLAIN shows no full table scan.
"""

with client.messages.stream(
    model="claude-fable-5",
    max_tokens=32000,                    # stream anything this large
    output_config={"effort": "high"},
    # No thinking parameter: on Fable 5 thinking is always on, and an
    # explicit {"type": "disabled"} is rejected with a 400.
    messages=[{"role": "user", "content": BRIEF}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

final = stream.get_final_message()
print(f"\n[stop: {final.stop_reason}, output: {final.usage.output_tokens}]")

Use the builder below to assemble a brief in that shape for your own task, then paste it straight into the API, Claude Code, or claude.ai. The structure matters more than the wording.

Sweep effort instead of guessing it

output_config.effort shapes everything: how deeply the model thinks, how many tool calls it makes, how verbose the answer is. The default is high, and the ladder runs low, medium, high, xhigh, max. The counterintuitive part is how strong the bottom of the ladder is. Low effort on Fable 5 often exceeds what previous-generation models produced at their maximum settings, so routine extraction, classification, and summarisation frequently belong at low or medium, where responses are faster and dramatically cheaper. Reserve xhigh and max for work where correctness beats cost. Do not guess where your task sits: sweep it once and let the numbers decide.

# effort_sweep.py
# Run one representative prompt at four effort levels and compare.
import time
from anthropic import Anthropic

client = Anthropic()
TASK = open("representative_task.txt").read()  # a real prompt from prod

print(f"{'effort':<8}{'seconds':>9}{'output':>9}  stop")
for effort in ["low", "medium", "high", "xhigh"]:
    t0 = time.monotonic()
    with client.messages.stream(
        model="claude-fable-5",
        max_tokens=64000,
        output_config={"effort": effort},
        messages=[{"role": "user", "content": TASK}],
    ) as stream:
        final = stream.get_final_message()
    took = time.monotonic() - t0
    print(f"{effort:<8}{took:>8.1f}s{final.usage.output_tokens:>9}"
          f"  {final.stop_reason}")

# Judge the four answers (by eye, or with a judge prompt) and keep the
# cheapest effort level that still clears your quality bar.

The output token counts from a sweep translate directly into money. The playground below runs entirely in your browser: plug in your own measurements and see what a day of traffic costs at each effort level, with and without caching.

De-prescribe prompts written for older models

Here is the migration surprise nobody budgets for: your best Opus-era prompts can make Fable 5 worse. Prompts accumulate scaffolding, numbered step lists, "always do X before Y" rules, forced summaries every few actions, because older models needed the guardrails. Fable 5 follows instructions more literally and plans better than the scaffolding you wrote, so prescriptive prompts actively constrain it. Anthropic's own migration guidance is blunt about this: state the goal and the constraints, then A/B the workload with the step-by-step scaffolding removed and keep whichever wins. In my testing the de-prescribed version wins far more often than it loses.

BEFORE (written for an older model, too prescriptive for Fable 5):

  Step 1: Read the ticket. Step 2: List every file that could be involved.
  Step 3: For each file, explain whether it is relevant and why.
  Step 4: Propose exactly three fixes. Step 5: Pick one and implement it.
  Step 6: Summarize what you did in exactly 3 bullet points.

AFTER (goal + constraints, steps left to the model):

  Fix the double-charge described in ticket #4821 (text below).
  Constraints: touch only the billing module, keep the public API stable,
  add a regression test. Deliver a unified diff plus one paragraph on the
  root cause. When you have enough information to act, act; do not
  narrate options you will not pursue.

Cache the prefix and pay a tenth for it

Prompt caching is a prefix match: requests render as tools, then system, then messages, and any byte that changes invalidates everything after it. Structure every high-volume workload so the stable content (system prompt, reference docs, tool definitions) comes first and byte-identical on every call, with the volatile part (the user's actual question) last. Mark the cache boundary with cache_control, and note that on Fable 5 a prefix below 2,048 tokens silently will not cache at all. Cached reads bill at roughly a tenth of the input price; on a $10 per million model serving thousands of requests a day, this is not an optimisation, it is the difference between a viable feature and a dead one.

# cached_prefix.py
from anthropic import Anthropic

client = Anthropic()
PLAYBOOK = open("support_playbook.md").read()  # ~9K tokens, never changes

def answer(ticket: str):
    return client.messages.create(
        model="claude-fable-5",
        max_tokens=2048,
        system=[{
            "type": "text",
            "text": PLAYBOOK,                        # stable prefix first
            "cache_control": {"type": "ephemeral"},  # cache boundary here
        }],
        messages=[{"role": "user", "content": ticket}],  # volatile last
    )

first = answer("Customer says the invoice PDF renders blank.")
again = answer("Customer was charged twice for order #8112.")

for label, r in (("first", first), ("again", again)):
    u = r.usage
    print(f"{label}: wrote={u.cache_creation_input_tokens}"
          f" read={u.cache_read_input_tokens} full_price={u.input_tokens}")

# first: wrote=~9000 read=0     -> pays the 1.25x write premium once
# again: wrote=0 read=~9000     -> reads bill at ~0.1x the input price

Budget agent loops, and expect long turns

Two operational habits round out the efficiency story. First, plan for time: a single Fable 5 request at high effort on a hard task can legitimately run many minutes while it gathers context, builds, and verifies its own work, so stream everything and design your UX around progress rather than a spinner. Second, for agentic loops, use a task budget. Unlike max_tokens, which is a hard cap the model never sees, a task_budget gives the model a live countdown it actively paces itself against, prioritising the work that matters and wrapping up cleanly instead of getting cut off mid-thought.

# task_budget.py
# Beta: the model sees a live token countdown and paces itself.
from anthropic import Anthropic

client = Anthropic()

with client.beta.messages.stream(
    model="claude-fable-5",
    max_tokens=128000,
    betas=["task-budgets-2026-03-13"],
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 60000},  # min 20,000
    },
    tools=tools,  # your agent's tool definitions
    messages=[{"role": "user", "content": AGENT_BRIEF}],
) as stream:
    final = stream.get_final_message()

Opt into refusal fallbacks from day one

Fable 5 runs safety classifiers aimed at research biology and most cybersecurity content, and benign adjacent work, a security-tooling audit, a life-sciences data pipeline, can occasionally trip a false positive. A declined request comes back as a successful HTTP 200 with stop_reason: "refusal" and, pre-output, an empty content array, so code that reads response.content[0] unconditionally will crash on exactly the requests you least expect. The efficient pattern is to opt into server-side fallbacks: name a rescue model in the same call and a decline is transparently re-served by Opus 4.8, with the unbilled decline costing you nothing.

# refusal_fallback.py
from anthropic import Anthropic

client = Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=2048,
    betas=["server-side-fallback-2026-06-01"],
    fallbacks=[{"model": "claude-opus-4-8"}],  # rescue inside the same call
    messages=[{"role": "user", "content":
               "Audit this nginx config for MIME sniffing issues."}],
)

if response.stop_reason == "refusal":
    print("Whole chain declined:", response.stop_details)
else:
    rescued = any(i.type == "fallback_message"
                  for i in (response.usage.iterations or []))
    print(f"served by {response.model}" + (" (fallback)" if rescued else ""))
    print(response.content[0].text)

The efficient way, in one paragraph

Write one complete brief with the reason behind it, sweep effort once and settle on the cheapest level that passes, strip the scaffolding your old prompts accumulated, cache every stable prefix above 2,048 tokens, give agent loops a budget they can see, and opt into fallbacks so refusals degrade instead of failing. None of these steps is difficult, and together they routinely halve the cost of a Fable 5 workload while improving the output. The model took away the knobs; what it gave back is a system where the quality of your writing is the performance tuning.