Claude Opus 5 Explained and How Close It Comes to Fable 5

Practical AI tools and prompt engineering  /  Analysis by the aitrendblend editorial team  /  25 July 2026  /  13 min read

• Claude Opus 5
• Claude Fable 5
• Effort parameter
• Cost per task
• Agentic coding
• Safety classifiers
• Model routing
• 1M context

The problem runs deeper than the sticker price

To understand why Opus 5 exists in the shape it does, you have to remember what Fable 5’s first eight weeks looked like. The model launched in June as the first widely released member of the new Mythos class. Days later Anthropic pulled it to comply with an export control directive, restored it on 1 July, and then spent most of the month adjusting how subscription plans paid for it. Underneath the policy drama sat a plainer complaint from paying developers. Fable 5 thought a lot, and thinking costs output tokens, and output tokens are billed at 50 dollars per million. Teams were finishing tasks and then flinching at the invoice.

So the pitch for Opus 5 is not really about the frontier. It is about the middle band of work where most professional value actually sits. Reviewing a pull request. Refactoring four files. Reading a messy workbook and producing a defensible summary. None of that needs a model that can run unattended for days. What it needs is a model that finishes the job on the first pass without burning a week of budget, and Anthropic has priced Opus 5 to make that trade obvious.

Which raises a distinction worth making early, because most launch coverage skipped it. Intelligence and usability are not the same quantity. A model can be the smartest available and still be the wrong tool if it spends too many tokens, waits too long before answering, or hands you a refusal because a safety classifier misread your request. Usability is closer to the probability that a real task reaches a usable result at an acceptable cost. Read that way, the Opus 5 story becomes much more interesting than a price cut.

What actually changed inside Opus 5

Start with the defaults, because defaults are what most integrations inherit without noticing. On Opus 4.8, a plain request ran without thinking unless you asked for adaptive thinking explicitly. On Opus 5 thinking is on out of the box, and the model decides for itself when and how deeply to think on each turn. The wire format did not change, so old code still validates, but the behaviour it produces did change. Since max_tokens caps thinking and visible response together, any workload that was tuned tightly around a small output ceiling needs revisiting before it starts truncating.

The second shift is the one Anthropic keeps circling back to. Effort matters more now. The full ladder runs low, medium, high, xhigh and max, and the documentation says the model converts extra effort into better answers more reliably than any earlier Opus. That claim cuts in two directions and both are useful. Turning effort up buys real quality on hard work rather than just longer thinking traces. Turning effort down loses less than you would expect, which is the whole basis of the cost argument. Anthropic reports that low and medium effort produce strong quality at a fraction of the tokens and latency of the higher settings.

The breaking change nobody will read about until it fails

Here is where a migration goes wrong quietly. On Opus 5, passing a disabled thinking flag is accepted only when effort sits at high or below. Combine disabled thinking with xhigh or max and the API returns a 400 error. On Opus 4.8 those two controls were independent, so any integration that pinned both settings for cost reasons now has a request that simply fails. The fix is a choice rather than a puzzle. Keep thinking off and cap effort at high, or keep the higher effort and delete the thinking field entirely.

There is also a soft warning attached. With thinking disabled, Opus 5 occasionally writes a tool call into its visible text instead of emitting a proper tool_use block, or leaks internal XML tags into the response. For anything agentic, that is a parser bug waiting to happen. The recommendation from the platform team is sensible. Leave thinking on and control spend with the effort dial instead.

Around those two behaviour changes sit four platform additions that matter more to production teams than to benchmark watchers. The context window is one million tokens, and that is both the default and the maximum, with no smaller variant to choose between. Maximum output is 128k tokens. The minimum cacheable prompt has dropped from 1,024 tokens to 512, which quietly makes caching viable for short system prompts that previously could not create a cache entry at all. Mid conversation tool changes, in beta behind the mid-conversation-tool-changes-2026-07-01 header, let you add or remove tools between turns without invalidating the prompt cache. Anyone who has rebuilt a whole session because a single tool definition changed will understand why that one earns its place.

The fourth addition is the most strategically revealing. The fallbacks parameter now supports a default mode that applies Anthropic’s own recommended fallback model per refusal category, rather than a list you maintain by hand. With fallbacks enabled, a request that trips a safety classifier routes to another model instead of returning a refusal. That is a reliability feature dressed as a safety feature, and it exists because refusal handling had become a genuine engineering burden on Fable 5.

Reading the benchmark claims without being sold to

Every number that follows comes from Anthropic’s own launch post for Claude Opus 5 or from a named early access customer. There is no independent replication yet, and for a model that is one day old there could not be. Treat the figures as a vendor’s honest best case and discount accordingly, which is what you would do reading any results table written by the people who built the system.

With that caveat placed, the shape of the results is unusual and worth attention. On Frontier-Bench v0.1, an internal run using the mini agent harness, Anthropic says Opus 5 surpasses every other model and more than doubles Opus 4.8 at a lower cost per task. On CursorBench 3.2 at max effort, the reported gap to Fable 5’s peak score is under half a percentage point, delivered at half the cost per task. On ARC-AGI 3, which tests novel problem solving rather than recall, the claim is a score three times the next best model. On OSWorld 2.0, a computer use benchmark, Anthropic says Opus 5 beats Fable 5’s best result at just over a third of the cost.

Notice what the table does not say. It does not say Opus 5 is smarter than Fable 5, and Anthropic does not say that either. What it says is that the two models now sit close enough together on a wide band of professional work that the price difference decides the matter for most teams. Anthropic still points to Fable 5 for the hardest and longest running projects, and to Mythos 5 for biology research and offensive cybersecurity work. That restraint is the most credible part of the announcement.

Claude Opus 5 delivers near Fable 5 intelligence at Opus speed and cost. Sualeh Asif, Cofounder, Cursor, in Anthropic’s launch post

Cost per task is the only unit that settles the argument

Token prices mislead because they measure the wrong thing. What a team pays for is a finished task, and a finished task may take one attempt or four. So write the cost of a single attempt in terms of the input and output prices and the tokens actually consumed.

Here \( p_{\text{in}} \) and \( p_{\text{out}} \) are the per token prices, \( T_{\text{in}} \) and \( T_{\text{out}} \) are the tokens a single attempt consumes, and \( s \) is the probability that an attempt produces something you can ship. The denominator is what people forget. A model that succeeds two thirds of the time is not two thirds as good as one that always succeeds. It is one and a half times as expensive per shipped result, before anyone counts the engineer waiting on it.

Now compare the two models. Opus 5 charges exactly half of Fable 5 on both directions of traffic, so let \( r \) be the ratio of tokens Opus 5 spends to tokens Fable 5 spends on the same work. Opus 5 is the cheaper route to a finished task whenever its cost per task is lower, which rearranges into a condition on success rates alone.

Read that carefully, because it is the practical heart of the launch. If Opus 5 burns the same tokens as Fable 5 on a task, then \( r \) equals one and Opus 5 wins whenever it succeeds more than half as often. That is an enormous margin, and the benchmarks suggest the real success gap is nowhere near that wide. Fable 5 only reclaims the economics when \( r \) grows, meaning Opus 5 needs many more tokens to reach the same place, or when the success ratio collapses on a class of work Opus 5 cannot handle at all. Both conditions describe the same territory. Very long, very hard, weakly specified projects.

Early access reports back this up with numbers from their own harnesses rather than Anthropic’s. Harvey, working on legal agent tasks, said Opus 5 matched Opus 4.8 at maximum reasoning while producing 26 percent fewer tokens on average. Fundamental Research Lab reported around 9 percentage points higher accuracy on hard financial modelling with a third fewer turns and tool calls and 60 percent less time. Box measured an 8 percent overall improvement over Opus 4.8, rising to 11 percent on data analysis and 17 percent on due diligence. These are self reported figures from partners with an interest in the launch, and they are still the closest thing to outside evidence available today.

The effort dial deserves a small optimisation of its own

If effort converts into quality more reliably now, then choosing an effort level is an optimisation rather than a habit. Write quality at a given effort as \( q(e) \) and cost at that effort as \( c(e) \), then pick the level that maximises value net of spend.

The weight \( \lambda \) is where teams differ from one another. A consumer product answering thousands of questions an hour sets it high and lives at low or medium effort. A firm using the model to draft contract redlines sets it near zero, because one missed clause costs more than a month of tokens. The reason this framing matters on Opus 5 specifically is that both ends of the ladder moved. The low end got more useful, and the high end got more responsive to being pushed.

The usability story hiding in the safeguards

This is the part of the announcement that deserves more attention than it received, and it has nothing to do with benchmarks. Fable 5 ships with safety classifiers that can decline a request and route it elsewhere. Anthropic has said those classifiers trigger in fewer than 5 percent of sessions, which sounds small until you are the person whose security research keeps landing in that 5 percent. For anyone doing legitimate work near the cyber or biology boundaries, an interruption is a usability failure even when the safety reasoning behind it is sound.

Opus 5 changes the shape of that friction. Its cyber classifiers are proportionally less restrictive than Fable 5’s. They permit vulnerability discovery in source code while blocking binary based scanning, penetration testing and exploit generation, and Anthropic expects them to intervene roughly 85 percent less often than Fable 5’s do. On the consumer surfaces and in Claude Code and Claude Cowork, flagged requests fall back to Opus 4.8 by default rather than failing. Biology requests that were blocked on Fable 5 now route to Opus 5 instead of Opus 4.8, which makes Opus 5 the most capable generally available model for scientific research on the current lineup.

Put that beside Equation 1 and the point sharpens. An interruption is a failed attempt. It pushes \( s \) down, which pushes cost per task up, and it does so on exactly the workloads where a specialist was already paying premium rates. A model that interrupts far less often is, in the only sense that matters to a working team, more usable, even where it is marginally less intelligent.

The alignment claim sits alongside this. Anthropic’s automated behavioural audit scored Opus 5 at 2.3 on overall misaligned behaviour, the lowest of its recent models, with lower rates of deceptive behaviour and less susceptibility to being talked into misuse than Opus 4.8, Sonnet 5 or Fable 5. Worth holding lightly. This is an automated audit designed and run by the model’s developer, and the field has no agreed external standard to check it against. The direction of travel is encouraging. The number itself is not independently meaningful yet.

Where Fable 5 is still the right answer

Anthropic did not retire the flagship, and the reasons are specific rather than promotional. Fable 5 remains the recommendation for projects a model runs largely by itself over long stretches, planning across stages, delegating to subagents and checking its own output for hours or days. Mythos 5, the trusted access sibling from Project Glasswing, stays ahead on biology research and on offensive cybersecurity. Opus 5 now comes close to Mythos 5 at finding software vulnerabilities but stays well behind it at turning those findings into working exploits, a gap Anthropic illustrates with its OSS-Fuzz evaluation and clearly wants to keep.

There is a subtler reason to keep Fable 5 in the toolbox. If Equation 2 is the deciding rule, then the models you want are the ones whose failure modes differ. When a task defeats Opus 5 twice, escalating to Fable 5 is often cheaper than a third Opus attempt, because the second model brings different behaviour rather than more of the same. A tiered pipeline reads clumsy on an architecture diagram and works well on a bill.

An honest look at the limitations

Four things about this launch should keep a careful reader cautious.

The evidence is one sided. Every headline figure originates with Anthropic, on internal runs of Frontier-Bench v0.1 and its own configurations of CursorBench 3.2, ARC-AGI 3, GDPval-AA, OSWorld 2.0 and AutomationBench. The customer quotes are more useful than marketing copy because they are specific, but they come from partners given early access. Nothing here has survived a hostile replication yet.

Cost per task depends on your harness, not on the model alone. A poorly cached prompt, a retry loop with no ceiling, or a tool that returns 40,000 tokens of noise will erase the pricing advantage without the model doing anything wrong. The 512 token cache minimum helps, but only if caching is switched on and the prompt is stable enough to hit, which is a separate discipline of its own.

Some behaviour changes cut against tidy output. Anthropic notes that default responses and written deliverables run longer than on earlier Opus models, that the model narrates progress more often in agentic sessions, and that it delegates to subagents more readily. It also verifies its own work unprompted, which means verification instructions carried over from older prompts now cause over verification. Teams that spent months tuning terse prompts have some unlearning to do, and the prompting guide is explicit that lowering effort reduces thinking rather than output length. If you want short answers, ask for short answers.

Finally, the pricing landscape is not stable. Fable 5’s subscription treatment has already shifted several times since June, Sonnet 5 carries introductory rates that expire at the end of August, and Fast mode for Opus 5 is priced at Fable 5 rates while running about two and a half times faster. Any cost model built this week should be treated as a snapshot rather than a plan.

Putting the comparison to work

The useful response to a launch like this is not to switch everything, and not to wait for consensus either. It is to measure. The script below is a small evaluation harness that sweeps the effort ladder on a fixed task set, records tokens and outcomes, and reports cost per completed task for each model and effort combination using published prices. It runs offline against a fake client so you can read the accounting logic before spending anything, and it computes the crossover ratio from Equation 2 so you can see how much success rate you are allowed to lose before the cheaper model stops being cheaper.

"""
opus5_effort_sweep.py

A small, self-contained harness for deciding between Claude Opus 5 and
Claude Fable 5 on YOUR tasks rather than on a vendor benchmark.

What it does
  1. Runs a fixed task set across models and effort levels.
  2. Records input tokens, output tokens and a pass/fail judgement.
  3. Reports cost per COMPLETED task using published API prices.
  4. Reports the Equation 2 crossover: how much success rate Opus 5 may
     lose relative to Fable 5 before it stops being the cheaper route.

Run offline first:   python opus5_effort_sweep.py
Run for real:        export ANTHROPIC_API_KEY=...  &&  python opus5_effort_sweep.py --live

Prices are USD per million tokens and are hard-coded from Anthropic's
published pricing page. Verify them before trusting any output.
"""

from __future__ import annotations

import argparse
import os
import random
from dataclasses import dataclass, field
from typing import Callable, Iterable


# --------------------------------------------------------------------------
# 1. Pricing table (USD per million tokens)
# --------------------------------------------------------------------------

@dataclass(frozen=True)
class Price:
    """Per-million-token prices for one model."""
    inp: float
    out: float

    def attempt_cost(self, in_tok: int, out_tok: int) -> float:
        """Cost of a single attempt in USD."""
        return (self.inp * in_tok + self.out * out_tok) / 1_000_000


PRICES: dict[str, Price] = {
    "claude-opus-5":   Price(inp=5.0,  out=25.0),
    "claude-opus-4-8": Price(inp=5.0,  out=25.0),
    "claude-fable-5":  Price(inp=10.0, out=50.0),
}

# Opus 5 accepts the full ladder. Disabling thinking at xhigh or max is a 400.
EFFORT_LADDER = ("low", "medium", "high", "xhigh", "max")


# --------------------------------------------------------------------------
# 2. Result accounting
# --------------------------------------------------------------------------

@dataclass
class Attempt:
    model: str
    effort: str
    in_tok: int
    out_tok: int
    passed: bool
    refused: bool = False   # a classifier refusal is a failed attempt, not a free one


@dataclass
class Cell:
    """Aggregated results for one model and effort combination."""
    model: str
    effort: str
    attempts: list[Attempt] = field(default_factory=list)

    @property
    def success_rate(self) -> float:
        if not self.attempts:
            return 0.0
        return sum(a.passed for a in self.attempts) / len(self.attempts)

    @property
    def mean_attempt_cost(self) -> float:
        p = PRICES[self.model]
        if not self.attempts:
            return 0.0
        total = sum(p.attempt_cost(a.in_tok, a.out_tok) for a in self.attempts)
        return total / len(self.attempts)

    @property
    def cost_per_completed_task(self) -> float:
        """Equation 1. Infinite when nothing ever passes."""
        s = self.success_rate
        return float("inf") if s == 0 else self.mean_attempt_cost / s

    @property
    def mean_out_tok(self) -> float:
        if not self.attempts:
            return 0.0
        return sum(a.out_tok for a in self.attempts) / len(self.attempts)


def crossover_success_ratio(token_ratio: float, price_ratio: float = 0.5) -> float:
    """Equation 2.

    Returns the minimum s_opus / s_fable at which Opus 5 remains the cheaper
    route to a finished task. token_ratio is Opus 5 tokens divided by Fable 5
    tokens on the same work. price_ratio is 0.5 because Opus 5 lists at half
    of Fable 5 on both input and output.
    """
    return price_ratio * token_ratio


# --------------------------------------------------------------------------
# 3. Model callers. The fake one runs offline so the logic is inspectable.
# --------------------------------------------------------------------------

def make_fake_caller(seed: int = 7) -> Callable:
    """Deterministic dummy client for the smoke test.

    Higher effort spends more output tokens and passes more often, which is
    the qualitative pattern Anthropic reports. The numbers are invented for
    the smoke test only and mean nothing about real model quality.
    """
    rng = random.Random(seed)
    quality = {"low": 0.55, "medium": 0.68, "high": 0.80, "xhigh": 0.85, "max": 0.88}
    burn = {"low": 900, "medium": 1800, "high": 3600, "xhigh": 6400, "max": 9800}

    def call(model: str, effort: str, prompt: str) -> Attempt:
        # Fable 5 is modelled as slightly stronger and markedly more talkative.
        bonus = 0.04 if model == "claude-fable-5" else 0.0
        talk = 1.45 if model == "claude-fable-5" else 1.0
        refused = model == "claude-fable-5" and rng.random() < 0.05
        passed = (not refused) and rng.random() < min(0.99, quality[effort] + bonus)
        return Attempt(
            model=model,
            effort=effort,
            in_tok=len(prompt.split()) * 4 + 1200,
            out_tok=int(burn[effort] * talk),
            passed=passed,
            refused=refused,
        )

    return call


def make_live_caller(judge: Callable[[str], bool]) -> Callable:
    """Real Anthropic caller. Requires the anthropic SDK and an API key.

    Notes that matter on Opus 5.
      * Thinking is on by default, so no thinking field is passed here.
      * Effort is set through output_config.
      * max_tokens covers thinking plus visible output, so keep it generous
        at xhigh and max or the response will truncate mid-task.
      * `judge` is YOUR pass/fail check. A benchmark is only as honest as it.
    """
    import anthropic  # imported lazily so the offline smoke test needs no SDK

    client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

    def call(model: str, effort: str, prompt: str) -> Attempt:
        msg = client.messages.create(
            model=model,
            max_tokens=32000,
            output_config={"effort": effort},
            messages=[{"role": "user", "content": prompt}],
        )
        text = "".join(b.text for b in msg.content if getattr(b, "type", None) == "text")
        refused = msg.stop_reason == "refusal"
        return Attempt(
            model=model,
            effort=effort,
            in_tok=msg.usage.input_tokens,
            out_tok=msg.usage.output_tokens,
            passed=(not refused) and judge(text),
            refused=refused,
        )

    return call


# --------------------------------------------------------------------------
# 4. The sweep
# --------------------------------------------------------------------------

def sweep(
    caller: Callable,
    tasks: Iterable[str],
    models: Iterable[str] = ("claude-opus-5", "claude-fable-5"),
    efforts: Iterable[str] = EFFORT_LADDER,
    repeats: int = 3,
) -> dict[tuple[str, str], Cell]:
    """Run every task at every effort level, repeats times, and aggregate."""
    tasks = list(tasks)
    grid: dict[tuple[str, str], Cell] = {}
    for model in models:
        for effort in efforts:
            cell = Cell(model=model, effort=effort)
            for _ in range(repeats):
                for task in tasks:
                    cell.attempts.append(caller(model, effort, task))
            grid[(model, effort)] = cell
    return grid


def report(grid: dict[tuple[str, str], Cell]) -> None:
    """Print the table people actually need, sorted by cost per finished task."""
    header = f"{'model':<18}{'effort':<9}{'pass':>7}{'refuse':>8}{'out tok':>10}{'USD/attempt':>14}{'USD/finished':>15}"
    print(header)
    print("-" * len(header))
    for (model, effort), cell in sorted(grid.items(), key=lambda kv: kv[1].cost_per_completed_task):
        refusals = sum(a.refused for a in cell.attempts) / max(1, len(cell.attempts))
        print(
            f"{model:<18}{effort:<9}{cell.success_rate:>7.2f}{refusals:>8.2f}"
            f"{cell.mean_out_tok:>10.0f}{cell.mean_attempt_cost:>14.4f}"
            f"{cell.cost_per_completed_task:>15.4f}"
        )

    # Equation 2 at matched effort, using measured token burn rather than a guess.
    print()
    for effort in EFFORT_LADDER:
        o, f = grid.get(("claude-opus-5", effort)), grid.get(("claude-fable-5", effort))
        if not (o and f and f.mean_attempt_cost):
            continue
        token_ratio = o.mean_attempt_cost / (f.mean_attempt_cost * 0.5)
        need = crossover_success_ratio(token_ratio)
        actual = o.success_rate / f.success_rate if f.success_rate else float("inf")
        verdict = "opus 5 cheaper" if actual > need else "fable 5 cheaper"
        print(f"effort {effort:<7} needs s_opus/s_fable > {need:.3f}, measured {actual:.3f} -> {verdict}")


# --------------------------------------------------------------------------
# 5. Smoke test on dummy data
# --------------------------------------------------------------------------

DUMMY_TASKS = [
    "Refactor the payment retry logic and keep the public interface stable.",
    "Find the root cause of the flaky integration test in the billing module.",
    "Turn this account health workbook into a churn prevention sequence.",
]


def main() -> None:
    ap = argparse.ArgumentParser(description="Cost per finished task sweep")
    ap.add_argument("--live", action="store_true", help="call the real API")
    ap.add_argument("--repeats", type=int, default=3)
    args = ap.parse_args()

    if args.live:
        # Replace this judge with a real check. Compile it, run the tests, diff it.
        caller = make_live_caller(judge=lambda text: len(text) > 200)
    else:
        print("[offline] using the deterministic fake client, numbers are illustrative\n")
        caller = make_fake_caller()

    grid = sweep(caller, DUMMY_TASKS, repeats=args.repeats)
    report(grid)

    # Sanity checks so a broken edit fails loudly rather than silently.
    assert PRICES["claude-fable-5"].out == 2 * PRICES["claude-opus-5"].out
    assert abs(crossover_success_ratio(1.0) - 0.5) < 1e-9
    assert all(c.cost_per_completed_task >= c.mean_attempt_cost for c in grid.values())
    print("\n[ok] smoke test passed")


if __name__ == "__main__":
    main()

Two design choices in that script carry the argument of this article. Refusals are counted as failed attempts rather than free ones, because a refusal costs a developer a round trip whatever its justification. And the crossover ratio is computed from measured token burn instead of assumed parity, since token burn is the variable that actually decides the outcome once prices are fixed.

What this launch tells us about the next twelve months

Opus 5 is the clearest signal yet that the frontier and the useful model have separated into two products with different jobs. For two years the top of each vendor’s lineup was also the model most people should reach for. That is no longer true. Anthropic now sells a Mythos class for problems that need days of autonomous work, an Opus class tuned for daily professional throughput, and a Sonnet class for volume. The pricing makes the intended sorting obvious, and the effort ladder pushes that sorting inside a single model as well.

The conceptual shift underneath is about where quality comes from. Opus 5’s most repeated behavioural change is not a benchmark number, it is that the model checks its own work without being asked, catches its own planning mistakes before writing code, and pushes back when a user proposes something flawed. Several early access reports converge on that same observation. If it holds up outside the launch post, then the improvement people will actually feel is a reduction in supervision cost rather than an increase in peak intelligence, and supervision is the expense that has kept agents out of production more than raw capability ever did.

That reframing travels well beyond Anthropic’s lineup. Any team evaluating models should be measuring cost per completed task, refusal and interruption rate, and variance between runs, not headline benchmark scores, which is the thread running through the rest of our practical AI tools coverage. Lovable’s comment about lower run to run variance is arguably more valuable than any accuracy figure in the launch post, because unpredictability is what forces a human to review everything. A model that is slightly less capable but far steadier is the better production choice almost every time.

What remains unresolved is whether the closeness claim survives contact with hostile testing. Internal harnesses reward the models their builders tuned against, and a benchmark suite that Anthropic selected is a suite Anthropic knows well. The independent evaluations will arrive over the coming weeks, and some of them will probably find task families where Fable 5’s advantage is much larger than half a percentage point. Long, weakly specified, multi day projects are the obvious candidates, which is precisely where Anthropic has already conceded the ground.

For now the practical advice is unglamorous and firm. Move your daily workloads to Opus 5, keep effort at high until your own evaluations tell you otherwise, switch fallbacks on so a classifier hit degrades rather than fails, and keep Fable 5 configured as the escalation path for the small number of tasks that defeat the cheaper model twice. Then measure your own cost per finished task, because that number is the only benchmark that ever appears on your invoice.

Frequently asked questions

Sources. Anthropic, Introducing Claude Opus 5, 24 July 2026, including the alignment audit figure, the safeguards discussion and the early access customer statements. Anthropic Claude Platform Docs, What’s new in Claude Opus 5, for the API behaviour changes, the effort ladder, the cache minimum and pricing. Anthropic, Claude Fable, for Fable 5 pricing. Anthropic, statement on Fable and Mythos access, for the June suspension and the 1 July restoration. Equations 1, 2 and 3 are this publication’s own derivation from those published prices and are not taken from any vendor document. This analysis is based on the published sources and an independent evaluation of their claims.

Related Reading