In 30 Sekunden
Theo discusses Claude Fable 5.1’s launch-era pricing, safeguards, benchmarks, design demos and prompting guidance. He describes extensive early use in T3 Code and Lakebed, including successes and an incorrect audit result. His PR comparison uses small, selected groups and different tasks, so its bot findings and timings are descriptive rather than a controlled measure of model quality.
- 1Launch pricingAnthropic estimated savings from cheaper cache reads; actual cost depends on the workload and other token categories.
- 2Cache writes matterIn Theo’s displayed example, cache writes account for nearly 60% of the estimated cost.
- 3Benchmark cost per taskArtificial Analysis reported higher cost on its index despite the cache-read discount.
- 4Prompting guidanceTheo discusses effort levels, progress updates, scope and compaction.
- 5A mistaken auditThe model initially misunderstood how PR linking worked and corrected its report after feedback.
- 6Observational PR comparisonThe selected cohorts differ in tasks and workflow, limiting conclusions from their review and timing metrics.
Das Wichtigste
- Cache-read discounts can reduce costs in agentic workflows, but cache writes and output tokens can still dominate a bill.
- Fable and Mythos share an underlying model but have different safeguards and access conditions.
- Theo finds improved design and coding behavior, while reporting an audit that initially misunderstood PR linking.
- A clear endpoint, scope limits and requested progress updates can help tailor an agent workflow.
- His PR figures come from selected, non-equivalent workloads and automated-review signals, not a controlled experiment.
- Automated reviews and tests provide evidence about changes but cannot prove the absence of defects.
Den bearbeiteten Text nach Kapiteln lesen
Launch, pricing and safeguards
Theo introduces Fable 5.1 and explains the relationship to Mythos. He discusses launch-era cache pricing and data retention.
Fable 5.1 is here, and after a day of heavy use I am impressed. It feels like a meaningful improvement over Fable 5, though pricing and instruction-following have nuances. My team landed 89 PRs in 24 hours while using it; that experience informs my review but is not a controlled benchmark.
Anthropic says Claude Fable 5.1 and Mythos 5.1 are the same underlying model with different safeguards. Fable is generally available, while Mythos is limited to trusted access for work including cybersecurity and life sciences. I also find the new model's responses more readable and less full of stock technical jargon.

At launch, Anthropic estimated that typical token-billed workloads would cost 25% less than Fable 5 and highly agentic work could save up to 45%, chiefly because cache reads became 75% cheaper. Standard rates remained $10 per million input tokens and $50 per million output tokens, with cache reads at $0.25 per million. Those are launch-era figures; actual costs depend on usage and may change.
Caching matters when an agent repeatedly calls tools. Each result continues the conversation with previous context, and a cached prefix can avoid reprocessing all of that input at the full rate. In one of my usage breakdowns, most input tokens were cache reads. That does not mean all repeated reads are new text.

Cache writes are a different cost. In the example on screen they make up nearly 60% of the estimated bill, about $1,171 out of roughly $1,963, while cache reads are about $264 and output about $523. My subscription usage is not the same as paying that API bill. For a short chat with few tool calls and a five-minute default cache, the savings may look very different.
Anthropic also describes Enterprise Frontier Safeguards, intended to keep data in customer-controlled infrastructure while applying its safety checks. Its availability and terms are specific to the enterprise offering. The company says false positives are down 60%; in my own heavy use I encountered only one safeguard flag. Neither observation establishes that false positives or safety risks are gone.
Benchmarks and demonstrations
He reviews reported coding and research results, then compares cost per task and design examples. The examples do not substitute for controlled real-world comparisons.
On Terminal-Bench Science and terminal coding, the launch charts show higher scores than the prior model at several effort levels. The chart also shows a gap between Fable and Mythos, which Anthropic attributes to Fable's safeguards sometimes falling back to Opus. Same underlying model does not mean identical system behavior in every evaluation.

Cursor's coding benchmark also reports stronger scores at lower cost in the displayed runs. I notice that high effort is often a useful setting, while going beyond it does not always yield a proportionate improvement. Fable 5.1 can generate more output than its predecessor, so token efficiency and the usefulness of the work both matter.
Anthropic presents scientific examples including protein binder design, a map derived from Venus radar data and computational-biology kernel optimization. The reported results are encouraging examples of research assistance, not proof that the model independently solves medicine. The company's safety evaluation also reports improved behavior on several measures, which applies to the tests it describes.
A change to conversation history affects developers building on the API: Anthropic describes an append-only approach as part of its anti-distillation efforts. Editing prior context can affect continuation and preserved reasoning, so clients with branching histories may need to adjust. The rollout discussed here was gradual and the exact rules are time-dependent.
Artificial Analysis reports a higher score on its index, but says Fable 5.1 at max cost about $3.76 per task, roughly 20% more than Fable 5 in that evaluation, partly because it generated more output. The cheaper cache read saves money where repeated cached context is common; it does not guarantee every benchmark or workload becomes cheaper.

I also compare a physics reasoning benchmark with a measure that penalizes confident wrong answers. Sol leads in one chart, while Anthropic models perform better in the other. My explanation that the labs may emphasize different behaviors is an interpretation, not proof of their training objectives or a causal explanation of their scores.
For frontend design, Which-AI's examples with Anthropic's design skill show animations and distinctive landing pages that I like much more than the Fable 5 versions. In these examples the design skill helps substantially. I have not yet done extensive frontend work of my own with the model, so I treat these as demonstrations rather than a complete evaluation.

In my 2D Fish Slop rebuild, the fish tilt as they change direction, bubbles trail the submarine, and sounds distinguish actions. Some assets came from earlier versions, but the model applied them well. The detail that impresses me is how the movement and animation curves combine into a more coherent experience.

The 3D version uses Blender for some models and produces recognizable fish, coral and rocks. I like the movement and mouse acceleration, although some controls differ from what I expected and the monsters are not fully animated. Similar-looking results across models make me wonder about shared data, but that is speculation.
Prompting and real-world use
Theo covers effort settings, progress updates and scope. He demonstrates both an incorrect audit and successful PR takeovers.
Anthropic's prompting guide recommends starting with high effort and testing other settings against your own evaluations. Low and medium have handled many tasks for me, but may miss a subtle complication; higher effort is not a guarantee either. I also suggest revisiting old instruction files and removing rules that no longer match the model's behavior, then adding back what is needed.
One documented change is fewer progress updates during long tool runs. While trying unsuccessfully to recover corrupted audio, I saw a run last over 24 minutes with more than 60 tool calls and long stretches without a text update. If updates matter to you, the guide suggests requesting them directly and removing old instructions that suppress them.

The guide discusses denser prose, fewer default bullets and bold, and the possibility of reproducing source passages without marking quotations. It suggests explicit writing instructions and examples when needed. It also recommends giving an autonomous task a clear endpoint, specifying what compaction should preserve, and setting scope constraints when the model adds unnecessary nearby changes or tests.
In real work, I asked the model to audit how T3 Code links PRs to threads. Its first report incorrectly said nothing linked them automatically; I corrected it that branch lookup provided the behavior I meant, and it acknowledged the distinction. This example shows that even a useful agent needs its claims checked and clarified.

For stalled PRs, I use a takeover instruction: check out the branch in a worktree and take responsibility for getting the change ready. Several changes previously stuck in repeated review loops landed after Fable 5.1 took them over, including work on skill selection and streaming behavior. That is my experience on these tasks, not evidence that every takeover will succeed.
Lakebed and PR analysis
He describes delegated cleanup and testing, then compares selected PR cohorts. The results are specific to his projects and workflows.
I asked it to audit Lakebed for messy code, review its proposed order and delegate cleanup across subagents. I allowed simple changes to merge because this project did not automatically deploy to production. It reported ten merged PRs, green checks and a net reduction of roughly 13,000 lines across 340 files. Automated review and CI are useful signals, but do not prove the changes are defect-free.

A second quality audit led to further parallel PRs, which another agent monitored and merged. I did not read every line, but I did examine results through benchmarking; in some difficult cases I observed improvements of 85–90%. Those measurements concern my project and selected cases, not a general speedup attributable to the model.
The model also helped identify contributor PRs worth reviewing and merging in T3 Code. I increasingly allow it to merge changes it judges ready, especially focused fixes, while recognizing this is risky and that a bad outcome may eventually occur. My trust here is a personal choice under my project's workflow, not a universal recommendation to remove human oversight.
To compare models, I asked for an analysis of my PRs across T3 Code and Lakebed: the first 24 hours of Fable 5.1 against selected high-activity days for Fable 5 and Sol. The cohorts, tasks, review conditions and amount of human involvement differ, so this observational comparison cannot establish causation or a universal ranking.
The report shows 13 Fable 5.1 PRs, with a median of 489 added lines across 11 files and four packages. It reports 0.4 high-severity bot findings per thousand lines versus 2.06 for Fable 5 and 1.02 for Sol. Bot findings are an imperfect quality signal and the small, selected samples make direct comparisons uncertain.

The displayed report gives median time from PR filing to merge of about 50 minutes for Fable 5.1, 47 for Fable 5 and 30 for Sol. I also discuss fewer follow-up commits in the selected sample. These figures describe different tasks and workflows; faster merge time or more changed lines alone does not prove better software.
Delegating more work
Theo reflects on a shift from autocomplete to delegating review and some merges. He notes the corresponding increase in autonomy and usage.
The change I feel is in the level of work I can delegate. I moved from autocomplete, to directing edits in known files, to reviewing PRs, to asking agents to find and review candidate PRs, and now sometimes to letting them fix and merge focused changes. More capable agents can also consume more allowance simply because I ask them to do more and coordinate more subagents.
For me, Fable 5.1 is a meaningful improvement that lets me spend more time on higher-level decisions. It is not a proof that every model output is correct or that every team should use the same level of autonomy. I am excited by the update and want to keep testing its strengths and limitations.
Mehr aus diesem Kanal
36:07EN
30:37EN
0:43EN
29:22EN
31:13EN
31:47EN