Claude Opus 5.5 Makes Reasoning Effort a Cost-Control Problem
Executive Summary
The practical question raised by Claude Opus 5.5 is no longer simply whether the model is better, but how much reasoning should be purchased for each task. Early hands-on testing suggests a meaningful improvement in coding, instruction-following, and communication over Opus 5. Yet the same testing shows that the highest reasoning setting can multiply token use—and sometimes runtime—for negligible gains.
Only one item in the past 24 hours was evidenced strongly enough to shape today’s report, so the conclusion should remain narrow. This is a first-day practitioner assessment based on roughly five shipped pull requests, personal benchmarks, and cited vendor and third-party figures—not a settled verdict on reliability. Even so, it sharpens an increasingly important view of advanced models: capability and efficiency must be evaluated as a configured system, not as properties of a model name alone.
What Happened
In an extended first-day review of Claude Opus 5.5, Theo Browne reported that the model felt substantially stronger than Opus 5 for routine implementation work, following detailed instructions, and producing readable explanations. He also saw improvement in computer-use tasks. The praise came with useful limits: he had used the model for only a day, had shipped about five pull requests with it, and had not yet accumulated enough evidence to make a confident reliability claim.
The most consequential finding concerned reasoning effort. In his Skatebench tests, moving from extra-high to max reasoning increased reasoning-token use from roughly 330 to nearly 5,000 per question, while improving the score by about one point. In a separate planning task, max effort entered a loop that continued for six and a half hours. His blunt recommendation was not to use max by default.
Headline token prices do not resolve this trade-off. Browne cited Anthropic pricing of $4 per million input tokens and $20 per million output tokens, along with cheaper cache reads and an estimate that typical workloads cost 40% less than with Opus 5. But he also cited Artificial Analysis results in which maximum effort consumed almost 120,000 output tokens per task, compared with about 27,000 for GPT-6 Astra. Those external numbers were not independently verified here, but they illustrate the right concern: a lower unit price can be overwhelmed by a model spending far more units.
Why It Matters
Reasoning controls are becoming operational controls. A team choosing “the best model” has not finished making the decision if that model can run at materially different effort levels. It must also decide which tasks justify deeper search, how long a run may continue, and what evidence warrants escalation from a moderate setting.
This changes evaluation practice. A benchmark score without token consumption, wall-clock time, and failure behavior can reward economically irrational configurations. The relevant comparison is the complete task outcome: quality achieved, total cost, elapsed time, and whether the system knew when to stop. On that basis, medium or high reasoning may deliver more useful work than max, even when max wins narrowly on a scorecard.
The caveats also matter. Browne found weaker front-end taste than Fable 5.1 in his tests, less-thorough repository review than OpenAI models, and occasional poor judgment around context compaction. These observations complicate any claim that one model has become a universal default. Different parts of software work—planning, repository analysis, implementation, interface design, and long-running autonomy—still expose different strengths.
The Bigger Story
Today’s signal reinforces a developing canon in agentic work: more autonomy and more inference are not automatically better. Recent discussion has emphasized permissions, interfaces, and supervision; reasoning effort belongs in the same control plane. The mature workflow is likely adaptive: begin with a bounded effort level, measure progress, escalate only when the expected value justifies it, and impose explicit time or spend limits.
Opus 5.5 may indeed be a substantial step forward. The more durable lesson, however, is that frontier capability increasingly arrives with a tuning problem. The teams that benefit most will not merely select strong models. They will govern how those models spend their intelligence.
Further Reading
- Theo Browne, first-day Claude Opus 5.5 tests and cost analysis — useful practitioner evidence, best read with the review’s limited sample size in mind.