Fable 5.1 Is Live: Prices Stayed Flat, So How Can Agent Costs Fall by 45%?

Anthropic released Claude Fable 5.1 and Claude Mythos 5.1 on September 1, 2026.

The launch comes with an apparent contradiction. Standard input and output prices have not changed: Fable 5.1 still costs $10 per million input tokens and $50 per million output tokens. Yet Anthropic estimates that typical workloads can cost about 25% less, while highly agentic workloads may save up to approximately 45%.

The answer is not the base token rate. It is the way agents repeatedly read context.

Fable 5.1 cuts cache-read pricing from $1.00 to $0.25 per million tokens. That difference may barely register in a one-shot conversation. It matters far more when an agent works for hours, calls tools repeatedly, and carries the same system prompt, tool definitions, project instructions, and history into every step.

Fable 5.1 is therefore best understood not simply as a stronger chat model, but as a model whose economics and interfaces have been tuned for long-horizon agent work.

For users accessing it through Apito, the current console lists a separate platform rate. The claude-fable-5-1svg route is priced at $8 per million input tokens and $40 per million output tokens—20% below Anthropic’s standard rates in both categories. The sections below keep official pricing, platform pricing, and cache labels clearly separated.

Verified specifications: expensive, slower, and built for hard work

The official Claude API model ID is:

claude-fable-5-1

claude-fable-5-1

This is not a model that should automatically receive every request.

Anthropic’s own documentation says most workloads should start with Opus 5. Fable 5.1 is intended for demanding reasoning, long-horizon agentic work, or cases where Opus 5 at higher effort still fails an organization’s evaluations.

That qualification matters more than a leaderboard. Fable 5.1 is not always the cheapest choice. Its purpose is to make certain high-value tasks possible or reliably completable.

The benchmarks are strong—but read the test conditions

Anthropic’s summary table reports 52.6% on Terminal-Bench-Science 0.1, 55.8% on Terminal-Bench 4.0, 73.4% on CursorBench 3.2, 77.9% on OSWorld 2.0 partial, and 65.0% on Humanity’s Last Exam with tools.

Those results support the model’s positioning around difficult tool use, coding environments, and cross-application work. They do not mean your production success rate will improve by the same margin. Four caveats matter:

1. Some results use tools or different effort levels, so compare like with like.
2. Terminal-Bench-Science has a reported standard error of roughly ±3.5–4.5 percentage points.
3. OSWorld uses an August 2026 task set and is not directly comparable with older published runs.
4. Production safeguards and routing can change behavior by account, region, and task category.

The defensible conclusion is not “Fable wins every benchmark.” It is that Fable 5.1 shows meaningful promise on long-horizon tool use and hard reasoning, while deployment value still depends on evaluation against your own work.

Current Apito pricing: 20% below the official standard input and output rates

As of September 2, 2026, the Apito console marks the route as recommended and displays this model name:

claude-fable-5-1svg

claude-fable-5-1svg

One distinction is essential. Apito labels these fields “input cache” and “output cache,” while Anthropic documents cache reads, five-minute cache writes, and one-hour cache writes. The naming systems are not identical, so this article does not map one set directly onto the other. Use Apito’s billing details for actual settlement behavior.

Scenario 1: a one-shot analysis

For one million input tokens and 200,000 output tokens, excluding caching:

Anthropic standard rate:
1 × $10 + 0.2 × $50 = $20

Current Apito platform rate:
1 × $8 + 0.2 × $40 = $16

Difference: $4, or 20% lower

Anthropic standard rate:
1 × $10 + 0.2 × $50 = $20

Current Apito platform rate:
1 × $8 + 0.2 × $40 = $16

Difference: $4, or 20% lower

Scenario 2: output-heavy code generation

For 200,000 input tokens and one million output tokens:

Anthropic standard rate:
0.2 × $10 + 1 × $50 = $52

Current Apito platform rate:
0.2 × $8 + 1 × $40 = $41.60

Difference: $10.40, or 20% lower

Anthropic standard rate:
0.2 × $10 + 1 × $50 = $52

Current Apito platform rate:
0.2 × $8 + 1 × $40 = $41.60

Difference: $10.40, or 20% lower

Scenario 3: an agent that reuses substantial context

If an Apito usage record contains five million input-cache tokens and 500,000 output-cache tokens, the arithmetic under the current console labels is:

5 × $0.20 + 0.5 × $10 = $6

5 × $0.20 + 0.5 × $10 = $6

This calculation only illustrates the two Apito cache fields. It does not imply that the entire task costs $6. Ordinary input, ordinary output, cache creation behavior, routing, and other billing items may still apply. Reconcile usage logs with the final bill before scaling production traffic.

Platform pricing and model availability can change. Before purchase or deployment, confirm the current model name, rates, and settlement rules in the Apito console.

If token prices stayed flat, where do the savings come from?

A normal chat and an agent do not have the same token profile.

A one-shot request may process its system prompt, user message, and attachments once. An agent can go through dozens or hundreds of steps: reading a repository, searching, running commands, checking results, replanning, and starting another tool loop.

Every step may carry a large stable prefix:

• system instructions and safety rules;
• tool names, schemas, and usage guidance;
• project conventions, code indexes, or knowledge bases;
• conversation and tool-call history;
• acceptance criteria for the current task.

If that prefix stays byte-for-byte identical, prompt caching prevents it from being charged as ordinary input on every request.

Consider a simplified example. A coding agent has a 100,000-token stable prefix that is read again in 20 later steps. Ignoring the initial cache write, dynamic input, and model output:

Total cache reads = 100,000 × 20 = 2,000,000 tokens

Fable 5:
2 MTok × $1.00 = $2.00

Fable 5.1:
2 MTok × $0.25 = $0.50

Cache-read savings alone: $1.50, or 75%

Total cache reads = 100,000 × 20 = 2,000,000 tokens

Fable 5:
2 MTok × $1.00 = $2.00

Fable 5.1:
2 MTok × $0.25 = $0.50

Cache-read savings alone: $1.50, or 75%

The whole task does not become 75% cheaper. Cache creation, uncached dynamic context, and output tokens still cost money. If a higher effort setting produces substantially more output, the final dollar cost can even increase.

That is why Anthropic describes approximately 25% savings for typical workloads and up to about 45% for highly agentic workloads. These are official workload estimates, not a guarantee for every call.

Cheaper caching only helps when your prefix is stable

Claude prompt caching matches the full prefix across tools, system, and messages. Text, images, and tool schemas must match exactly.

Common cache breakers include:

• putting timestamps or request IDs at the front of the system prompt;
• reordering tools or JSON keys on every request;
• editing the top-level system field to inject a temporary reminder;
• inserting, deleting, or rewriting earlier messages;
• placing a cache breakpoint after changing user content.

A better layout keeps stable material first and dynamic content last:

Tool definitions
  ↓
Stable system instructions
  ↓
Project rules / examples / background
  ↓  cache breakpoint
Conversation history
  ↓
Current dynamic input

Tool definitions
  ↓
Stable system instructions
  ↓
Project rules / examples / background
  ↓  cache breakpoint
Conversation history
  ↓
Current dynamic input

In production, track more than total tokens:

• cache_creation_input_tokens
• cache_read_input_tokens
• uncached input tokens
• output tokens
• task completion rate
• total cost per successful task

If cache creation and read fields remain zero, check the minimum prefix length, breakpoint placement, and whether your serialized content is actually stable.

Here is a minimal automatic-caching request. The important part is the structure: stable instructions first, changing input last.

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-1",
    "max_tokens": 2048,
    "cache_control": {"type": "ephemeral"},
    "system": [{"type": "text", "text": "You are a code-review agent. These repository rules remain stable..."}],
    "messages": [{"role": "user", "content": "Review this change and report only merge-blocking defects."}]
  }'

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-1",
    "max_tokens": 2048,
    "cache_control": {"type": "ephemeral"},
    "system": [{"type": "text", "text": "You are a code-review agent. These repository rules remain stable..."}],
    "messages": [{"role": "user", "content": "Review this change and report only merge-blocking defects."}]
  }'

For a transparent cost model, calculate each usage category separately:

cost = uncached_input_MTok × 10
     + 5m_cache_write_MTok × 12.5
     + 1h_cache_write_MTok × 20
     + cache_read_MTok × 0.25
     + output_MTok × 50

cost = uncached_input_MTok × 10
     + 5m_cache_write_MTok × 12.5
     + 1h_cache_write_MTok × 20
     + cache_read_MTok × 0.25
     + output_MTok × 50

The operational metric that matters is total cost / successfully completed tasks. A cheap call that repeatedly fails can be more expensive than a premium call that finishes once.

The real target is not code completion—it is finishing long tasks

Anthropic positions Fable 5.1 for demanding reasoning and long-horizon agentic work.

The goal is a complete loop rather than a better isolated code snippet:

Understand → inspect → plan → use tools → verify
     ↑                                 ↓
     └──── diagnose failures and iterate ────┘

Understand → inspect → plan → use tools → verify
     ↑                                 ↓
     └──── diagnose failures and iterate ────┘

Official use cases include codebase-wide features, difficult reviews, performance engineering, multi-day autonomous sessions, and multi-stage knowledge work across documents, spreadsheets, presentations, and browsers.

Anthropic also cites an early-access case from Millennium. An internal system had a crash that appeared roughly once in a million runs and had remained unexplained for years. Fable 5.1 reportedly disassembled an external vendor library, compared it with a core dump, and traced the failure to a bug in that library.

The case illustrates the model’s intended role, but it remains a partner-reported example published by Anthropic, not a broad independent evaluation. Teams should test the model on their own repositories and acceptance criteria.

Other early-access reports show a similar pattern. Ramp ran a machine-learning task for 38 hours across six parallel experiments. MongoDB described complex prototyping over hours without intervention. Shopify reported that the model records unresolved issues and reprioritizes them during long tasks. Together, these cases point to three capabilities that matter more than raw typing speed: preserving the goal, changing course after failure, and maintaining consistent acceptance criteria across subproblems.

An external code-review snapshot: less noise, not more speed

CodeRabbit evaluated review output across 45 tasks containing 105 known issue points. Its comparison did not show a universal win:

Fable 5.1 found roughly the same share of known issues while producing far fewer noisy comments, but it took longer. In this task set, raising effort from low to high did not help: recall fell from 61.0% to 57.1%, while latency rose to 21:36.

Two practical lessons follow. First, effort is not a quality slider that should always be set to maximum; test low, medium, and high against a fixed task set. Second, Fable 5.1 may be better reserved for fewer, harder reviews—architecture changes, concurrency bugs, security boundaries, and cross-module root-cause analysis—while routine pull requests stay on a faster model.

CodeRabbit notes that the two snapshots used an updated review pipeline, so this is not a strict same-day head-to-head experiment. It is useful independent evidence, not a substitute for internal evaluation.

Three scientific cases that move beyond text generation

Anthropic devoted substantial attention to scientific research. The interesting part is not simply that the model generated an answer, but that outputs entered computational or experimental validation loops.

1. Protein binder design

Anthropic gave Mythos 5.1 access to open-source protein design and folding tools, then sent its designs to two external organizations for experimental validation.

Anthropic reports that binding affinity on three targets was ten times higher than the best submissions to Adaptyv Bio protein-design competitions. Across 12 targets, the viable-binder hit rate approached 50%, compared with an industry-typical range of 10–15% cited by Anthropic.

This is stronger evidence than model self-evaluation, but it is still a study organized and reported by Anthropic. Independent replication remains important.

2. Mapping one-third of Venus

Fable 5.1 trained a neural network on radar imagery collected by NASA’s Magellan mission more than 30 years ago. It produced a new elevation map covering roughly one-third of Venus.

Anthropic says the map reveals details at a two-to-three-kilometer scale, compared with 10–20 kilometers in the earlier map, with height estimates up to 25% more accurate. The map has been released under a Creative Commons license for potential use in future observation planning.

3. Custom GPU kernels for seven biology models

Mythos 5.1 wrote custom GPU kernels for seven open-source protein and genomics models and cached intermediate results. Anthropic reports speedups of up to 2.5× with identical outputs and estimated GPU-cost reductions of 30–60% for some genome-wide analyses.

None of this means an AI can independently “do science.” Humans still provide data, tools, objectives, evaluation methods, and expert review. The meaningful change is that a model can participate in a loop of proposing a method, using tools, running computation, generating candidates, and facing real-world validation.

Migrating from Fable 5: three breaking changes

If you already use Fable 5, migration involves more than changing the model ID.

Before modifying an agent framework, verify the model, account, and network path with a minimal request:

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-1",
    "max_tokens": 512,
    "messages": [{"role": "user", "content": "Reply with: connection ok"}]
  }'

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-1",
    "max_tokens": 512,
    "messages": [{"role": "user", "content": "Reply with: connection ok"}]
  }'

Once that succeeds, add tools, caching, thinking blocks, model routing, and history compaction one at a time. When a 400 response appears, this sequence makes the offending layer much easier to identify.

1. Invalid forced-tool combinations now return errors

Applications that force a specific tool with tool_choice must test whether each combination is valid. Do not rely on behavior that an earlier model may have tolerated.

Regression coverage should include forced tools, automatic selection, no-tool fallback, schema failures, and continuation after a tool result.

2. Earlier models cannot read Fable 5.1 thinking blocks

If a conversation can switch from Fable 5.1 to an earlier model, do not assume its thinking blocks can be replayed unchanged.

Routing logic must check content-block compatibility, not just text compatibility. When switching to an incompatible model, create a fresh compressed context rather than replaying unsupported thinking blocks.

3. Editing the conversation prefix invalidates thinking blocks

For API accounts created on or after August 31, 2026, Fable 5.1 thinking blocks are valid only in the exact conversation prefix that produced them.

Changing the system prompt, tool list, or an earlier message can cause a 400 response. A beta control can instead drop affected blocks and record the transformation:

{
  "thinking": {
    "block_binding": {
      "prefix_mismatch_behavior": "drop_block"
    }
  }
}

{
  "thinking": {
    "block_binding": {
      "prefix_mismatch_behavior": "drop_block"
    }
  }
}

This should not become a permanent way to hide integration bugs. During migration, use it to run complete multi-turn sessions, inspect input_transformations, and find places where the framework silently rewrites history.

The new conversation rule: append, do not rewrite

Treat messages as an append-only log.

const history = [];

history.push({ role: "user", content: userInput });
const response = await callClaude(history);
history.push({ role: "assistant", content: response.content });

// Append the next turn. Do not rewrite history[0] or mutate old tool definitions.
history.push({ role: "user", content: nextInput });

const history = [];

history.push({ role: "user", content: userInput });
const response = await callClaude(history);
history.push({ role: "assistant", content: response.content });

// Append the next turn. Do not rewrite history[0] or mutate old tool definitions.
history.push({ role: "user", content: nextInput });

Use turn-scoped system messages for temporary reminders. Use mid-conversation system messages and supported tool-addition or removal mechanisms when instructions or tools must change. Prefer server-side compaction or context editing when history needs to shrink.

If client-side compaction is unavoidable, a clean approach is to start a new context with one summary message and the new user turn, carrying no old thinking blocks. The model reasons again from the compressed facts instead of replaying an altered history.

This pattern supports both goals: thinking-block integrity and a stable cache prefix.

Stronger agents require stronger deployment guardrails

An agent that can run longer and call more tools can also propagate one bad decision further. Anthropic places Fable 5.1 under Enterprise Frontier Safeguards and reports roughly 60% fewer cyber interventions per Claude Code session and 85% fewer benign biology or medical triggers than the previous generation.

Those figures describe a safety system tuned to interrupt fewer legitimate tasks. They are not a reason to remove application-level controls. Production deployments should still include:

• a tool allowlist and permissions graded by action risk;
• human approval before database writes, outbound messages, deployments, or deletion;
• input filtering for secrets, personal information, and customer data;
• logs containing each tool call, arguments, result, and initiating identity;
• hard limits for tokens, tool calls, elapsed time, and budget;
• a kill switch plus a way to reverse external side effects.

The durable design principle is simple: the model proposes and executes a plan; the surrounding system decides what it may touch. Sandboxes, approvals, and audit logs are permanent infrastructure for capable agents, not temporary patches for weak ones.

Choosing between Fable 5.1, Opus 5, and Sonnet 5

Choose by task value and evaluation results, not by a single ranking.

* Prices may vary by platform, region, and date. Check Anthropic’s current pricing page before publication or deployment.

A practical routing policy is:

1. Use Sonnet 5 for extraction, classification, simple transformations, and frequent interactions.
2. Use Opus 5 for most coding, analysis, and professional deliverables.
3. Escalate only root-cause investigations, long-running autonomous work, and high-value decisions to Fable 5.1.
4. Compare total cost per successful task, not just price per million tokens.

Start with transparent rules before building a complex learned router:

function chooseModel(task) {
  if (task.isRoutine && task.maxLatencyMs < 5000) return "sonnet";
  if (task.requiresRepoWideReasoning || task.expectedToolCalls > 40) return "fable-5-1";
  if (task.previousModelFailed && task.businessValue === "high") return "fable-5-1";
  return "opus-5";
}

function chooseModel(task) {
  if (task.isRoutine && task.maxLatencyMs < 5000) return "sonnet";
  if (task.requiresRepoWideReasoning || task.expectedToolCalls > 40) return "fable-5-1";
  if (task.previousModelFailed && task.businessValue === "high") return "fable-5-1";
  return "opus-5";
}

Review escalated tasks each week. Narrow the route if Fable 5.1 does not improve completion. Expand it only where the model measurably reduces human takeover and rework.

Managing model access and costs with Apito

The most common launch-day integration problem is rarely basic connectivity. It is model IDs, routing policies, cache hit rates, and history compatibility being scattered across multiple clients.

Apito provides a single layer for API keys, Base URLs, model routing, request logs, and cost visibility. OpenAI-compatible clients typically begin with:

export OPENAI_BASE_URL="https://gw.apito.ai/v1"
export OPENAI_API_KEY="YOUR_APITO_API_KEY"

export OPENAI_BASE_URL="https://gw.apito.ai/v1"
export OPENAI_API_KEY="YOUR_APITO_API_KEY"

Then confirm the model’s actual availability and identifier in the Apito console. An upstream announcement does not guarantee simultaneous availability across every third-party platform, region, or account.

Use a three-stage rollout:

1. Shadow evaluation: replay representative, sanitized tasks against Fable 5.1, Opus 5, and the current production model.
2. Small-traffic routing: send only a limited set of difficult tasks to Fable 5.1 and record success, latency, cache hits, and total cost.
3. Task-based escalation: upgrade the model only when explicit conditions are met instead of replacing every request globally.

Apito is an independent third-party API service and is not affiliated with or officially endorsed by Anthropic or Claude.

Ten checks before production rollout

• [ ] Is claude-fable-5-1 mapped to the identifier actually exposed by your provider?
• [ ] Have you rerun your own real-task evaluations instead of relying on public benchmarks?
• [ ] Are cache-creation and cache-read tokens recorded?
• [ ] Is dynamic information placed after the stable cached prefix?
• [ ] Are tool definitions and serialized key ordering stable?
• [ ] Have all forced-tool paths passed regression tests?
• [ ] Does model switching handle thinking-block compatibility?
• [ ] Is conversation history append-only?
• [ ] Have drop_block and input_transformations been used to diagnose prefix edits?
• [ ] Is routing based on total cost per successful task rather than token price alone?

FAQ

Did Fable 5.1 actually get cheaper?

Standard input and output prices stayed at $10 and $50 per million tokens. Cache reads fell from $1.00 to $0.25 per million tokens.

Through the route currently shown in Apito as claude-fable-5-1svg, the platform rates are $8 for input and $40 for output per million tokens, 20% below those official standard rates. This is Apito platform pricing, not an Anthropic price cut.

What do Apito’s “input cache” and “output cache” fields mean?

They are the labels currently used in the Apito console, priced at $0.20 and $10 per million tokens. Because Anthropic’s documentation divides caching into reads, five-minute writes, and one-hour writes, do not assume a direct mapping. Refer to Apito usage records and billing documentation for settlement details.

Why does the Apito model name end in svg?

claude-fable-5-1svg is the route name currently displayed by Apito. Anthropic’s official API model ID remains claude-fable-5-1. When using a third-party access layer, configure the exact model identifier exposed by that platform rather than guessing from upstream documentation.

Will every agent workload save 45%?

No. Anthropic says highly agentic workloads may save up to approximately 45%, while typical workloads are estimated at about 25%. Results depend on stable-prefix share, cache hit rate, output length, effort, and whether the task succeeds.

Should every Opus 5 request move to Fable 5.1?

No. Anthropic recommends starting most workloads with Opus 5. Upgrade only when internal evaluations show a meaningful completion-rate or quality gain.

What is the difference between Fable 5.1 and Mythos 5.1?

Anthropic says they use the same underlying model with different safeguards. Fable 5.1 is generally available, while Mythos 5.1 is limited to trusted-access programs such as Project Glasswing.

Where are older agent frameworks most likely to break?

Look for rewritten history, dynamic top-level system prompts, changing tool lists, and Fable 5.1 thinking blocks passed to older models. Audit the conversation assembly layer before migration.

Final take

Fable 5.1 is not simply “a slightly smarter model.”

Anthropic changed capability, cache pricing, and conversation constraints together, with a clear target: workloads that involve dozens of tool calls, multiple applications, and hours of continuous work.

Developers should focus on three questions:

1. Does it improve completion rates on your hardest tasks?
2. Is your prompt and conversation structure stable enough to benefit from caching?
3. Does the additional output cost replace work that was previously uneconomical or impossible?

If the answer is yes, Fable 5.1 may be an important upgrade for high-value agents. For routine questions and mechanical transformations, a faster and cheaper model will usually remain the better choice.

Sources:

• Anthropic: Claude Fable 5.1 and Mythos 5.1
• Claude Platform: Fable 5.1 model overview
• Claude Platform: Prompt caching
• Claude Platform: Prompting Claude Fable 5.1
• Anthropic: Claude Fable product page
• CodeRabbit: Fable 5.1 model review