Opus 5.5: Theo’s First Day with a New Coding Model

Opus 4.5 changed how I worked with coding agents, but subsequent releases did not all live up to that experience. I initially liked Opus 5, then found its writing and coding mistakes made it hard to rely on. After a single day with Opus 5.5, I am excited again, though it is too early for a final verdict.

So far it feels cheaper, clearer in conversation and much better at following instructions and writing code. Whether it can replace Fable for my work is still unknown. I want to show the evidence and examples behind my enthusiasm, including the weaknesses.

Anthropic says Opus 5.5 performs near Fable 5.1 on much work and costs 40% less to run than Opus 5 on typical workloads at default settings. It also cites a tester’s 680,000-line migration. Those are company claims and examples; actual performance and cost depend on the task.

The launch prices shown are $4 per million input tokens, $20 per million output tokens and $0.20 per million cached input tokens. Anthropic describes the cached-read rate as 60% lower than before and says output generation is over 30% faster. Faster output does not alone determine the time or price of a complete task.

My favorite change is the communication style. Anthropic says it worked on clearer, more natural explanations, and I have already noticed the difference. Putting the important information first makes long agent sessions easier to follow, although clear writing is not proof that the underlying work is correct.

The company’s selected coding benchmarks show strong results. On its Terminal-Bench chart, Opus 5.5 at medium scores above Fable 5.1 at max at a much lower reported cost. Individual benchmarks, effort levels and test conditions matter; those charts do not settle every real-world comparison.

Other charts, including FrontierCode and CursorBench, show that increasing reasoning effort does not always improve a score. I made a separate visualization using Artificial Analysis data so I could compare cost and score more easily. In the displayed index, Opus high scores higher than Astra high but costs more.

In my early use, medium, high and x-high have been useful, while low and max have caused concerns. This is a preference based on limited testing. A different task or budget may make another setting worthwhile.

Anthropic’s writing example illustrates a billing bug. The newer response leads with the finding and clearly separates the effect of the free tier from a regression that omitted the last day of the month. I find the explanation much easier to read than the older example.

I also discuss zero-data-retention options as a reason businesses might choose one model over another. Availability is governed by the specific product, account and contract; a claim about one model’s eligibility does not mean every subscriber automatically has zero retention. Organizations should verify their own terms.

A public comment acknowledging problems with the previous model strikes me as a welcome change in communication. I infer a more open culture from the posts around the release, but that is my impression from outside the company, not a verified change in internal policy.

Before returning to benchmarks I show a third-party action-game demo and mention a practical cache improvement reported by another developer: changing reasoning effort during a session no longer necessarily invalidates the cached prompt. The actual behavior depends on the relevant implementation and version.

On the Artificial Analysis index, Opus 5.5 leads the displayed chart, but I also question what a gap of a few points means in practice. A benchmark summarizes selected tasks and can obscure the qualities that matter in daily coding.

The output-token chart shows another tradeoff. At max effort, Opus 5.5 uses nearly 120,000 output tokens per index task in the comparison, versus about 73,000 for Opus 5 and 27,000 for Astra. A faster token rate can still mean a longer task if many more tokens are generated.

Lower prices help offset the increased token use. At max, the displayed cost per task is close to the earlier Opus model; at medium or high it is much lower. These are index-specific costs, not a guarantee for every workload or subscription.

I plot the cost and score combinations as a frontier and point out another model, MiMo V2.6, that appears competitive at a lower price. The visualization is based on a snapshot of one data source; it should help compare settings rather than serve as a timeless ranking.

Artificial Analysis attributes much of the cost moderation to lower input, output and cache-read pricing. Another observer describes medium Opus as reaching Fable-level intelligence at a lower cost; I think that conclusion is stronger than the evidence warrants, even if the measured price gap is interesting.

My frustration with max effort also comes from an actual run: a planning task spent six and a half hours looping and was only partly complete when I stopped it. I switched settings and asked for an update. One failure does not establish that max is always inappropriate, but it shows why I prefer to monitor long runs.

In my Skate Bench experiment, x-high used about 330 tokens per question, while the max run was approaching 5,000 and was still unfinished when I showed it. The preliminary score improved by only about one percentage point. On this particular test, the extra cost did not look worthwhile to me.

I show my subscription dashboard after a day of heavy use across multiple accounts. I estimate that roughly 20% of one account’s weekly limit was attributable to Opus, after accounting for earlier Fable use. This is a personal estimate, not a guaranteed allowance; limits, eligibility and terms can change.

The work included making the benchmark visualizer, adapting it for different hosts and using a browser to verify it. When I noticed a bug in another project, the agent found the repository, updated a stale checkout, made an isolated worktree and prepared a fix. I say these tasks used only a small portion of my weekly quota.

For my own subscription usage, I find the value attractive compared with the alternatives I was using that day. That comparison depends on my workloads and plans; it should not be taken as a general price or value guarantee.

I also tried a personal test asking models to investigate a large codebase and suggest improvements. Grok 4.7 and OpenAI models were more thorough in that setting, while Opus 5.5 improved substantially over Opus 5 according to my judging setup. I speculate about the training data behind Grok’s performance, but do not know the cause.

A deep codebase audit is useful, but I do not do that task every day. It reveals one weakness I perceive in Anthropic models compared with some alternatives, rather than defining the best model for all coding. Findings still require independent validation.

Front-end design gives a mixed picture. In examples using and not using a design skill, many Opus results look merely adequate to me. I prefer Fable’s subtle layout and animation choices in the examples I inspect, although those judgments are subjective and based on a limited sample.

Other people see it differently. Mia generated 100 HTML examples and called Opus 5.5 the best model she had tested; I look at paper-like layouts, a neon design and a chess game. The varied reactions show how prompting, examples and taste can affect a design comparison.

I show other people’s demos, including an integration that brings T3 Code into Minecraft and a series of game experiments. A Dark Souls-inspired demo, a flight simulator and an animated sequence are impressive prototypes, even though they are not equivalent to finished commercial games.

Another developer made a skateboarding game in C++ and a browser-based first-person demo. I observe that the web example looks stronger in some respects and that model-assisted computer use can sometimes identify rendering problems. These examples show possibilities, not a systematic comparison of engines or languages.

My own Fish Slop game initially ran smoothly on my machine, with attractive models and controls. I realized I had used medium reasoning, then asked the model at x-high to refine its visual presentation. The later result builds on the earlier version rather than being an independent one-shot generation.

The improved demo includes a stingray, animated fish, lighting and a camera mode. I am especially impressed that the gameplay loop made me want to keep playing, although I can still see lighting artifacts. The video conveys my reaction to this particular prototype, not a measured product-quality result.

The model still has quirks. In a long-running performance task, one agent reported that another was close to context compaction and warned that uncommitted work could be lost if it crashed. I thought parts of that warning were confused given the machine and workflow, though uncommitted work can carry risks depending on the failure.

I speculate that earlier training and context limits may explain why the model worries about compaction. That mechanism is not established by this example. Long-running tasks and recovery behavior are also difficult to judge from short benchmarks, so I want more evidence before drawing broad conclusions.

The performance-improved game ran smoothly in my demonstration, but I noticed a transparency problem near the water surface. I like the result while recognizing that a polished demo can still contain visual or functional bugs.

On day one I had only about five medium-sized pull requests to inspect. My rough impression is that severe issues were similar to or less frequent than in my Fable examples, with a similar or slightly higher number of minor issues. The sample is far too small to establish reliable error rates.

I expect occasional bad spikes: on longer work, even a relatively reliable model can get stuck fixing something unnecessary or misunderstand its context. I am not ready to discard Fable based on one day. Both outputs and the systems that verify them still need scrutiny.

My early verdict is that Opus 5.5 is a valuable daily coding option for my subscription usage, though API costs and limits differ. I also want to test GPT-6 Sol more. The competitive picture is moving quickly, and the choice should be revisited as evidence accumulates.