PrompTessor
Back to Blog
claude fable 5.1claude promptingclaude promptsanthropicprompt engineeringadaptive thinkingeffort levelsai agentscoding promptslong-context promptingxml promptstool use

How to Prompt Claude Fable 5.1: Best Practices, Adaptive Thinking, and Examples

RRizki Murtadha
September 6, 202646 min read

Claude Fable 5.1 is built for work that does not fit neatly into one model call.

Anthropic positions it as its most capable generally available model for ambitious coding and knowledge work, including long-running agents, multi-step research, computer use, document-heavy analysis, and projects that may run for hours.

That changes the most important prompting question.

Instead of asking only, “How should I phrase the request?”, a production prompt often needs to control how Claude should work over time: how much effort to spend, when to search, when to batch tool calls, how to communicate progress, how to preserve conversation state, how far to continue without asking permission, what to verify, what not to change, and when the task is actually complete.

Anthropic's current Fable 5.1-specific prompting guide documents several behaviors worth designing for: a broader effort range, always-on adaptive thinking, fewer progress updates during long tool runs, more variable tool-call batching in agent loops, stricter append-only history requirements for preserved thinking, denser prose in some cases, less default formatting, stronger long-horizon execution, and model-specific considerations for testing, search, file edits, subagents, and vision.

A strong Claude Fable 5.1 prompt does not micromanage every reasoning step. It gives the model a clear deliverable, appropriate effort, explicit action boundaries, reliable context, and a definition of what “finished” means.

This guide turns Anthropic's official recommendations into practical prompt patterns for writing, research, coding, long-context work, tool use, autonomous agents, subagents, and production workflows.

Quick Answer

For complex Claude Fable 5.1 tasks, a useful prompt architecture is:

OBJECTIVE
What complete outcome should Claude deliver?

CONTEXT
What information, files, state, or source material matters?

SCOPE
What is included, and what should remain untouched?

AUTONOMY
What can Claude decide and execute without asking?

TOOLS
When should tools be used, batched, retried, or avoided?

PROGRESS
When should the user receive status updates?

EVIDENCE
What sources are authoritative and how should quotations be handled?

VERIFICATION
What must be checked before completion?

OUTPUT
What should the final deliverable contain?

STOP CONDITION
When is the full task actually done?

Then choose an effort level appropriate to the workload. Anthropic currently recommends starting Fable 5.1 at high, then testing low, medium, xhigh, and max against your own evaluations.

Key Takeaways

  • Claude Fable 5.1 uses always-on adaptive thinking; the primary control for thinking depth is the effort parameter.
  • Current effort levels are low, medium, high, xhigh, and max, with high as the recommended starting point.
  • Do not assume the same effort label produces the same amount of thinking across Claude model generations. Re-run your evals.
  • Fable 5.1 can finish very long tasks with little methodological hand-holding when the goal is clear, but asynchronous workflows benefit from explicit completion and autonomy rules.
  • If the model keeps describing what it will do next instead of doing it, define the request itself as the deliverable and tell it to continue reversible in-scope work.
  • Fable 5.1 produces fewer user-facing updates between tool calls than Fable 5. Ask for progress updates explicitly when the user needs visibility.
  • In long coding and computer-use loops, independent tool calls may need a short batching nudge so they run in parallel rather than one per turn.
  • Conversation history should be treated as append-only when preserved thinking blocks are replayed. Rewriting earlier system prompts, tools, or messages can invalidate those blocks.
  • At low effort, Fable 5.1 may search or retrieve less often and answer from memory more readily. Current-data tasks may need higher effort or an explicit verification rule.
  • Fable 5.1 can write denser prose than Fable 5 and tends to use less formatting. Tune writing density and formatting positively rather than carrying forward aggressive anti-formatting prompts.
  • For document summarization, explicitly distinguish paraphrase from quotation when exact source wording matters.
  • For coding, tell Claude not to fix unrelated issues or create permanent tests beyond the scope the task actually needs.
  • For small file changes, targeted edits can reduce output tokens compared with whole-file rewrites.
  • At xhigh and max, leave enough output room for long deliverables and evaluate whether the quality gain justifies additional thinking.
  • Subagents can reduce time when the lead agent continues independent work instead of idling while delegated work runs.
  • Long-context prompting still benefits from structured source boundaries, XML tags, and placing large documents before the final query.
  • Prompt quality should be judged by behavior on representative tasks, not by how elaborate the prompt looks.

Table of Contents

What Is Claude Fable 5.1?

Claude Fable 5.1 is Anthropic's successor to Claude Fable 5 for long-running agentic coding, knowledge work, and research.

The Claude API model ID is:

claude-fable-5-1

Anthropic's current documentation lists:

  • a 1 million-token context window,
  • up to 128,000 output tokens,
  • always-on adaptive thinking,
  • effort control through low, medium, high, xhigh, and max,
  • long-running agentic coding,
  • multi-step research,
  • document, spreadsheet, and slide work,
  • vision over charts, tables, files, and PDFs,
  • computer use and tool-driven workflows,
  • mid-conversation effort changes in beta,
  • turn-scoped system messages in beta,
  • and progress updates between tool calls in beta.

Anthropic recommends Fable 5.1 for demanding reasoning and long-horizon agentic work. It is available through the Claude API and supported cloud platforms.

Those capabilities make model-specific prompting valuable because the model may stay active across many tool calls, files, state changes, and context updates before producing its final deliverable.

What Changed About Prompting Claude Fable 5.1?

Anthropic says existing Claude Fable 5 prompts should generally continue to work, but Fable 5.1 has behavioral differences that can matter in production.

The most important ones are not superficial style preferences. They affect cost, latency, tool orchestration, long-running completion, context integrity, and how users experience an agent while it works.

Claude Fable 5.1 prompting behaviors infographic showing effort adaptive thinking task completion progress updates tool batching append-only history writing density search verification and scoped coding changes
Fable 5.1 prompting is strongly shaped by effort, long-running execution, tool-loop behavior, preserved thinking, and explicit task boundaries.
BehaviorWhat You May ObservePrompting Response
EffortHigher intelligence, latency, and token use at stronger settingsStart at high, then evaluate all relevant levels
Progress updatesLong tool runs can appear quietAsk for opening, periodic, and closing updates when needed
Tool batchingIndependent reads may occur one turn at a timePrompt batching for calls without dependencies
Long task completionClaude may explain the next step or ask permission mid-taskDefine reversible in-scope work as already authorized
Preserved thinkingEdited history can invalidate thinking blocksKeep history append-only and use supported mid-conversation controls
WritingProse can be dense and chat formatting lighterRequest readable density and useful structure positively
Search at low effortMore answers from memory, fewer retrieval callsRequire verification for current or uncertain entities
Coding scopeNearby fixes and extra tests may expand the changeExplicitly define what not to modify

1. Calibrate Effort Instead of Maximizing It

effort is the primary control for the intelligence, latency, and cost tradeoff on Claude Fable 5.1.

Anthropic currently recommends starting at high, then comparing other levels on your actual tasks:

low
medium
high
xhigh
max

The names are not a universal unit of reasoning. Anthropic specifically recommends re-running effort evaluations when moving from Fable 5 because the same label does not necessarily correspond to the same amount of thinking across model versions.

A practical workflow is:

START: HIGH
    ↓
RUN REPRESENTATIVE EVALS
    ↓
COMPARE MEDIUM / LOW
    ↓
IF QUALITY HOLDS
USE LOWER COST / LATENCY SETTING

FOR HARD CASES
COMPARE XHIGH / MAX
ONLY KEEP THEM IF THE QUALITY GAIN IS MEASURABLE

Anthropic reports that medium on Fable 5.1 can roughly match Fable 5 in many evaluations at lower cost, while low can be competitive with smaller Claude models on cost per task in some workloads.

The key is evaluation, not assumption.

Claude Fable 5.1 effort levels infographic comparing low medium high xhigh and max across intelligence latency cost search behavior and long deliverables
Effort is a workload control. Start with high, then lower or raise it only when evaluation evidence justifies the tradeoff.

Example API Configuration

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    output_config={"effort": "high"},
    messages=[
        {
            "role": "user",
            "content": prompt
        }
    ],
)

Fable 5.1 also supports changing effort mid-conversation in the Claude API beta. That can be useful when one long workflow contains both routine and unusually difficult steps.

2. Design for Always-On Adaptive Thinking

Claude Fable 5.1 uses adaptive thinking as its only thinking mode.

You do not manually allocate a thinking budget with budget_tokens, and you cannot disable thinking. Claude decides whether and how much to think based primarily on the effort setting and the complexity of the current query.

This changes prompt design in two useful ways.

Prefer Goals Over Hand-Written Reasoning Scripts

Anthropic recommends general instructions over prescriptive reasoning sequences. A manually written twenty-step thought process can be less useful than giving Claude the goal, constraints, evidence, and acceptance criteria it actually needs.

Instead of:

First think about A.
Then think about B.
Then reconsider A.
Then generate three hypotheses.
Then challenge each hypothesis.
Then...

prefer:

Determine the root cause of the failure.

Use the available logs, implementation, and test results.
Update your hypothesis when new evidence contradicts it.
Before finishing, verify that the proposed fix explains the observed
failure and does not violate the stated constraints.

Prompt When Thinking Should Be Worth the Latency

For systems where unnecessary thinking is expensive, a behavioral rule can help:

Use deeper reasoning when it will materially improve the result,
especially for multistep diagnosis, planning, or decisions with
important tradeoffs.

For straightforward formatting, retrieval, or transformation tasks,
respond directly.

Use this together with effort configuration rather than trying to control thinking entirely through prose.

3. Tell Claude to Finish the Whole Task

Fable 5.1 is designed for long asynchronous work, but Anthropic notes a practical failure mode: the model may sometimes end a turn after describing what it plans to do next, or ask for permission for work already included in the original request.

For an interactive pair-programming session, that behavior may be useful.

For an unattended agent, it can turn a long-running capability into a sequence of unnecessary “continue” messages.

A production-friendly autonomy block can look like:

<autonomy>
The user's request defines the work that has already been authorized.

Proceed with reversible actions that are necessary to complete that
request without asking for permission again.

Routine implementation decisions are yours to make.

Stop and ask only when:
- the next action is destructive or difficult to reverse
- the request would materially change scope
- required information cannot be discovered or safely inferred
- two plausible interpretations would lead to materially different work

If one part is blocked, complete every independent part that can still
be finished before reporting the blocker.
</autonomy>

<completion>
Do not end the task with a plan for work you can still perform.
If the final paragraph says what you will do next, do that work first.

End only when the requested deliverable is complete or you are blocked
on information or authorization only the user can provide.
</completion>

This is stronger than a generic instruction like “be autonomous” because it defines both the permission boundary and the stopping boundary.

4. Ask for Progress Updates When Users Need Them

Claude Fable 5.1 tends to write fewer user-facing progress notes between tool calls than Fable 5, particularly during long or higher-effort runs.

That can be ideal for an unattended backend agent.

It can feel broken in a human-in-the-loop interface where the user watches a task run for several minutes.

If progress visibility matters, request it explicitly:

<progress_updates>
Before starting a long tool-driven task, briefly state what you are
about to investigate.

During the task, provide a short user-facing update after a meaningful
milestone, discovery, or change of plan. Do not narrate every tool call.

Finish with a standalone recap that tells the user:
- what you found
- what you changed or completed
- what was verified
- anything that remains unresolved
</progress_updates>

Anthropic also exposes progress-update thinking blocks through a beta display option. That is a runtime feature, not something prompt wording alone enables.

The important prompt-design question is whether your interface needs progress text at all.

5. Batch Independent Tool Calls in Agent Loops

Fable 5.1 usually parallelizes clearly independent tool calls, but Anthropic notes that in long coding and computer-use loops it can sometimes issue one independent call per turn when the parallelism is only implied by the task.

That can increase round trips, tokens, and wall-clock time without improving answer quality.

A concise batching rule is enough:

<tool_batching>
Before requesting the next tool results, identify which information
you need next.

Request all items that do not depend on one another in the same turn.

Use sequential calls only when a later call requires data produced by
an earlier call.

Never invent placeholders or guess missing tool arguments merely to
make calls parallel.
</tool_batching>

That last line matters. Parallelism is useful only when dependencies are real and arguments are known.

See Function Calling and Tool Use for a broader tool-policy framework.

6. Keep Long-Running Conversation History Append-Only

This is partly an integration rule, but it has direct implications for prompt architecture.

Fable 5.1 thinking blocks can be bound to the exact conversation prefix that produced them. If an application rewrites earlier messages, tools, or the system prompt while replaying later thinking blocks, those blocks can become invalid.

A safer architecture is:

ORIGINAL SYSTEM PROMPT
        ↓
USER TURN
        ↓
ASSISTANT TURN + THINKING BLOCKS
        ↓
TOOL RESULTS
        ↓
TURN-SCOPED / MID-CONVERSATION INSTRUCTIONS
        ↓
NEXT ASSISTANT TURN

APPEND NEW INFORMATION
DO NOT REWRITE THE PREFIX

For long-lived agents, use supported mid-conversation system messages or tool changes rather than rebuilding the earlier prompt stack.

If you compact conversation history, define what the summary must preserve:

  • constraints and boundaries,
  • decisions already made,
  • failed approaches and why they failed,
  • current state,
  • open tasks,
  • exact identifiers, URLs, numbers, dates, and user requirements that are hard to reconstruct.

This is an example of Context Engineering: the prompt is only one layer of a larger information environment.

Claude Fable 5.1 long-running agent loop infographic showing append-only history adaptive thinking tool batching progress updates compaction preserved constraints verification and task completion
Long-running Fable 5.1 workflows benefit from append-only history, batched independent tools, preserved constraints, and explicit completion behavior.

7. Tune Writing Density and Formatting

Anthropic notes two Fable 5.1 writing tendencies that can appear contradictory:

  • its prose can be denser in some cases, with longer sentences and fewer paragraph breaks,
  • but it also uses less bold, fewer headers, and fewer lists than earlier Claude models.

So prompts designed to suppress excessive formatting in older models can overcorrect Fable 5.1.

Use positive style rules:

<writing_style>
Use direct, literal language.

Prefer short-to-medium sentences when the idea does not require a
long compound sentence.

Use paragraphs for explanation.

Use headings, bullets, and tables when they genuinely improve scanning,
comparison, or sequence.

Do not add formatting merely for decoration, but do not suppress useful
structure when the content is multifaceted.
</writing_style>

For editorial work, you can also define the specific anti-pattern:

Avoid mannered prose: decorative metaphors, clever phrasing, or
performative wording that makes a simple statement less precise.

When a literal phrase communicates the idea accurately, use it.

This is more actionable than “write professionally.”

8. Control Quoting and Source Grounding

Anthropic notes that when summarizing retrieved documents, Fable 5.1 can reproduce source wording without clearly marking it as a quotation more often than Fable 5.

For research, legal, policy, or document-heavy work, define the relationship between source text and the final answer.

<evidence_policy>
Use the supplied and retrieved sources as evidence.

Paraphrase by default.

Use direct quotations only when the exact wording is materially
important, and mark them clearly as quotations.

Do not reproduce long passages when a short paraphrase is sufficient.

Separate:
- verified source facts
- inference
- recommendation

If sources conflict, report the disagreement instead of silently
merging them.
</evidence_policy>

When a specific output pattern is important, Anthropic recommends giving Claude a complete example. This is a good use of Few-Shot Prompting.

9. Keep Changes and Tests Within Scope

Fable 5.1 can be proactive enough to fix nearby problems, extend behavior, or create more permanent test files than the task actually requires.

That can look helpful while creating review noise and regression risk.

A professional coding prompt should define scope positively and negatively:

<scope>
Implement every behavior explicitly required by the task.

Do not fix, refactor, optimize, document, or extend unrelated code
unless the requested behavior cannot work without that change.

If you notice a separate issue, record it under Follow-up Suggestions
instead of changing it.
</scope>

<testing>
Verify the requested behavior thoroughly.

Use scratch scripts or temporary checks when useful.

Add or modify permanent tests only when:
- the task requests them, or
- the repository already keeps tests for this class of behavior.

Keep test changes proportional to the requested behavior and consistent
with neighboring test files.
</testing>

This does not tell Claude to test less. It distinguishes verification work from permanent repository changes.

At low effort, Anthropic reports that Fable 5.1 may call search and retrieval tools less often and answer from memory more readily.

For stable knowledge, that may be fine.

For fast-moving entities such as AI models, software versions, prices, APIs, company leadership, or recent events, it can create authoritative-sounding stale answers.

Add a verification rule when freshness matters:

<freshness_policy>
When the task depends on a current entity, product, version, price,
policy, release, or fast-moving technical fact, verify it with the
available current source or search tool before relying on memory.

Recognizing a name is not proof that your remembered information is
current.

If current verification is unavailable, label the limitation.
</freshness_policy>

You can also raise effort only for turns where fresh research matters.

11. Prefer Targeted Edits for Small Changes

Anthropic notes that Fable 5.1 can rewrite an entire file for a small edit more often than Fable 5. The end result may be correct, but the rewrite can consume more output tokens, take longer, and make review harder.

A simple editing policy:

<editing_policy>
When a small or medium change can be implemented without changing the
result, prefer the smallest targeted edit over rewriting the entire file.

Rewrite the whole file only when most of it genuinely needs to change
or when a targeted edit would make the implementation less reliable.
</editing_policy>

This is especially useful in coding agents where diffs are reviewed by humans or downstream automation.

12. Leave Room for Long Outputs at High Effort

At xhigh and especially max, Fable 5.1 can think for longer before writing a large deliverable.

That creates a practical token-budget problem: one request may use substantial capacity for reasoning and then need a large final answer as well.

If the deliverable itself is long, first ask whether the higher effort level is actually improving quality.

Anthropic recommends starting at high and only moving higher when evaluation demonstrates a gain.

If you do use stronger effort for a long deliverable, guide the model to spend its reasoning on the difficult decisions instead of drafting the entire output twice:

Use additional effort to understand the inputs, resolve difficult
decisions, verify dependencies, and settle the structure.

Do not draft the complete deliverable in reasoning and then reproduce
the same deliverable again in the final response.

Reserve the final output budget for the deliverable the user actually
needs.

13. Let the Lead Agent Keep Working

Anthropic recommends not forcing the lead Fable 5.1 agent to idle whenever a subagent is running.

When delegated work is independent, the lead can continue useful work and consume subagent results as they arrive.

A useful orchestration instruction:

<delegation>
Delegate work only when the workstream is materially independent or
benefits from specialized parallel investigation.

After starting a subagent, continue any primary-agent work that does
not depend on that subagent's result.

Wait only when the next meaningful step genuinely requires the pending
result.

The lead agent owns:
- conflict resolution
- integration
- final verification
- the final deliverable
</delegation>

This prevents both extremes: never delegating and delegating everything.

For broader agent instruction design, see AI Agent Prompts.

14. Give Complex Vision Tasks Crop-and-Zoom Tools

Fable 5.1 improves vision over dense charts, filings, tables, and visual documents.

Anthropic specifically recommends giving the model a way to crop and zoom complex images when detailed visual inspection matters.

The prompt should treat that capability as part of the analysis workflow:

<vision_policy>
Inspect the full visual first to understand its structure.

When a chart, table, label, annotation, or region is too dense to read
reliably at full resolution, crop or zoom that region before making a
specific claim about it.

Separate:
- directly visible evidence
- interpretation
- uncertainty

Do not infer unreadable values.
</vision_policy>

This applies well to financial filings, architectural drawings, UI screenshots, charts, and visual QA for coding tasks.

15. Use XML and Long-Context Structure Deliberately

Anthropic continues to recommend XML tags for complex prompts that mix instructions, context, examples, and variable inputs.

Claude Fable 5.1 also has a one-million-token context window, so source organization matters.

A practical long-context structure is:

<documents>
  <document index="1">
    <source>current_policy.pdf</source>
    <document_content>
      ...
    </document_content>
  </document>

  <document index="2">
    <source>previous_policy.pdf</source>
    <document_content>
      ...
    </document_content>
  </document>
</documents>

<task>
Compare the two policies and identify material changes.
</task>

<evidence_rules>
Use the documents above as the authoritative evidence.
Mark direct quotations clearly.
If the documents conflict internally, report the conflict.
</evidence_rules>

<output>
Return a change table, practical implications, and unresolved issues.
</output>

Anthropic's general prompting guidance recommends placing long documents near the top and the query after them for large multi-document tasks.

See Long-Context Prompting.

A Practical Claude Fable 5.1 Prompt Framework

You do not need every block for every task.

But for a long-running agentic workflow, this structure is a useful starting point:

<objective>
The complete outcome to deliver.
</objective>

<context>
Relevant facts, files, system state, and background.
</context>

<source_authority>
Which evidence is authoritative and how conflicts are resolved.
</source_authority>

<scope>
What is included, excluded, and allowed to change.
</scope>

<autonomy>
What Claude can decide and execute without asking.
</autonomy>

<tool_policy>
When tools are used, batched, retried, or avoided.
</tool_policy>

<progress_updates>
What the user should see during long work.
</progress_updates>

<delegation>
When subagents are appropriate and who owns integration.
</delegation>

<verification>
What must be checked before completion.
</verification>

<output>
Required deliverable and communication style.
</output>

<stop_condition>
What proves the task is complete.
</stop_condition>

Use the smallest set of blocks that correspond to real requirements or failure modes.

Practical Claude Fable 5.1 Prompt Examples

These examples are intentionally different from one another. The goal is to show how Fable 5.1-specific prompting principles adapt to real professional workflows.

Example 1: Professional Technical Writing

<objective>
Write an educational guide explaining idempotency in distributed systems
to backend developers who understand HTTP APIs but have not designed
payment or workflow retry systems.
</objective>

<coverage>
Explain:
- what idempotency means operationally
- idempotency keys
- retry behavior
- duplicate side effects
- storage and expiration
- race conditions
- failure recovery
- common implementation mistakes
</coverage>

<factual_policy>
Do not invent statistics, provider behavior, or API guarantees.
When an implementation detail depends on a specific provider,
label it as provider-specific.
</factual_policy>

<writing_style>
Use direct technical prose.
Avoid mannered prose and decorative metaphors.
Use paragraphs for explanation and code blocks for implementation patterns.
Use lists only when the items are genuinely parallel or sequential.
Keep sentences readable rather than dense.
</writing_style>

<success_criteria>
A backend developer should finish able to explain why retries create
duplicate-action risk and identify the main components of a robust
idempotency design.
</success_criteria>

Example 2: Current Market Research

<objective>
Identify meaningful product gaps in the current AI developer-tool market.
</objective>

<source_authority>
1. current first-party documentation
2. current first-party pricing and release notes
3. reputable current secondary reporting
4. community discussions as qualitative evidence only
</source_authority>

<freshness_policy>
Search current sources for model names, pricing, product capabilities,
and recently changed features before relying on memory.
</freshness_policy>

<evidence_policy>
Paraphrase by default.
Mark direct quotations.
Separate verified facts, inference, and recommendation.
Do not present community claims as verified product capabilities.
</evidence_policy>

<output>
Return:
1. executive summary
2. evidence table
3. repeated user pain points
4. underserved workflows
5. three opportunities
6. major risks
7. one recommended direction
8. unresolved evidence
</output>

Example 3: Long-Running Coding Agent

<objective>
Diagnose and fix the intermittent duplicate-payment capture bug.
Deliver a verified implementation, not only an analysis.
</objective>

<scope>
Inspect the payment retry path, idempotency state, provider response
handling, transaction persistence, and relevant tests.

Do not refactor unrelated billing code.
If you discover a separate bug, report it as a follow-up instead of
fixing it unless the requested fix cannot work without that change.
</scope>

<autonomy>
Proceed through reversible investigation and implementation steps without
asking for permission again.

Stop only for destructive actions, a genuine scope change, or information
that cannot be discovered from the repository and available tools.

Do not end the turn with a plan for work you can still execute.
</autonomy>

<tool_batching>
Read independent files, logs, or test artifacts in parallel.
Use sequential calls only when one result is required to construct the
next call.
</tool_batching>

<testing>
Reproduce or explain the failure condition.
Verify that retries are idempotent.
Run the smallest relevant existing test set that covers the affected path.
Add permanent tests only where consistent with the repository's existing
testing pattern.
</testing>

<output>
Summarize:
- root cause
- files changed
- implementation
- verification performed
- unresolved risk
- unrelated issues noticed but not changed
</output>

Example 4: Long-Context Contract Review

<documents>
  <document index="1">
    <source>current_contract.pdf</source>
    <document_content>...</document_content>
  </document>

  <document index="2">
    <source>prior_contract.pdf</source>
    <document_content>...</document_content>
  </document>
</documents>

<task>
Identify material changes affecting payment, renewal, termination,
liability, data handling, service levels, and audit rights.
</task>

<evidence_policy>
The contract text is the authoritative source.
Paraphrase by default.
Use short marked quotations when exact wording materially affects
the comparison.
Do not infer a legal conclusion beyond what the text supports.
</evidence_policy>

<output>
For each material change provide:
- prior position
- current position
- evidence location
- practical significance
- ambiguity requiring legal review

Add a final section for important clauses that did not change.
</output>

Example 5: Tool-Using Customer Operations Agent

<objective>
Resolve the customer's subscription-access issue completely.
</objective>

<tool_policy>
Retrieve the customer and subscription record before making account-specific
claims.

Use internal policy search for entitlement and refund rules.

Never invent customer IDs, subscription state, payment status, dates,
or authorization.

Batch independent read-only lookups.
</tool_policy>

<risk>
Read-only investigation and drafting are allowed.

Plan changes, refunds, cancellations, external sends, and other account
writes require the authorization defined by the application.
</risk>

<recovery>
If a tool fails, determine whether the failure is transient, invalid input,
or permission-related.

Retry only when safe.

Before retrying a write, verify whether the action already succeeded.

Never tell the customer an action succeeded when the state is unknown.
</recovery>

<completion>
Do not stop after identifying the likely fix if the authorized tools can
complete it.

Stop when the issue is resolved or the next required action genuinely
needs user authorization or unavailable information.
</completion>

Example 6: Subagent Repository Investigation

<objective>
Determine why the application's startup time regressed after the last
three releases and recommend the smallest corrective change.
</objective>

<delegation>
Delegate independent investigations when useful:
- dependency changes
- database initialization
- frontend bundle startup
- telemetry initialization

Do not create subagents for tiny or tightly coupled work.

After delegating, continue primary-agent work that does not depend on
pending results.

The lead agent owns conflict resolution and the final diagnosis.
</delegation>

<evidence>
Distinguish measured startup cost from hypotheses.
If two measurements disagree, investigate why before averaging them.
</evidence>

<output>
Return:
- root-cause ranking
- supporting measurements
- rejected hypotheses
- recommended fix
- expected impact
- verification plan
</output>

Example 7: Dense Chart and PDF Analysis

<objective>
Explain the material changes in operating margin and cash flow shown in
the supplied quarterly filing and charts.
</objective>

<vision_policy>
Inspect the full pages first.

Crop and enlarge dense chart, table, or annotation regions before making
a specific claim about values that are difficult to read at full scale.

Do not infer unreadable values.
</vision_policy>

<evidence_policy>
Separate:
- values directly visible in the filing
- management explanation
- your inference

Use short quotations only when exact wording matters.
</evidence_policy>

<output>
Provide:
1. major changes
2. evidence table
3. likely drivers
4. contradictions or uncertainty
5. questions for further diligence
</output>

Example 8: Business Decision With Effort-Aware Execution

<objective>
Recommend whether the company should migrate its primary analytics
pipeline from Vendor A to Vendor B.
</objective>

<decision_criteria>
Evaluate:
- reliability
- latency
- implementation effort
- migration risk
- observability
- data governance
- vendor lock-in
- three-year cost
</decision_criteria>

<source_authority>
Use current contracts, internal usage data, incident records, and current
official vendor documentation as the primary evidence.
</source_authority>

<sensitivity>
Identify assumptions capable of reversing the recommendation.

For each material assumption:
- state the current value
- show a plausible alternative
- explain whether the decision changes
</sensitivity>

<output>
Recommendation, evidence, strongest alternative, migration risks,
sensitivity analysis, confidence, and the next data that would most
improve confidence.
</output>

Run the evaluation at high first, then test whether medium preserves the decision quality at lower cost or latency. Move to xhigh or max only if the extra reasoning measurably improves the recommendation.

A Production-Grade Claude Fable 5.1 Prompt

The following example combines the most important Fable 5.1-specific behaviors in one long-running coding and research workflow.

It is intentionally complete. Do not copy every block into every prompt. Remove anything that does not correspond to a real requirement or failure mode.

Example: Autonomous Repository Modernization Agent

<objective>
Modernize the repository's authentication subsystem to the new session API.

The deliverable is a working, verified implementation across all affected
application paths, plus a concise final report.
</objective>

<context>
The repository, current tests, migration notes, issue history, and official
session API documentation are available through tools.
</context>

<source_authority>
For current external API behavior:
1. official current documentation
2. official release notes
3. repository integration code
4. issue history and comments

For current repository behavior:
1. executable code and tests
2. current configuration
3. repository documentation
4. historical issue discussion

If sources conflict, prefer current executable behavior and current official
documentation, then report the conflict when it affects the implementation.
</source_authority>

<scope>
Migrate:
- login
- logout
- session restoration
- protected-route checks
- expired-session handling
- relevant authentication tests

Preserve:
- the current identity provider
- public user-facing authentication flows
- unrelated authorization logic

Do not clean up, refactor, document, or optimize unrelated code.
Report unrelated problems as follow-ups.
</scope>

<autonomy>
You are operating autonomously.

The user has already authorized reversible repository investigation,
implementation, and local verification required by this migration.

Make routine engineering decisions yourself.

Do not ask permission again for work already implied by the migration.

Stop and ask only before:
- destructive external actions
- production deployment
- a material architecture change outside authentication
- a decision where two plausible interpretations produce substantially
  different user behavior

If one part becomes blocked, finish every independent part first.
</autonomy>

<thinking_and_effort>
Use deeper reasoning for root-cause analysis, architecture decisions,
conflicting evidence, and migration risk.

For straightforward edits, formatting, and mechanical transformations,
proceed directly.

Do not spend effort repeatedly reconsidering a decision unless new evidence
contradicts it.
</thinking_and_effort>

<tool_policy>
Inspect the implementation before editing it.

Batch independent reads, searches, and test-artifact retrieval.

Use sequential tool calls only when a later argument depends on an earlier
result.

Never guess file paths, IDs, configuration values, or tool arguments when
they can be discovered.

When a tool fails:
- classify the failure
- retry only when appropriate
- change approach when the evidence supports doing so
- do not claim success when the result is unknown
</tool_policy>

<conversation_state>
Treat the working conversation as append-only.

Preserve:
- user requirements
- migration decisions
- failed approaches and why they failed
- changed files
- test results
- unresolved blockers
- exact identifiers and configuration values

If the context is compacted, these items must survive the summary.
</conversation_state>

<progress_updates>
Before beginning, give one short line describing the first investigation.

During long work, update the user only after a meaningful milestone,
discovery, blocker, or change of plan.

Do not narrate every command or file read.

The final message must stand alone for a reader who did not see the
intermediate updates.
</progress_updates>

<editing_policy>
Prefer targeted edits for small and medium changes.

Rewrite an entire file only when most of the file genuinely needs to change
or a surgical edit would make the result less reliable.
</editing_policy>

<testing>
Verify every requested authentication behavior.

Run the relevant existing tests and checks.

Use temporary scratch checks freely, but do not preserve them as permanent
test files unless the repository normally keeps that class of test.

Add or modify permanent tests in proportion to the changed behavior.

Do not expand the task into unrelated test cleanup.
</testing>

<verification>
Before finishing:
- confirm login works
- confirm logout works
- confirm protected-route refresh works
- confirm session restoration works
- confirm expired sessions fail safely
- confirm the old API is no longer used in the migrated path
- run relevant type and test checks
- review the changed diff for unrelated modifications
- identify anything that could not be verified
</verification>

<delegation>
Use subagents only for materially independent investigation or verification.

Good candidates:
- tracing current session usage
- reviewing tests
- auditing documentation differences
- checking separate application surfaces

After launching a subagent, keep working on independent primary-agent tasks.

Do not wait unless the next meaningful step genuinely requires the pending
result.

The lead agent owns integration and final verification.
</delegation>

<completion>
The task is not complete when the plan is written or the likely fix is known.

If you state a next implementation or verification step that you can still
perform, perform it before ending the turn.

Finish only when:
- the requested migration is implemented
- verification is complete to the defined scope
- blockers requiring user input are explicitly identified
- the final report is ready
</completion>

<output>
Return:
1. root cause / migration summary
2. implementation decisions
3. files changed
4. verification performed
5. remaining uncertainty or blockers
6. unrelated follow-up issues noticed but not changed
</output>

Why This Prompt Is Production-Ready

BlockControlsFailure It Reduces
ObjectiveComplete deliverableStopping after analysis or planning
Source authorityEvidence priorityUsing stale docs over current code or APIs
ScopeChange boundaryUnrequested refactors and cleanup
AutonomyAsk vs proceedRepeated permission requests during asynchronous work
Thinking and effortWhere deeper reasoning mattersOverthinking mechanical work
Tool policyBatching, argument quality, recoverySlow tool loops and guessed parameters
Conversation stateAppend-only continuityLost constraints and invalidated preserved thinking
Progress updatesUser visibilitySilent long-running agents or excessive narration
Editing policyDiff sizeWhole-file rewrites for small changes
TestingVerification scopeTest bloat or weak checking
DelegationParallelismLead-agent idle time and unnecessary subagents
CompletionStop condition“Next I will...” responses instead of finished work

Production prompting is not about making every instruction longer. It is about making the model's important operating boundaries explicit.

Common Claude Fable 5.1 Prompting Mistakes

1. Running Every Task at Max Effort

Higher effort can improve difficult work but also increases latency and token use. Start at high and measure whether stronger settings actually help.

2. Assuming Effort Labels Transfer Perfectly From Fable 5

Anthropic recommends re-running the effort sweep because model generations do not map the labels to identical amounts of thinking.

3. Manually Scripting Every Reasoning Step

Fable 5.1 already uses adaptive thinking. Define the task, evidence, constraints, and verification rather than forcing a brittle reasoning script.

4. Letting an Autonomous Agent Stop After Announcing the Next Step

Explicitly tell asynchronous agents that the request itself defines the deliverable and that reversible in-scope work should continue.

5. Asking for No Progress Updates and Then Expecting Visible Progress

Fable 5.1 is quieter between tool calls. Decide whether your interface wants narration and prompt accordingly.

6. Running Independent Tool Calls Sequentially

Add a short batching rule when your agent loop turns independent reads into separate round trips.

7. Rewriting Earlier Conversation Turns

Editing the prefix of a conversation can invalidate Fable 5.1 thinking blocks. Design long-lived integrations around append-only history.

8. Carrying Aggressive Anti-Formatting Rules From Older Claude Models

Fable 5.1 uses less formatting by default. Ask for the structure you want instead of suppressing formatting globally.

9. Ignoring Dense Prose

If readability matters, request shorter sentences, clearer paragraph breaks, and literal language.

10. Letting Document Summaries Blur Paraphrase and Quotation

Define when direct wording may be reproduced and how it must be marked.

11. Allowing Nearby Coding Cleanup to Expand the Task

Tell Claude to report unrelated problems instead of fixing them unless the requested behavior depends on the change.

12. Turning Every Verification Scratch File Into a Permanent Test

Separate temporary validation from the repository's permanent test suite.

13. Trusting Memory for Fast-Moving Facts at Low Effort

Require current verification when names, versions, pricing, policies, or releases may have changed.

14. Rewriting Whole Files for Small Edits

Use a targeted-edit rule when review size, latency, or output tokens matter.

15. Using Xhigh or Max for a Huge Deliverable Without Output Headroom

Reasoning and the final deliverable share finite output capacity. Measure whether high effort is already sufficient.

16. Making the Lead Agent Wait for Every Subagent

Let the lead continue independent work and consume delegated results when they arrive.

17. Asking Vision Questions About Unreadable Details Without Zooming

For dense visuals, provide crop-and-zoom tooling or explicitly mark unreadable values as uncertain.

18. Judging Prompt Quality by Prompt Length

A shorter prompt with precise boundaries can outperform a longer prompt full of redundant guidance.

How to Evaluate Fable 5.1 Prompts

Anthropic explicitly recommends evaluating effort levels against your own tasks.

The same principle applies to prompt changes.

BASELINE PROMPT
      ↓
REPRESENTATIVE TEST CASES
      ↓
FABLE 5.1 @ HIGH
      ↓
MEASURE
- task success
- completion rate
- unnecessary questions
- tool-call count
- tool batching
- grounding
- scope adherence
- verification
- latency
- tokens
- cost
      ↓
COMPARE EFFORT / PROMPT VARIANTS
      ↓
KEEP / REVISE / REVERT

For a long-running agent, output quality alone is not enough.

Track behavior such as:

  • Did the task finish without unnecessary “continue” turns?
  • Did independent calls batch appropriately?
  • Did the agent preserve scope?
  • Did it perform destructive or external actions only when authorized?
  • Did it keep users informed at the right level?
  • Did it verify before claiming success?
  • Did lower effort skip required current-data retrieval?
  • Did higher effort materially improve outcome quality?

See AI Prompt Evaluation and Prompt Versioning and Lifecycle Management.

Where PrompTessor Fits

Claude Fable 5.1 prompt iteration workflow showing rough prompt PrompTessor generation analysis optimization refinement Claude candidate effort target agent evaluation versioning and stable prompt
PrompTessor fits at the prompt-design and iteration layer; effort, tools, preserved thinking, runtime orchestration, and production evaluation remain in the Claude application.

PrompTessor can help improve the prompt candidate used with Claude Fable 5.1.

ROUGH IDEA / EXISTING PROMPT
          ↓
PrompTessor
├ Generate
├ Analyze
├ Optimize
├ Refine
├ Compare iterations
└ Save reusable prompts
          ↓
CLAUDE FABLE 5.1 PROMPT CANDIDATE
          ↓
TARGET APP / API / AGENT
├ effort
├ tools
├ system instructions
├ conversation history
└ runtime permissions
          ↓
REAL BEHAVIOR
          ↓
EVALUATION
          ↓
REFINE / VERSION / RETEST

AI Prompt Analysis can help identify prompt-level weaknesses such as unclear goals, missing context, weak constraints, incomplete output requirements, or poor model fit.

AI Prompt Optimizer can improve an existing prompt with optional model targeting.

Prompt Refinement can apply specific feedback after you observe Fable 5.1 behavior in the real workflow.

PrompTessor does not set Anthropic's effort parameter in your API, manage preserved thinking blocks, execute Claude tools, control conversation-prefix binding, orchestrate subagents, or run production evaluations. Those are responsibilities of the target application and Anthropic runtime.

Use PrompTessor to improve the instruction artifact, then test that exact prompt with the effort level, tools, context, and permissions it will use in production.

Fable 5.1 in the Broader ChatGPT vs Claude Decision

Claude Fable 5.1 is one model inside the broader Claude platform. Choosing between Claude and ChatGPT involves more than comparing a single model's raw capability.

The product surface, tools, file handling, structured output support, deployment environment, pricing, governance requirements, and the exact model version can all affect the decision.

For a broader platform-level comparison, see ChatGPT vs Claude.

This guide stays focused on prompting Claude Fable 5.1 itself. A direct model-to-model comparison should use the exact current models, comparable workloads, disclosed settings, and explicit limitations rather than treating the two platform names as interchangeable.

Claude Fable 5.1 Prompting Checklist

  • Is the complete deliverable clear?
  • Does the prompt distinguish the goal from the method?
  • Is the effort level appropriate for the task?
  • Has high been compared with medium, low, xhigh, or max where the tradeoff matters?
  • Are you avoiding hand-written reasoning steps that do not reflect a real process requirement?
  • Does an asynchronous task define what Claude may do without asking again?
  • Are destructive or genuine scope-change actions separated from reversible work?
  • Does the task have a clear completion condition?
  • Can Claude finish independent work before reporting a blocker?
  • Does the user need visible progress during long tool runs?
  • Are progress updates milestone-based rather than command-by-command narration?
  • Are independent tool calls batched when possible?
  • Are dependent calls kept sequential?
  • Are tool arguments discovered rather than guessed?
  • Is conversation history append-only when preserved thinking blocks are replayed?
  • Are per-turn reminders added through supported runtime mechanisms rather than rewriting earlier turns?
  • If context is compacted, are user constraints, decisions, current state, blockers, and exact identifiers preserved?
  • Does writing guidance address density and readability positively?
  • Have obsolete anti-formatting instructions been removed?
  • Are quotations clearly distinguished from paraphrases?
  • Are source authority and conflict rules explicit?
  • Does coding scope say what not to change?
  • Are scratch checks separated from permanent tests?
  • Does low-effort work verify current or uncertain facts when freshness matters?
  • Are small file changes implemented as targeted edits when practical?
  • Is there enough output headroom for long deliverables at xhigh or max?
  • Can the lead agent keep working while independent subagents run?
  • Do complex vision tasks have crop-and-zoom capability when needed?
  • Are long documents structured clearly with XML or equivalent boundaries?
  • Has the prompt been evaluated on representative and edge cases?
  • Is the exact prompt and model configuration preserved for regression testing?

Official Anthropic Resources

FAQ

What is Claude Fable 5.1?

Claude Fable 5.1 is Anthropic's most capable generally available model for ambitious coding and knowledge work, including long-running agents, multi-step research, computer use, and large document workflows.

What is the Claude Fable 5.1 API model ID?

The current Claude API model ID is claude-fable-5-1.

What is the best way to prompt Claude Fable 5.1?

Define the complete deliverable, relevant context, scope, autonomy, tool policy, evidence rules, verification, output, and stop condition. For complex workflows, also define progress behavior, delegation, and conversation-state requirements.

What effort level should I use with Claude Fable 5.1?

Anthropic recommends starting at high and testing low, medium, xhigh, and max on representative tasks to find the best intelligence, latency, and cost tradeoff.

Is adaptive thinking always on in Claude Fable 5.1?

Yes. Anthropic documents adaptive thinking as always on for Fable 5.1. The effort parameter controls thinking depth.

Can I use budget_tokens with Claude Fable 5.1?

No. Fable 5.1 does not use the older manual extended-thinking configuration with budget_tokens. Use adaptive thinking and the effort parameter instead.

Can I disable thinking in Claude Fable 5.1?

No. Anthropic documents thinking as always on for Claude Fable 5.1.

Why does Claude Fable 5.1 stop and ask me to continue?

On long asynchronous tasks, the model may sometimes describe the next step or ask permission for work already implied by the request. Define reversible in-scope work as authorized and give the task an explicit completion condition.

Why is Claude Fable 5.1 quiet during long tool runs?

Fable 5.1 produces fewer user-facing updates between tool calls than Fable 5. If your interface needs progress visibility, ask for concise milestone updates and use Anthropic's supported progress-display controls where appropriate.

How do I make Claude Fable 5.1 call tools in parallel?

Tell it to batch tool calls that do not depend on one another and to keep dependent calls sequential. Do not use guessed placeholders merely to create artificial parallelism.

Why should Fable 5.1 conversation history be append-only?

Preserved thinking blocks can be bound to the exact conversation prefix that produced them. Editing earlier system instructions, tools, or messages can invalidate later thinking blocks.

Does Claude Fable 5.1 support long context?

Yes. Anthropic's current documentation lists a one-million-token context window and up to 128,000 output tokens.

Should I use XML tags in Claude Fable 5.1 prompts?

XML tags are useful when a prompt mixes instructions, documents, examples, variable inputs, or nested source material. They are not mandatory for every simple prompt.

Why does Claude Fable 5.1 write dense prose?

Anthropic notes that Fable 5.1 can produce longer sentences and fewer paragraph breaks than Fable 5 in some cases. Ask for direct literal prose, readable sentence length, and useful paragraph structure when this matters.

Why does Fable 5.1 use less formatting?

Anthropic reports that Fable 5.1 uses bold, headings, and lists less often than earlier Claude models. Remove aggressive anti-formatting rules and state when structure is useful.

How should I handle quotations in Claude Fable 5.1 research prompts?

Tell the model to paraphrase by default, mark direct quotations clearly, and separate verified source facts from inference and recommendation.

How should I prompt Claude Fable 5.1 for coding?

Define the requested behavior, affected scope, what must remain untouched, allowed autonomy, tool behavior, testing scope, verification criteria, and completion condition.

Why does Fable 5.1 sometimes rewrite a whole file?

Anthropic notes that Fable 5.1 is more likely than Fable 5 to rewrite entire files for small changes. A targeted-edit instruction can reduce unnecessary output tokens and larger diffs.

Should I use max effort for long documents?

Only when evaluation shows a meaningful quality gain. At xhigh and max, Fable 5.1 may spend more output capacity reasoning before writing a long deliverable, so high can be a better starting point.

How should I use subagents with Claude Fable 5.1?

Delegate materially independent work, let the lead agent continue tasks that do not depend on pending results, and keep final integration, conflict resolution, and verification with the lead.

How do I improve vision performance on dense charts or PDFs?

Give Fable 5.1 access to crop-and-zoom tooling when possible and instruct it to inspect difficult regions before making claims about small labels, values, or annotations.

How do I know whether a Fable 5.1 prompt is better?

Compare prompt and effort variants on the same representative test cases and measure task success, completion, tool behavior, grounding, scope adherence, verification, latency, token use, and cost.

Can PrompTessor optimize prompts for Claude Fable 5.1?

PrompTessor can help generate, analyze, optimize, refine, compare, and save prompt candidates with model-aware context. The final prompt should still be evaluated in the actual Claude Fable 5.1 workflow with the intended effort, tools, history, and permissions.

Is Claude Fable 5.1 directly comparable with GPT-6 Astra?

They can be compared as current high-end models for demanding coding, agentic, research, and professional workflows, but a useful comparison should use exact model versions, comparable tasks, disclosed settings, and explicit benchmark or methodology limitations rather than treating the broader ChatGPT and Claude platforms as identical to the models.

Conclusion

Claude Fable 5.1 is designed for work that continues after the first answer.

That makes its best prompting practices unusually operational.

Effort determines how much capability you are buying for a task. Adaptive thinking is always on. Tool-loop structure affects speed. Progress policy affects user experience. Append-only history affects preserved reasoning. Scope rules affect code review. Completion rules determine whether a long-running agent actually finishes the job.

GOOD FABLE 5.1 PROMPTING
=
CLEAR DELIVERABLE
+
RIGHT EFFORT
+
USEFUL CONTEXT
+
EXPLICIT SCOPE
+
AUTONOMY BOUNDARIES
+
TOOL POLICY
+
PRESERVED STATE
+
VERIFICATION
+
CLEAR STOP CONDITION

Do not add every possible instruction to every task.

For a short transformation, a concise prompt may be enough. For a multi-hour coding agent, research workflow, or computer-use system, the prompt becomes part of the operating contract that keeps the work moving in the right direction.

The best Claude Fable 5.1 prompt is not the most elaborate one. It is the one that gives a capable long-running model enough structure to finish the right work without creating unnecessary friction.

Build better prompts in one workspace

Generate prompts from ideas, analyze and optimize quality, refine with feedback, reverse-engineer content, and save reusable prompts in your Prompt Library.

Try PrompTessor Free