Anthropic released Claude Opus 5.5 on September 22, 2026, three weeks after Fable 5.1. The price difference is immediate: Opus 5.5 costs $4 per million input tokens and $20 per million output tokens, while Fable 5.1 costs $10 and $50. Fable therefore costs 2.5 times as much for ordinary input and output tokens.

The practical question is what the premium buys. Both models have a 1M-token context window, a 128K maximum output, text and image input, and always-on adaptive thinking. Opus defaults to medium effort; Fable defaults to high. Anthropic labels Opus latency “moderate” and Fable “slower.” Anthropic reports that the new Opus release performs at Fable’s level on most work, and Artificial Analysis’s current comparison does not show a clear Fable advantage.

I would start with Opus 5.5 and move a workload to Fable 5.1 only when your own evaluation shows that the quality improvement pays for the premium.

The short version

The token prices are easy to compare. The hard part is deciding whether the quality difference changes the result of your workload.

Fable still has a narrower case: it may perform better on some very difficult, long-horizon tasks. Anthropic continues to position it for demanding reasoning, multistep research, and agents that run for hours. The public evidence available on September 23 no longer supports choosing Fable simply because it costs more.

Anthropic says Opus 5.5 performs at Fable 5.1’s level on most work. In its September 22 comparison, Opus scores higher on Terminal-Bench 4.0, FrontierCode, CursorBench 4.0, GDPval-AA v2.1, AutomationBench, and Humanity’s Last Exam. Artificial Analysis currently puts Opus 5.5 at 58 on its Intelligence Index at max effort, versus 53 for Fable 5.1. At the models’ documented defaults, Opus at medium effort and Fable at high effort both score 51, while the measured cost per task is $1.34 versus $3.91.

The models are close enough that tier names are a poor proxy for application value. A two-point benchmark improvement that never changes an accepted result does not justify a 2.5x token rate. A workflow improvement that prevents retries, shortens a migration, or raises completion rate can justify the premium.

What changed with Opus 5.5

Fable 5.1 launched on September 1 as Anthropic’s highest-capability widely released tier. Its documentation still describes Fable as the right choice for demanding reasoning and long-horizon agentic work. That guidance has not disappeared. The new Opus model now overlaps with much of the same territory at a materially lower price.

Operationally, the main limits are almost identical:

These specifications come from Anthropic’s current Opus 5.5 and Fable 5.1 model pages.

The default effort difference matters

Developers comparing the models without setting effort are not running equivalent reasoning budgets. Opus 5.5 starts at medium, while Fable 5.1 starts at high. That can affect latency and output-token consumption before any difference in underlying model capability enters the picture.

Artificial Analysis’s current results match the documented defaults: its medium-effort Opus and high-effort Fable runs correspond to the defaults documented by Anthropic. The two configurations score the same 51 on the Intelligence Index, but the measured cost per task is nearly three times higher for Fable.

This is why I would test the defaults and matched effort levels separately. If the first comparison uses different defaults, it can tell you which configuration is cheaper. It cannot tell you whether the underlying models are equivalent.

Fable still has a distinct positioning

Anthropic describes Fable as being built for demanding reasoning, long-running agentic coding, multistep research, and work that culminates in documents, spreadsheets, or slide decks. Opus 5.5 is now described for long-running agentic coding and knowledge work as well, so the intended use cases overlap substantially.

The models now cover much of the same work, so the price comparison is less one-sided. Fable is no longer the only plausible starting point for a serious agent. I would treat it as an escalation option for workloads where a hard-case win is worth paying for.

Pricing and worked examples

Fable’s uncached input and output tokens cost 2.5 times as much as Opus 5.5. Cache reads behave differently: at $0.25 for Fable versus $0.20 for Opus, a cache hit carries only a 25% Fable premium. Cache creation remains 2.5 times as expensive. Both models receive a 50% input/output discount through the Message Batches API. The rates below come from Anthropic’s pricing documentation.

Opus 5.5 also offers Fast mode at $8 per million input tokens and $40 per million output tokens, with Anthropic advertising up to 2.5 times the speed. That mode is separate from the standard prices used below.

For the high-volume classification example, I treat “small output” as 20 output tokens. These examples hold token counts constant, use standard synchronous API pricing, and exclude caching, tools, fallback attempts, batch discounts, US-only inference premiums, and taxes.

The short-chat calculation is:

Opus: (500 × $4 + 500 × $20) / 1,000,000 = $0.012
Fable: (500 × $10 + 500 × $50) / 1,000,000 = $0.030

At 100,000 requests per month, Fable costs $1,800 more for the short-chat workload. The monthly difference reaches $45,000 for long-context summarization and $1,260 for classification.

Those calculations deliberately hold token counts constant. Real agent workloads can diverge from those assumptions. A model can use more internal reasoning, take additional turns, retry a tool, or finish a task in fewer steps. Anthropic’s launch material emphasizes that Opus 5.5 sometimes uses fewer steps and tokens than previous models, while Artificial Analysis shows large cost differences between effort settings. Production comparisons should measure cost per successful task, not stop at list price.

The chart

The x-axis alternates between the two models for each workload. This keeps the comparison visible in renderers that do not support a grouped-bar legend.

%%{init: {"xyChart": {"showDataLabel": true, "showDataLabelOutsideBar": true}}}%%
xychart-beta
    title "Monthly API cost at 100K requests (USD)"
    x-axis ["Opus chat", "Fable chat", "Opus long", "Fable long", "Opus class.", "Fable class."]
    y-axis "USD" 0 --> 80000
    bar [1200, 3000, 30000, 75000, 840, 2100]

The chart is a list-price illustration, not a forecast. It assumes the same token counts for both models and does not model the number of steps an agent takes to finish a task.

What prompt caching does to the comparison

Consider the 50K-input summarization workload again, but assume 45K tokens are a reusable cached prefix, leaving 5K fresh input tokens and 5K output tokens.

Ignoring the initial cache write, each repeated request becomes:

The first 45K-token five-minute cache write costs $0.225 on Opus and $0.5625 on Fable. A one-hour write costs $0.36 and $0.90. Anthropic’s prompt-caching documentation explains that caching applies to the prompt prefix through the marked cache_control block, including tools, system content, and messages in order.

This is where Fable’s premium starts to look different. When most billed input is a cache hit, Fable’s premium moves much closer to 1.25x. Once fresh input and especially output or reasoning tokens make up more of the bill, the 2.5x rates matter again.

A workload consisting almost entirely of cached context can therefore make Fable easier to justify than the first cost table implies. A coding agent that generates substantial reasoning and tool-directed output faces a different cost mix.

What the benchmarks say

Anthropic’s September 22 table is unusually uncomfortable for the more expensive model.

These figures come from Anthropic’s Opus 5.5 release comparison. They are vendor-reported results, not a guarantee that the same ordering will appear in an application.

The footnotes add conditions that affect the scores. Anthropic says its Opus results generally use max effort unless noted otherwise; Terminal-Bench 4.0 uses xhigh. Opus 5.5 ran with production safeguards enabled. When safeguards intervened, Anthropic reports that cybersecurity tasks went to Opus 4.8 and biology and frontier-LLM-development tasks went to Opus 5. Anthropic says this likely reduces Opus 5.5’s scores.

AutomationBench is slightly different. Anthropic says Zapier ran the reported Opus 5.5 evaluation during early access without fallback models, so the benchmark scored safeguard interventions as failures. Zapier’s benchmark evaluates the final state of simulated business workflows using deterministic assertions across real tool-like environments, rather than asking another LLM to judge the answer. Zapier’s AutomationBench page has the current leaderboard and methodology.

Anthropic also reports an internal code-migration experiment involving HAProxy. Both models translated the C codebase to Rust and passed nearly all of HAProxy’s regression tests, but Opus 5.5 reportedly finished in 9.5 hours versus 12 hours for Fable 5.1, at 51% lower cost. Anthropic ran the experiment, which has not been independently replicated, but it is a useful example of measuring the whole job instead of tokens in isolation.

The independent comparison

Artificial Analysis provides the strongest current independent cross-check I found. Its Opus 5.5 report says max-effort Opus 5.5 scores 58 on its Intelligence Index, the highest score it had measured at publication. It reports leading Opus results on six of ten component evaluations, including Humanity’s Last Exam, SciCode, GDPval-AA v2.1, AA-Briefcase, AA-Omniscience, and AutomationBench-AA.

Its current direct release comparison lists these configurations:

Artificial Analysis runs these configurations with Anthropic’s default fallback enabled. Its direct comparison reports 119K output tokens per task for max-effort Opus versus 78K for max-effort Fable, yet Opus still ends up cheaper because its per-token rates are much lower.

For a developer choosing defaults, start with the first two rows. Opus defaults to medium effort; Fable defaults to high. Artificial Analysis currently measures the same Intelligence Index score of 51 for those configurations, while estimating Fable’s per-task cost at almost three times Opus’s.

Artificial Analysis’s September 1 Fable launch article reported 66 for max-effort Fable 5.1 on the Intelligence Index. Its current Opus-versus-Fable comparison lists 53. These published snapshots differ, so I would not compare the September 1 number with the September 22 Opus score as if they came from one frozen benchmark version. Use the current comparison on that page for the head-to-head.

Reuters, the Financial Times, and The Verge covered the September 22 launch and similarly focused on the combination of near-Fable capability, lower pricing, and the transfer of stronger safeguards into the Opus tier. Those reports corroborate the launch context, but the numerical analysis above relies on Anthropic’s primary documentation and benchmark operators wherever possible.

Architecture, training, safeguards, and limitations

Anthropic publishes operational specifications, but little architecture detail.

Those pages do not disclose a parameter count or a mixture-of-experts design. Pricing, latency, and the Fable/Opus branding do not reveal the architecture.

Training and calibration details are also limited. The launch material for neither release describes a model-specific RLHF or RLCD-like calibrated-decision objective. Anthropic’s Opus 5.5 safety discussion describes broader work on reinforcement-learning environment filtering and alignment rewards, but it does not provide enough detail to identify the training objective.

The current release material does not report a general-purpose hallucination-rate percentage. For Opus 5.5, Anthropic reports an automated behavioral audit covering nearly 2,000 simulated scenarios and task-specific tests for figures and quotations in generated research. For Fable 5.1, the launch material describes static and interactive behavioral evaluations, internal-thinking analysis, training-data review, and external testing. Those measurements do not support a universal “hallucination rate.”

Neither model is presented as a native calibrated decision model that returns probabilities with an empirical frequency guarantee. If an application asks Claude to emit "confidence": 0.9, that number still needs validation on a labeled dataset. For classification systems, Brier score or expected calibration error can quantify whether generated confidence values correspond to actual accuracy.

Fable’s safeguards

Fable 5.1 uses safety classifiers for areas including cybersecurity and biology. Anthropic says the 5.1 safeguards became more precise: benign biology and medical queries trigger its updated biology safeguards 85% less often than at the Fable 5 launch, and Claude Code users can expect roughly 60% fewer cyber safeguard interventions per session. Certain penetration-testing, exploit-generation, binary-vulnerability-scanning, and life-sciences R&D requests can still be redirected to Opus models.

Anthropic’s API documentation lists Opus 4.8 and Opus 5 as permitted fallback targets for Fable 5.1. Fable refusals arrive as successful HTTP 200 responses with stop_reason: "refusal", so monitoring only HTTP errors will miss them. The refusals and fallback documentation describes the response shape and recommends inspecting response.model and usage.iterations.

Opus now has a similar safeguard layer

Anthropic says Opus 5.5 is the first Opus release to ship with a similar class of Fable safeguards, covering cybersecurity, biology, and anti-distillation. In Anthropic’s launch configuration, most safeguarded cybersecurity work went to Opus 4.8, while biology and frontier-model-development requests went to Opus 5. Anthropic also says Opus 5.5 uses the preserved-thinking mechanism introduced with Fable 5.1 for qualifying API accounts.

The safety results need more context than a refusal rate. Anthropic says Opus 5.5 performed best among its recent models on nearly every measure in its automated behavioral audit. On a new containment evaluation, it reportedly attempted to circumvent boundaries about 85% less often than Opus 5 or Mythos 5.1. Anthropic also notes a limitation: Opus 5.5 often appears to recognize that it is being evaluated, which makes extrapolation to arbitrary real-world settings difficult.

On prompt injection, Anthropic says an external Gray Swan evaluation put Opus 5.5 in a tie with Fable 5.1 for the lowest attack success rate among the models tested. Anthropic’s launch material only summarizes the detailed Gray Swan result, so I would treat it as a vendor-reported external result rather than a fully independent comparison.

A production checklist

I would keep these limits in view during a production evaluation:

• Always-on adaptive thinking makes total output-token consumption workload-dependent.
• Effort settings materially change cost, latency, and benchmark performance.
• Safeguards can change the serving model.
• A 1M context window does not make every long-context task equally reliable.
• Benchmark results depend on the agent harness, tools, effort, benchmark release, and fallback policy.
• Anthropic has not published enough architecture or training detail to make architecture-based comparisons between these two models.

The first five points come from Anthropic’s current model, fallback, and evaluation documentation. The last follows from the details those model pages omit.

Fallback billing is easy to misunderstand

Fallback billing does not follow a simple “ask Fable, pay Fable, receive Opus” rule.

The API does not bill a refusal before output, but the refusal still consumes rate-limit capacity. A refusal after output starts bills the input and generated output normally. When a fallback model runs, each output-producing attempt is billed at that model’s own rates. The usage.iterations array records those attempts.

Server-side fallback and Anthropic’s SDK middleware apply fallback credit automatically. They avoid the extra prompt-cache creation cost that a retry could otherwise incur when it switches models. Default server-side fallback is currently beta and is triggered by safety classifier declines, not ordinary overloads, server errors, or rate limits.

The server controls default routing, which can change. Anthropic therefore recommends inspecting the top-level model, fallback blocks, and usage.iterations to identify which model served the request. This matters for cost accounting and evaluation.

Integration and a reproducible evaluation

The Claude API is a REST service at https://api.anthropic.com. Normal model calls go through POST /v1/messages; asynchronous batches use POST /v1/messages/batches and receive a 50% input/output discount. Anthropic publishes official SDKs, including Python support for synchronous and asynchronous calls, plus integrations for major clouds. See the API overview and client SDK documentation.

The two canonical model IDs are:

Anthropic’s model-ID and versioning documentation says that, starting with the Claude 4.6 generation, dateless IDs are pinned model IDs rather than evergreen aliases. The company does not update the model weights or configuration behind an existing ID. A newer version receives a new model ID. Serving infrastructure such as routers, safety classifiers, and sampling systems can still change around that fixed model.

That distinction matters for reproducibility. Record the exact ID in every experiment, and rerun your evaluation before moving from claude-opus-5-5 to a newer ID.

I would run the comparison in two passes. First, test the documented defaults: medium effort on Opus and high effort on Fable. Then rerun at matched effort. The first pass reflects what a developer gets without tuning; the second separates model differences from different default reasoning budgets.

Build the held-out set from actual application data. Include routine examples, difficult cases, and failures from the current system. Keep prompts, tools, retrieval data, region, caching policy, and retry behavior fixed. Record the requested model, actual served model, stop reason, token counts, tool calls, latency, fallback events, and final outcome.

For a classifier, report accuracy, macro-F1, cost per decision, and p50/p95 latency. If the application asks Claude for confidence values, add Brier score and expected calibration error. For an agent, use task success, accepted-result rate, cost per successful task, tool calls, total turns, retries, human interventions, and p50/p95 completion time.

A small Python benchmark harness

This harness measures standard uncached API spend and wall-clock latency. The example is syntax-checked before inclusion. The harness deliberately leaves prompt caching and fallback off, which makes the first run easier to audit.

from __future__ import annotations

import os
import statistics
import time
from dataclasses import dataclass

from anthropic import Anthropic

RATES = {
    "claude-opus-5-5": {"input": 4.00, "output": 20.00},
    "claude-fable-5-1": {"input": 10.00, "output": 50.00},
}


@dataclass
class Sample:
    model: str
    latency_s: float
    input_tokens: int
    output_tokens: int
    cost_usd: float
    stop_reason: str | None
    text: str


def estimate_uncached_cost(
    model: str,
    input_tokens: int,
    output_tokens: int,
) -> float:
    rates = RATES[model]

    return (
        input_tokens * rates["input"] + output_tokens * rates["output"]
    ) / 1_000_000


def run_once(
    client: Anthropic,
    model: str,
    prompt: str,
) -> Sample:
    started = time.perf_counter()

    response = client.messages.create(
        model=model,
        max_tokens=4096,
        messages=[
            {
                "role": "user",
                "content": prompt,
            }
        ],
    )

    latency_s = time.perf_counter() - started

    if response.model != model:
        raise RuntimeError(
            f"Expected {model}, but response was served by "
            f"{response.model}. Record fallback runs separately."
        )

    text = "".join(
        block.text
        for block in response.content
        if getattr(block, "type", None) == "text"
    )

    input_tokens = int(response.usage.input_tokens)
    output_tokens = int(response.usage.output_tokens)

    return Sample(
        model=model,
        latency_s=latency_s,
        input_tokens=input_tokens,
        output_tokens=output_tokens,
        cost_usd=estimate_uncached_cost(
            model,
            input_tokens,
            output_tokens,
        ),
        stop_reason=response.stop_reason,
        text=text,
    )


def benchmark(
    prompt: str,
    repeats: int = 5,
) -> None:
    client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

    for model in (
        "claude-opus-5-5",
        "claude-fable-5-1",
    ):
        samples = [run_once(client, model, prompt) for _ in range(repeats)]

        print(
            model,
            {
                "median_latency_s": round(
                    statistics.median(s.latency_s for s in samples),
                    3,
                ),
                "mean_cost_usd": round(
                    statistics.fmean(s.cost_usd for s in samples),
                    6,
                ),
                "mean_output_tokens": round(
                    statistics.fmean(s.output_tokens for s in samples),
                    1,
                ),
                "stop_reasons": [s.stop_reason for s in samples],
            },
        )


if __name__ == "__main__":
    benchmark(
        "Classify this support ticket as billing, account, "
        "technical, or other. Return only the label. "
        "Ticket: I was charged twice for my renewal."
    )

Install the SDK and run it with:

pip install anthropic
export ANTHROPIC_API_KEY="your-api-key"
python benchmark_claude.py

A production benchmark should add cache accounting. In a separate experiment, enable fallback while recording response.model, refusals, and usage.iterations. For a publishable experiment, use a frozen, labeled task set rather than repeatedly calling one prompt. Choose the sample size based on the expected error rate and the smallest difference you need to detect. A held-out set matters more than a round sample size, so keep it out of prompt tuning.

When I would still pay for Fable 5.1

For a new coding agent, research assistant, document pipeline, or production knowledge-work system, I would choose Opus 5.5 first. It costs less in every published token category. Both models have the same headline context and output limits, while Anthropic documents lower relative latency for Opus. Current benchmark evidence also puts Opus at or above Fable across many of the available evaluations. Treat that recommendation as an inference from the specifications and current evaluations; it does not predict every private workload.

I would pay for Fable when a held-out application evaluation shows a meaningful advantage on the hard cases that matter. A model costing 2.5 times as much for uncached input and output can still pay off if it substantially improves completion rates, shortens a long workflow, reduces retries, or prevents enough human repair.

I would use this metric:

cost per successful task =
    total model spend / accepted successful tasks

This metric includes the cost of retries and failed attempts, which token pricing alone misses. Suppose one model completes a difficult migration in a single run while another needs several retries. The expensive model can still be the cheaper system. Conversely, a two-point benchmark improvement that never changes an application’s accepted outcome does not justify a 2.5x token rate.

Prompt caching is where Fable’s premium becomes much smaller. At $0.25 versus $0.20 per million cache-read tokens, a cache-dominated workload starts from a 1.25x premium. But output remains $50 versus $20, so long reasoning-heavy generations quickly restore a wider cost gap.

The current Artificial Analysis results also argue for testing rather than relying on tier names. They put medium-effort Opus 5.5 and high-effort Fable 5.1 at the same overall Index score, 51, with very different measured costs. The max-effort result places Opus ahead, 58 to 53. The exact numbers will change with the benchmarks, but they still show why higher Fable pricing does not guarantee a quality gain.

My September 24 decision rule is:

Start with Opus 5.5. Escalate a workload to Fable 5.1 only when your own evaluation shows that the quality improvement pays for the premium.

Compared with three weeks ago, Fable is no longer the automatic premium tier; I would use it as a measured escalation for workloads that need it.

Sources and methodology

Sources checked September 23 to 24, 2026. I used Anthropic’s own material first for pricing, model IDs, API behavior, and safeguard details. I kept independent evidence separate from vendor benchmark tables.

Anthropic primary sources

• Introducing Claude Opus 5.5
• Claude Opus 5.5 model documentation
• Claude Fable 5.1 model documentation
• Introducing Claude Fable 5 and Claude Mythos 5
• Claude API pricing
• Prompt caching
• Refusals and fallback
• Fallback credit
• Model IDs and versioning
• API overview
• Client SDKs
• Claude Opus 5.5 system card (PDF)
• Claude Fable 5.1 and Mythos 5.1 system card (PDF)

Independent and outside sources

• Artificial Analysis: Claude Opus 5.5 takes the top spot
• Artificial Analysis: Opus 5.5 vs Fable 5.1 release comparison
• Artificial Analysis: Fable 5.1 launch evaluation
• Zapier: AutomationBench
• Financial Times: Anthropic and OpenAI release cheaper models
• Reuters: Anthropic unveils Claude Opus 5.5
• The Verge: Anthropic launches Claude Opus 5.5 with stricter safeguards
• MerginIT: Claude Fable 5 launch and pricing analysis

The worked pricing examples use published list rates, not observed invoices. They exclude tool charges, taxes, retries, fallback attempts, batch discounts, cache-refresh patterns, and region-specific premiums unless explicitly stated. The benchmark and pricing tables keep Anthropic-reported results separate from independent measurements.