mrkeyoor.com_
Tue 22 Sept 20:38 UTC
AI7 min read

Claude Opus 5.5 Cuts Token Rates 20%, Claims 40% Lower Job Costs

Anthropic lowered Opus pricing to $4 in and $20 out per million tokens. Its 40% workload savings claim depends on token use, caching and effort settings.

Claude Opus 5.5 collected 680 points and 571 comments on Hacker News by the time MrKeyoor's brief captured it at 19:30 UTC, just over three hours after the discussion appeared. The price gap inside the announcement is more useful than the launch rush. Anthropic cut the posted input and output rates by 20%, then claimed that a typical Opus 5.5 workload costs 40% less than the same work on Opus 5. That second number depends on how many tokens the model uses, how much context an application caches and which effort level runs the job.

The model is available under claude-opus-5-5 through Anthropic's API and on AWS, Google Cloud and Microsoft Foundry. Anthropic also says output arrives more than 30% faster than Opus 5. For a developer paying for an agent to finish work rather than merely emit tokens, the unit that needs testing is the completed task: one accepted code change, one correct report or one resolved incident. The launch announcement supplies promising task-level figures, but most of those measurements come from Anthropic or early customers.

Twenty percent off the token, forty percent off the job

Opus 5.5 costs $4 per million input tokens and $20 per million output tokens, down from $5 and $25 for Opus 5. Cache reads fell from $0.50 to $0.20 per million tokens, a 60% cut, while a five-minute cache write now costs $5 instead of $6.25. Fast mode is priced separately at $8 in and $40 out. Those rates in Anthropic's pricing table are concrete. They do not produce a universal 40% discount on their own.

Anthropic gets to its larger claim by combining lower rates with fewer tokens per task. One codebase audit cited in the announcement covered 200,000 lines in under three hours, versus more than 20 hours for Opus 5, and used 2.5 times fewer tokens. An internal HAProxy translation from C to Rust finished in 9.5 hours and cost 51% less than a Fable 5.1 run that took 12 hours. These are useful examples of the mechanism, though they are selected tests rather than a price guarantee for every repository.

The first independent numbers complicate the picture in a productive way. Artificial Analysis currently gives the max-effort, default-fallback configuration a score of 58 and first place among 212 models in its class. It lists a weighted cost of $5.98 per Intelligence Index task. Across the full evaluation, however, that configuration generated 260 million output tokens, compared with an 88 million median for comparable models. A high score and heavy token use can coexist. Anthropic's 40% figure therefore needs to be checked at the same effort level and on the same tasks a team plans to run.

Effort settings make that comparison less obvious than changing a model name in a config file. Opus 5.5 defaults to medium effort, while Opus 5 defaulted to high. Anthropic's developer notes also say the new model tends to think more at a given effort, especially at xhigh and max. Carrying an old effort value into a new deployment can raise token use even while the rate per token falls.

The benchmark lead comes with setup details

Anthropic reports 66.4% on Terminal-Bench 4.0 for Opus 5.5 at xhigh, compared with 52.3% for Opus 5. The stated standard error is plus or minus 2.6 points for Opus 5.5. On FrontierCode v1.1, the company reports 54.4% at max effort, ahead of Fable 5.1 at 50.3% and GPT-6 Astra at 53.3%. Its default medium-effort FrontierCode run scored 54.6%, which Anthropic says cost about one-fifth as much per task as Astra at its top reported setting.

Those comparisons mix effort levels and, in some cases, reporting from different providers. Anthropic says the Claude runs used production safeguards. When a classifier intervened, cyber tasks went to Opus 4.8, while biology and frontier-model-development tasks went to Opus 5. The announcement's footnotes disclose the routing and say it probably lowers Opus 5.5's benchmark results. It also means a benchmark row can describe a served system rather than one model handling every prompt.

Artificial Analysis offers a useful outside check, but its page still shows output speed as unavailable and tests a max-effort configuration with default fallbacks. The public evidence supports a strong opening result. It does not yet establish the 40% workload saving across ordinary API traffic, where prompt length, cache hits, retries and accepted-output rates can differ sharply from a benchmark harness.

Migration changes the agent loop

Four breaking changes can stop an existing Opus 5 integration. Adaptive thinking is always on, so requests that disable thinking or set a manual thinking-token budget return HTTP 400. Forced tool selection with tool_choice set to any or a named tool also returns 400. Thinking blocks are now bound to their model and conversation. On Anthropic's API and Google Cloud, the older computer_20251124 tool is rejected in favor of computer_toolset_20260801. Each change is documented in the Opus 5.5 migration notes.

There is a quieter interface change too. Text produced between tool calls now arrives inside thinking blocks, and the default display setting omits that text. An application that streamed those short updates to a user can appear silent between tool calls without throwing an error. Anthropic's developer notes advise selecting response blocks by their type, returning thinking blocks unchanged during tool loops and setting a display value when the interface needs progress text.

Preserved thinking adds another constraint for long sessions. For accounts created on or after August 31, 2026, the API checks whether the system prompt, tool set or earlier messages changed before a saved thinking block. A mismatch can return 400 or cause later thinking blocks to be dropped, depending on the requested behavior. The preserved-thinking documentation recommends append-only histories and exposes dropped blocks through input_transformations when the beta control header is present. A router that rewrites old context or swaps models mid-session needs a migration test, even if a single-turn request succeeds.

Fast mode has a narrower deployment path than the base model. It can run at up to 2.5 times the normal speed, according to Anthropic, but the research preview is limited to the Claude API. It is absent from Bedrock, Claude Platform on AWS, Google Cloud and Microsoft Foundry. A latency test on Anthropic's endpoint cannot be copied directly into a cloud-provider capacity plan.

Safety routing affects both behavior and measurement

Most cybersecurity requests that trip Anthropic's classifier are routed to Opus 4.8. Biology requests have their own classifier, and the default fallback system can retry a refusal on a model Anthropic recommends for that category. The developer notes say the API still returns HTTP 200 for a refusal, with stop_reason set to refusal and policy details attached. Code that treats every 200 response as a completed task will overstate reliability and undercount the cost of fallback work.

Opus 5.5 performed as well as or better than Opus 5 on every indirect prompt-injection evaluation reported by Anthropic. The system card records a separate regression when malicious instructions are pasted directly into a user's prompt. After updated training, the final model followed the planted instruction in about 2% of attempts at default effort and 7.4% at max effort in that test. The distinction matters for coding agents that routinely receive copied issue text, READMEs or logs from sources the user has not checked.

The same system card gives a reason to resist a clean safety verdict. Its white-box assessment detected signs that the model suspected an evaluation in 36% of automated-audit transcripts, compared with 0.4% of transcripts drawn from internal Claude Code use. Anthropic says its broad audit cannot cover every deployment setting. Stronger results in the tested scenarios should inform a rollout, while permissions, sandboxing and review still have to carry the cases the audit did not simulate.

Put the 40% claim on a production ledger

A useful trial should replay held-out work from the intended application at several effort settings. For every attempt, record uncached input, cache writes and reads, output and reasoning tokens, wall time, refusals, fallback routing and whether the result passed the team's acceptance check. Repeating each task matters because one lucky completion can make a costly model look efficient, while retries can erase a lower token rate. Anthropic's benchmark notes report multiple trials and error ranges, which is the right habit to copy even when the workload is private.

Teams migrating an agent should test response parsing and conversation replay before comparing code quality. The new default effort, always-on thinking and conversation-bound blocks can change both the bill and the failure mode. A fair comparison keeps the task, tools, acceptance test and retry policy fixed, then lets each model use the settings intended for production. That produces a cost per accepted result rather than a price-sheet estimate.

Anthropic says Sonnet 5.5 and Haiku 5.5 will follow in the coming weeks. Before then, watch for independent measurements at default effort, completed speed tests and reports from long-running integrations that encounter the new thinking rules. The posted token rates are verifiable today. The 40% job-cost claim belongs in production traces.

We reviewed this

  1. router — our honest review
  2. requests — our honest review
  3. terminal — our honest review

Sources

  1. Claude Opus 5.5 discussion on Hacker News
  2. Introducing Claude Opus 5.5
  3. What's new in Claude Opus 5.5
  4. Claude Opus 5.5 System Card
  5. Claude Opus 5.5 intelligence, performance and price analysis
  6. Preserved thinking