Opus 5.5, Fable 5.1 and Looped Transformers

The news, and what is known

On 22 September 2026 Anthropic released Claude Opus 5.5 and said it “performs at the level of Claude Fable 5.1 on most work”. Fable 5.1, released three weeks earlier, charges $10 per million input tokens; Opus 5.5 charges $4. So a model that costs 60% less per token is claimed to keep up with the flagship. How can a cheaper model do that?

What was actually announced?

Both models are sold through the same API, with the same 1M-token context window and 128K-token output limit, and both think before they answer (adaptive thinking is always on). The differences Anthropic does publish are price, speed and how hard each model thinks by default.

Anthropic also says Opus 5.5 “requires less compute to serve than Opus 5, and its pricing reflects that”, and that it generates output more than 30% faster than Opus 5. Fable 5.1 and Claude Mythos 5.1 are the same model: Mythos is offered only to participants in Anthropic's Project Glasswing, with different safeguards. TechCrunch described Fable as “the larger Fable model”; Anthropic itself lists Fable as slower and more expensive, but gives no size.

What does “40% cheaper” mean?

The announcement says Opus 5.5 “costs 40% less to run than Opus 5”. The price list says something smaller: $5 → $4 for input and $25 → $20 for output, a 20% cut per token. Both can be true because the bill for a task is tokens used × price per token, and a model that reaches the answer in fewer tokens costs less even at the same price. One tester quoted in the announcement, GitHub's Mario Rodriguez, says it “solved more terminal tasks than Opus 5 in less than half the steps”.

Illustrative arithmetic only. Anthropic does not publish this breakdown; it simply shows how a 20% price cut and a 40% cost cut fit together.

Some headlines turned this into “a 40% lower price”. It is not: the price is 20% lower, and the rest depends on your workload.

How close is “at the level of”?

In Anthropic's own table, Opus 5.5 scores above Fable 5.1 on most of the listed benchmarks. Read those numbers with three caveats. They are reported by the company selling the model. The Opus 5.5 results use adaptive thinking at maximum effort (xhigh on Terminal-Bench), so they show the model at its most expensive setting, not at the cheaper default. And Anthropic itself warns that “at these levels of capability we've found that benchmark margins have become a less reliable guide” to real-world differences.

Key takeaways

• Opus 5.5 costs $4 / $20 per million tokens against Fable 5.1’s $10 / $50, and Anthropic says it performs at Fable’s level on most work.
• The “40% cheaper to run than Opus 5” claim combines a 20% lower price with fewer tokens per task; it is not a 40% price cut.
• Neither model’s architecture is public. Looping is a plausible guess, not a fact, and other explanations fit the evidence just as well.

Size versus compute

Roughly, how well a model handles a hard problem depends on two things: how much it has learned, stored in its parameters, and how much computation it spends on this particular problem. You can buy more of either, and they cost you in different ways.

What are the dials?

Parameters. A bigger network can store more facts and more refined skills. The price is paid on every token: generating one token takes about two arithmetic operations per parameter, and all of those parameters have to be read from memory.

Computation per parameter. A fixed network can be made to work harder. Reasoning models do this by writing out thousands of thinking tokens before answering, each one another full pass through the network (the reasoning models section of the LLMs lesson covers how they are trained). A looped model does it inside a single token, by running the same layers several times.

How can a smaller model match a larger one?

There are several well-understood routes, and a real model probably combines some of them:

• Distillation. Train the small model to imitate a large one's outputs, so it inherits skills it could not easily learn from raw text (Hinton et al., 2015).
• Better data and training. Cleaner data, more reinforcement learning on checkable tasks, and a later generation of recipes can move a model more than extra size does. See the fine-tuning lesson.
• Mixture of experts. Store many parameters but use only a fraction of them for each token, so the arithmetic per token is small.
• Lower precision. Store weights in 8 bits or fewer instead of 16, halving the memory to read. Try it in the Model Compression Lab.
• Serving engineering. Larger batches, prompt caching and faster kernels reduce the cost of the same model.
• Thinking harder at the right moments. Spend compute on hard steps, either as thinking tokens or as extra loops.

Why does the choice matter?

Because each dial loads a different part of the hardware. Parameters cost memory: capacity to hold them and bandwidth to stream them. Thinking tokens cost time: each one is a sequential step the user waits for. Loops cost arithmetic, and because each loop reads the shared weights again, they also cost memory reads; what they save is the memory needed to hold the model. Which one is cheapest depends on where the serving system is bottlenecked, and that is what the next section lets you calculate.

Key takeaways

• Quality comes from what a model has learned (parameters) and how much computation it spends per problem.
• Thinking tokens and looped layers both add computation without adding parameters; one writes text, the other works in hidden state.
• Distillation, better training, mixture of experts, quantization and serving tricks are equally valid ways a cheaper model can catch up.

What serving a model costs

A price per million tokens is, underneath, a price for GPU time. To see why looping could make a model cheaper, you need to know what a GPU spends its time on when it generates text.

What does generating a token cost?

Each new token needs one forward pass through the network. That pass has two costs. The GPU must read every weight from its memory into its compute units, and it must do about two floating-point operations per parameter used (one multiply, one add). It also reads the KV cache, the stored keys and values of every earlier token in the conversation, which grows with context length.

How does batching change the picture?

A server generates tokens for many users at once. The weights are read once per step and shared by the whole batch, but the arithmetic is repeated for every user. So with a small batch the GPU mostly waits for memory (memory-bound), and with a large batch it mostly waits for its own arithmetic (compute-bound). Pope et al. (2022) analyse this trade-off for large transformers in detail.

Time for one decoding step, ignoring the KV cache. The larger of the two terms wins.

A worked example: a 250-billion-parameter model stored at one byte per parameter must stream 250 GB for every step. Spread across GPUs with a combined 30 TB/s of bandwidth, that is about 8 ms per step, and it is the same 8 ms whether the batch holds one conversation or fifty. That is why the parameters used per token matter so much, and why it is worth asking exactly what a model that reuses its weights saves.

At small batches everything is memory-bound, and the looped model saves much less than its quarter-size weights suggest. Its core is far too large for the GPU's on-chip memory, so every loop streams the core's weights from GPU memory again. With four loops it reads 700B parameters' worth of weights per step, and its cost is about 0.7× the big model's, the same as a dense model of that effective depth. It is also slower per token, because it runs on half as many GPUs.

The saving shows up when memory capacity runs out. Every conversation in a batch needs its own KV cache, and a model with a quarter of the stored weights has much more memory left for it. At 32K tokens of context, one server holds the looped model plus about 200 conversations, while the big model fills two servers and still fits fewer than 100. Raise the demand past that and the looped model's cost per task drops to about 0.4× the big model's: larger batches share each read of the weights among more users. Switch to 4K contexts and a batch of 1,024 and the GPUs become compute-bound instead; now cost follows arithmetic, which grows with every loop, so at eight loops the looped model costs more than the big one. The “thinks longer” model is often cheap per task but makes the user wait: its thinking tokens are sequential steps.

Why does this matter for the news?

Real serving sits between the extremes: batches are limited by how much KV cache fits in memory, so large models are often memory-bound in practice. Changes that shrink the weights read per token, such as fewer parameters, lower precision or mixture of experts, lower the cost of every token. Shared looped layers work differently: they do not cut the bytes read per token, but they free memory for bigger batches, which lowers the cost per token when capacity is the limit. Any of these is consistent with Anthropic's statement that Opus 5.5 needs less compute to serve, but that statement does not tell you which, if any, Anthropic used; it has not disclosed the architecture.

Key takeaways

• Each token costs a read of every weight plus about two operations per parameter used; the KV cache adds more reading as context grows.
• Small batches are memory-bound, large batches compute-bound: stored parameters dominate the first, arithmetic the second.
• A looped model re-reads its core on every loop, so per token it reads and computes about as much as a dense model of equal depth; its saving is memory capacity, which allows bigger batches.

Looped transformers

An ordinary transformer runs layer 1, then layer 2, up to layer L, each with its own weights. A looped transformer runs the same block of layers again and again, feeding its output back in as input.

What is a looped transformer?

The idea is older than the current hype. Universal Transformers (2018) applied one shared block repeatedly and let each position decide when to stop. ALBERT (2019) shared parameters across all layers of a BERT-style model to make it much smaller. Yang et al. (2023) found that a looped transformer matched a standard one on in-context learning tasks with less than 10% of the parameters, and Saunshi et al. (2025) showed that a k-layer transformer looped L times nearly matches a kL-layer model on reasoning tasks.

The largest public language model built this way is Huginn (Geiping et al., 2025): 3.5 billion parameters trained on 800 billion tokens, with a prelude that embeds the input, a recurrent core that is looped, and a coda that produces the output. Given more loops at test time its reasoning scores improve, in the authors' words, “up to a computation load equivalent to 50 billion parameters”. The input is re-injected into the core at every loop, so the model cannot forget the question while it thinks.

How does looping help a model think?

Each pass through the core refines the hidden state, the vectors that carry the model's working memory for each token. Some problems need a chain of small steps: follow a path, carry a digit, apply a rule, check a constraint. A fixed-depth network can take only as many steps as it has layers. A looped network can take as many as it has loops, with the same weights doing each step. It is like a chain of thought that never gets written out as text, which is why this is often called latent reasoning.

The demo below makes that concrete. The task is to decide whether the goal in a random maze can be reached from the start. That needs information to travel along the path one cell at a time, so it genuinely requires iteration. The model is a single block with four weights, applied to every cell at once and looped.

Untrained, the block knows nothing and the accuracy sits at 50%, a coin flip. After training it has learned a local rule: “light up if a neighbour is lit”. That is one step of breadth-first search. The rule was trained with only 8 loops, but because it is local and repeatable it keeps working when you run it 40 or 60 times, solving paths far longer than anything it was trained on. Accuracy climbs as loops pass the typical path length of 26 to 48 steps. The parameter count stays at four the whole time. A standard network would need a separate layer for each step, so 40 layers and 160 weights to reach the same depth.

Real looped language models are far messier, but this is the core bet: some capability comes from applying a good rule many times, and that kind of capability can be bought with loops instead of parameters.

Why could this make a model cheaper?

A looped model stores fewer weights, so it needs fewer GPUs per copy and leaves more memory for KV cache, which lets a server batch more conversations together. It does not read fewer bytes or do less arithmetic per token than a dense model of the same effective depth: each loop reads the core again. The saving is in capacity, as the serving calculator showed. And because the number of loops is a dial, the model can in principle spend little effort on easy tokens and a lot on hard ones, without writing out thousands of thinking tokens. Whether a frontier lab has shipped a model built like this is not public.

Key takeaways

• A looped (recurrent-depth) transformer reuses one block many times: prelude, a core looped r times, then a coda.
• Published work from Universal Transformers to Huginn shows looping can trade parameters for compute, especially on reasoning tasks.
• Loops let a model think in hidden state; in the maze demo four shared weights solve paths of any length given enough loops.

Trade-offs and open questions

Looping is not a free lunch. It moves cost around, and several of its problems are still open research.

What does looping cost?

The arithmetic is still there

A model looped four times does roughly the arithmetic of a model four times as deep, and at small batches it reads the looped weights four times too. It saves memory capacity and model size, not floating-point operations or memory traffic per token. When serving is compute-bound, a looped model is no cheaper than the deep model it imitates.

Loops are sequential

Loop 3 cannot start until loop 2 has finished, so every extra loop adds to the time for each token. Wider layers can be split across GPUs; extra depth cannot. A looped model that thinks hard may be cheap to serve and still feel slow.

Less room for knowledge

Parameters are where facts are stored. Saunshi et al. found that looping helps reasoning much more than memorisation, so a looped model with few weights may reason well and still know less. That is one reason a larger model can remain better on knowledge-heavy work.

What is still unsolved?

Training stability. Backpropagating through many loops is expensive, and a loop that slightly amplifies its input can blow up after dozens of repetitions. Proposals such as OpenMythos constrain the loop mathematically so it cannot amplify, which shows how central the problem is.

When to stop. The appeal is to loop more on hard tokens. Adaptive computation time (Graves, 2016) lets a network learn how many steps to take, and early-exit methods stop a token once an intermediate prediction is confident. In a batched server, though, tokens that stop early leave hardware idle while others keep looping.

Reading the reasoning. A written chain of thought can be inspected, even if imperfectly. Reasoning in hidden state cannot be read at all without interpretability tools, which matters for debugging and for safety.

Why does this matter when you read the news?

Every architectural claim trades one cost for another. When you see “cheaper and just as good”, ask: cheaper in memory, in arithmetic or in tokens? As good on which tasks, and at which effort setting? Those questions are answerable from published facts even when the architecture is secret.

Key takeaways

• Looping saves stored weights, not arithmetic, and each loop adds latency because loops run one after another.
• Fewer parameters leave less room for knowledge; looping helps reasoning more than memorisation.
• Stable training, deciding when to stop, and inspecting latent reasoning are open problems.

Opus 5.5 or Fable 5.1?

Whatever is inside these models, the practical question is which one to call. Anthropic's documentation gives a clear default.

What does Anthropic recommend?

The Fable 5.1 overview says: for most workloads, start with an Opus model, and use Fable 5.1 for demanding reasoning and long-horizon agentic work, or when your evaluations on Opus at higher effort still fall short. Opus 5.5 now fills that Opus slot at a lower price.

1. 1Start on the Opus-class modelAnthropic’s Fable docs say to start most workloads on an Opus model. Opus 5.5 at its default medium effort is the cheap, moderate-latency baseline.
2. 2Build an eval before switchingCollect 20 to 50 real examples with a way to score them. Without that, “better” is a feeling. The evaluation lesson covers how.
3. 3Raise effort before changing modelThe effort parameter (low to max) controls how much the model thinks. It is the thinking-token dial from this lesson, and it is cheaper to try than a bigger model.
4. 4Move to Fable 5.1 when evals still fall shortAnthropic recommends Fable for demanding reasoning and long-horizon agentic work, or when an Opus model at higher effort is not enough. Expect 2.5× the per-token price and slower answers.

How much does the choice cost?

A worked example with published list prices: a task with 20,000 input tokens and 5,000 output tokens (thinking counts as output) costs 20,000 × $4/M + 5,000 × $20/M = $0.18 on Opus 5.5 and 20,000 × $10/M + 5,000 × $50/M = $0.45 on Fable 5.1. Fable also defaults to high effort rather than medium, so in practice it will usually think longer on the same task and the gap widens. Prompt caching changes the input side dramatically: cache reads cost $0.20 and $0.25 per million.

Why not just always use the best model?

For a single hard question, the price difference hardly matters. For an agent that makes hundreds of calls, or a product that serves thousands of users, a 2.5× price and slower replies compound. Most gains in practice come from clearer prompts, better context and better tools, which apply to both models.

Key takeaways

• Anthropic’s guidance: start on an Opus-class model, and move to Fable 5.1 for demanding long-horizon work when evals show you need it.
• Try higher effort before a bigger model; effort is the thinking-token dial and is cheaper to test.
• Per-token price is only half the bill: tokens per task, caching and batch discounts decide what you actually pay.

Check your understanding

Six scenarios, from reading a launch announcement to choosing a model for a real workload.

A colleague reads “Opus 5.5 costs 40% less to run than Opus 5” and budgets for a 40% cut on every API call. Their workload is a fixed-length summarisation job where token counts barely change between models. What should they expect?

References

Facts about Opus 5.5 and Fable 5.1 come from Anthropic's announcement and documentation as of 25 September 2026. The looped-transformer material comes from peer-reviewed papers and preprints. OpenMythos is listed as the source of the speculation, not as evidence for it.

Sources

1. [1]

   Introducing Claude Opus 5.5(opens in a new tab)

   Anthropic, 2026

   Launch announcement (22 September 2026): performs “at the level of Claude Fable 5.1 on most work”, “costs 40% less to run than Opus 5”, $4 / $20 per million tokens, benchmark table and caveats.

2. [2]

   OpenMythos(opens in a new tab)

   Gomez, K., 2026

   Community GitHub project (started April 2026) describing itself as “a theoretical reconstruction of the Claude Mythos architecture”, not affiliated with Anthropic. Proposes a prelude, a looped recurrent block and a coda.

3. [3]

   What’s new in Claude Opus 5.5(opens in a new tab)

   Anthropic, 2026

   Developer documentation: pricing, always-on adaptive thinking, default effort medium, and behaviour differences from Opus 5.

4. [4]

   Claude Fable 5.1: model overview(opens in a new tab)

   Anthropic, 2026

   Specifications and pricing for Fable 5.1 (released 1 September 2026), a comparison table with Opus 5.5, guidance on when to use it, and its relation to Claude Mythos 5.1.

5. [5]

   Anthropic releases Opus 5.5 with lower prices and Fable-level performance(opens in a new tab)

   TechCrunch, 2026

   News coverage of the launch, describing Fable as “the larger Fable model”. Contains no architecture details.

6. [6]

   Distilling the Knowledge in a Neural Network(opens in a new tab)

   Hinton, G., Vinyals, O., Dean, J., 2015

   Knowledge distillation: train a small student model to match the output probabilities of a large teacher.

7. [7]

   Efficiently Scaling Transformer Inference(opens in a new tab)

   Pope, R., Douglas, S., Chowdhery, A., Devlin, J., Bradbury, J., Levskaya, A., Heek, J., Xiao, K., Agrawal, S., Dean, J., 2022

   Analyses the cost of serving large transformers: memory bandwidth dominates at small batch sizes, compute at large ones; the KV cache grows with batch and context.

8. [8]

   Universal Transformers(opens in a new tab)

   Dehghani, M., Gouws, S., Vinyals, O., Uszkoreit, J., Kaiser, Ł., 2018

   Applies one shared transformer block repeatedly, with adaptive computation time deciding per position when to stop. ICLR 2019.

9. [9]

   ALBERT: A Lite BERT for Self-supervised Learning of Language Representations(opens in a new tab)

   Lan, Z., Chen, M., Goodman, S., Gimpel, K., Sharma, P., Soricut, R., 2019

   Shares parameters across all layers of a BERT-style encoder, cutting parameter count sharply while keeping depth. ICLR 2020.

10. [10]

    Looped Transformers are Better at Learning Learning Algorithms(opens in a new tab)

    Yang, L., Lee, K., Nowak, R., Papailiopoulos, D., 2023

    A looped transformer matches a standard transformer on in-context learning tasks with less than 10% of the parameters. ICLR 2024.

11. [11]

    Reasoning with Latent Thoughts: On the Power of Looped Transformers(opens in a new tab)

    Saunshi, N., Dikkala, N., Li, Z., Kumar, S., Reddi, S. J., 2025

    Shows a k-layer transformer looped L times nearly matches a kL-layer model on reasoning tasks, and relates looping to chain-of-thought. ICLR 2025.

12. [12]

    Scaling up Test-Time Compute with Latent Reasoning: A Recurrent Depth Approach(opens in a new tab)

    Geiping, J., McLeish, S., Jain, N., Kirchenbauer, J., Singh, S., Bartoldson, B. R., Kailkhura, B., Bhatele, A., Goldstein, T., 2025

    Huginn: a 3.5B-parameter recurrent-depth language model trained on 800B tokens that improves on reasoning benchmarks as it loops more, up to a compute load equivalent to 50B parameters.

13. [13]

    Adaptive Computation Time for Recurrent Neural Networks(opens in a new tab)

    Graves, A., 2016

    Lets a network learn how many computation steps to take per input, with a penalty on extra steps.

14. [14]

    Confident Adaptive Language Modeling(opens in a new tab)

    Schuster, T., Fisch, A., Gupta, J., Dehghani, M., Bahri, D., Tran, V. Q., Tay, Y., Metzler, D., 2022

    Early exiting for language models: stop running layers for a token once an intermediate prediction is confident enough. NeurIPS 2022.