Claude Fable 5 Pricing and Capabilities

Short version: Claude Fable 5 is Anthropic's highest-capability generally available model as of 9 June 2026. The API price is $10 per million input tokens and $50 per million output tokens. US-only inference is available at 1.1x the normal token price.

What Anthropic shipped

Anthropic published Claude Fable 5 on 9 June 2026, and the positioning is pretty clear: this is the model they want people to use when the work is too long, too complex, or too agent-heavy for normal chat usage. The page calls out long-running agent work, ambitious coding projects, enterprise knowledge work, and vision-heavy document tasks.

So for me this is less about "which chatbot is better" and more about architecture. If a model can run inside Claude Code, Claude Managed Agents, the Claude API, Amazon Bedrock, Vertex AI, and Microsoft Foundry, the real questions are cost control, retention, routing, governance, and where it fits compared with cheaper models.

Pricing

The pricing is simple on paper. Anthropic lists Claude Fable 5 at $10 per million input tokens and $50 per million output tokens. Prompt caching still gets the existing 90% input token discount, which matters if you're sending the same repository map, policy pack, schema, or long background document into repeated runs.

Compared with Claude Opus 4.7 and Opus 4.8 standard pricing, Fable is twice the price. Opus 4.7 and 4.8 are listed at $5 per million input tokens and $25 per million output tokens, while Fable is $10 and $50. The one caveat is Opus 4.8 fast mode, which also lands at $10 and $50, so the clean comparison is against the normal Opus price rather than every possible Opus mode.

The more interesting part is not only the token price. Anthropic is treating subscription access as temporary. Fable is included in Pro, Max, Team, and seat-based Enterprise plans only through 22 June 2026. From 23 June 2026, Anthropic says usage requires credits unless it extends the included window based on capacity. That is a different kind of pricing control: not just charging more per token, but moving the most capable model out of predictable flat-rate usage.

Item	Claude Fable 5	What I would watch
Input tokens	$10 per million tokens	Large context uploads, repo summaries, retrieval payloads, and repeated instruction blocks.
Output tokens	$50 per million tokens	Code generation, long reports, migration plans, test output, and multi-file refactoring sessions.
Prompt caching	90% input token discount for cached prompt content	Cache stable context. Don't rebuild huge prompts every turn if the platform can reuse them.
US-only inference	1.1x input and output token pricing	Useful for workloads with US residency requirements, but price it before enabling by default.
Enterprise plan	Consumption-based Enterprise availability	Seat cost and usage cost are separate on Enterprise, so finance needs both numbers.
Claude subscription access	Included on Pro, Max, Team, and seat-based Enterprise plans through 22 June 2026; usage credits required from 23 June unless Anthropic extends the window.	Do not build internal workflows assuming flat-rate Fable access will remain available.

Quick math: one million input tokens plus 200,000 output tokens is about $20 before caching, regional premiums, or platform-specific charges. That isn't scary for a single serious engineering task. It becomes a budget problem when ten agents run all day, produce long outputs, and keep retrying after failed tests.

The output side is the cost trap. A model that reads a large context once and writes a short patch note is manageable. A model that writes logs, explanations, failed test output, regenerated files, and long summaries every loop can spend more on output than the original task deserved. For agent work, I would budget by loop, not by prompt.

This may also be a signal for how frontier model access changes over time. Monthly plans may keep the strong everyday models, while the highest tier of model capability moves toward usage credits, API billing, or enterprise consumption. I would not call that a settled pattern yet. But I would track it, because it affects how teams design agent workflows, budget approval, and user expectations.

Agent loop	Token driver	Control
Plan	Repository map, requirements, policy files, and design notes.	Cache stable context and keep the plan output short.
Act	Tool results, file reads, diffs, and generated code.	Limit file scope and require patch-style changes.
Verify	Test logs, browser screenshots, trace output, and retry context.	Summarize failures and attach only the failing section back to the model.
Report	Final explanation, evidence, and handoff notes.	Use a short operational template rather than a full narrative each time.

Capabilities

The model docs list the API ID as claude-fable-5. Anthropic's model overview says Fable 5 has a 1M token context window, 128k max output, adaptive thinking always on, and availability through the Claude API, Claude Platform on AWS, Amazon Bedrock, Vertex AI, and Microsoft Foundry.

Capability	What Anthropic says	Practical use
Agents	Can work for days in an agent harness, plan across stages, delegate, and check its work.	Multi-step engineering tasks, backlog cleanup, long research runs, and controlled automation.
Coding	Built for large migrations, complex implementations, test writing, and visual checks.	Repo-wide changes where the model must read, edit, test, inspect output, and repair failures.
Enterprise workflows	Handles multi-stage knowledge work with less supervision.	Research packs, risk reviews, policy mapping, financial analysis, and document-heavy workflows.
Vision	Understands diagrams, charts, and tables in files and PDFs.	Architecture reviews, screenshots, UI verification, spreadsheet checks, and document analysis.
Context and output	1M token context and 128k max output.	Large codebases and long evidence packs, if you keep retrieval and logging under control.

The 1M token context changes design choices, but it does not remove the need for retrieval. For a codebase, I would still send a structured repository index first, then load only the files needed for the task. For a document-heavy workflow, I would keep citations and chunk IDs in the context so the final answer can be checked without replaying the whole session.

Tool use and state

Fable's agent pitch only works if the surrounding harness is strict. The model needs tool access, but the tool layer should decide what is allowed. Filesystem writes, shell commands, browser actions, ticket updates, and deployment steps should have separate permissions. A long-running model with one generic "execute" tool is how small mistakes become expensive mistakes.

For state, I would keep three stores separate:

Task state: plan, current step, blockers, and completed checks.
Evidence state: source files, retrieved chunks, screenshots, command output, and citations.
Decision state: approvals, policy exceptions, model routing, and cost limits.

That separation makes it easier to resume an agent safely. It also helps during incident review when someone asks what the model saw and what it changed.

Where I would use it

I wouldn't route every support question or small code edit to Fable. The price tells you what it is for. Use it where the cost of a poor answer, partial implementation, or broken handoff is higher than the model bill.

Large code migrations: framework upgrades, SDK migrations, test repair, and changes that touch many folders.
Agentic delivery: work where the model plans, edits, validates, and keeps state across many steps.
Architecture review: diagrams, documents, policy controls, and implementation plans in the same run.
Enterprise analysis: long evidence packs where the model needs to compare claims, produce a reviewable deliverable, and cite the source material.

For cheaper and shorter tasks, I would still keep Sonnet or Haiku-style routing in the design. A sensible pattern is a router: cheaper model for triage and extraction, Fable for the hard step, then cheaper model again for formatting or post-processing if the output doesn't need frontier reasoning.

Routing pattern

A practical router should look at task risk, tool access, context size, and expected output length. I would not route based only on user preference or a vague "complexity" flag.

Route to Fable	Use a cheaper model
Multi-file edits with tests and browser validation.	Single-file edits, formatting, or short Q&A.
High-risk analysis where missed context is costly.	Extraction, classification, or summarizing already-clean data.
Agent runs with tool use, retry loops, and long memory.	One-shot generation with no external side effects.

The Microsoft Foundry angle

Anthropic lists Microsoft Foundry as one of the places where developers can access Claude Fable 5. That matters for Azure-heavy organizations because model access is only one part of the rollout. You still need the surrounding controls: project scoping, identity, network rules, telemetry, content filtering decisions, chargeback, and approval flow.

What I would validate before putting it in front of teams:

Which Foundry project owns the deployment and who can call it.
Whether private networking, managed identity, and logging match the workload classification.
How prompts, outputs, traces, and files are retained.
Where spend limits and alerts live, especially for long-running agents.
Whether the same workload needs US-only inference or another residency constraint.

For a real Foundry rollout, I would capture these items in the deployment record:

Model deployment: model name, provider, region, SKU or consumption mode, fallback model, and owner.
Identity: managed identity, calling application, user delegation model, and RBAC assignments.
Network: public access setting, private endpoint design, DNS, and outbound dependency list.
Logging: prompt logging decision, trace destination, retention period, and redaction rules.
Controls: content filters, spend alerts, rate limits, approval steps, and incident owner.

Note: Don't let a 1M context window become an excuse to send everything. Long context is useful, but retrieval discipline still matters. Send the right evidence, cache stable prompt sections, and log enough to explain the bill later.

Safeguards and retention

Two operational details stood out. First, Anthropic says Fable has safeguards for cybersecurity and biology. Flagged requests in those areas can route to Opus 4.8 instead, and Anthropic says customers won't be charged Fable prices for rerouted requests. API customers need to configure the fallback behavior.

Second, using Fable requires 30-day data retention for safety monitoring. That doesn't automatically rule it out, but it does mean you need to check the data classification before feeding it production secrets, regulated records, customer evidence, or legal material. This is the kind of detail that should be in the design review, not discovered after a pilot.

API starting point

The model name Anthropic gives for API usage is claude-fable-5. A minimal request shape looks like this:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-fable-5",
    "max_tokens": 4096,
    "messages": [
      {
        "role": "user",
        "content": "Review this migration plan and list the risky steps."
      }
    ]
  }'

For real agent work I would add explicit spend limits, request logging, prompt caching where supported, and a workload policy that says when Fable is allowed. Otherwise the model choice becomes a hidden cost decision made by whoever writes the prompt.

For an application service, I would wrap the raw model call behind a small internal API. That API can enforce cost caps, redact obvious secrets, add stable system instructions, stamp trace IDs, and record which route picked Fable.

{
  "model": "claude-fable-5",
  "workload": "repo-migration-agent",
  "controls": {
    "max_agent_loops": 8,
    "max_output_tokens_per_loop": 4096,
    "cache_static_context": true,
    "require_tool_approval_for": ["shell", "deployment", "ticket_update"],
    "log_trace_id": true
  }
}

Evaluation before rollout

I would not pilot Fable only with happy-path prompts. Build a small evaluation set from actual work: failed migrations, messy PDFs, policy conflicts, broken unit tests, and ambiguous tickets. Then compare Fable against the cheaper route on quality, runtime, tool calls, cost, and number of human corrections.

Metric	What to measure
Task completion	Did it finish the requested work without skipping required checks?
Correction rate	How many human edits were needed before the output was usable?
Tool discipline	Did it use the right tools, avoid unnecessary reads, and stop after validation?
Cost per accepted task	Total model cost divided by tasks accepted into production or final review.

What to check before a pilot

Check	Operational reason
Model routing	Define which tasks use Fable and which tasks use a cheaper model.
Token budget	Long-running agents can create cost through retries, logs, and generated artifacts.
Retention	Fable requires 30-day data retention for safety monitoring.
Fallback behavior	Cybersecurity and biology requests may route to Opus 4.8, so the application must handle that cleanly.
Evidence handling	Large context windows make it easy to overshare data. Classify the inputs before the pilot.
Platform route	Claude API, Bedrock, Vertex AI, and Microsoft Foundry each have different operational controls.