Claude Opus 5.5 and the Myth of Cheaper AI: Engineering Progress or a Pre-IPO Price War?
Automatically translated. Read the Chinese original.
I liked Opus 5.5 at first. A stronger model at a lower price was welcome news. I subscribe to both Claude Pro and ChatGPT Plus and use Claude Code and Codex, so I had reason to hope that competition would eventually benefit users.
But after looking at my own usage records and AA's tests, then reading Fuli Luo's post on inference cost reductions alongside Anthropic's capacity expansion and incident reports, I have become increasingly unwilling to take the "stronger and cheaper" story at face value.
I am now more inclined to see this as price competition ahead of an IPO: cutting prices to win users and demonstrate growth while still dealing with expensive compute capacity and service delivery problems. That is my interpretation; I do not have access to Anthropic's internal decision-making documents. I want to know how much of the engineering economics behind these cuts has been explained, and how much of the growth investors welcome will translate into benefits for users.
Cheaper by 40% compared with what?
In its September 22, 2026 announcement, Anthropic presented Opus 5.5 as a more capable model with lower operating costs. Its claim of a 40% cost reduction on typical workloads compares it with Opus 5, under the default settings in Anthropic's tests. It does not mean the model is 40% cheaper than every competitor.Launch announcement
The official documentation confirms that standard input pricing fell from $5 to $4 per million tokens and output pricing from $25 to $20, both reductions of 20%. Cache reads fell from $0.50 to $0.20, a 60% reduction. For Opus 5.5, cache writes cost $5 per million tokens with a five-minute TTL and $8 with a one-hour TTL.Pricing and migration documentation
The 40% figure is therefore not a uniform discount visible on a price list. It combines lower prices for different token categories with changes in consumption on particular tasks. Change the cache mix, reasoning effort, or task, and that percentage can change too.
The announcement does state its comparison baseline and test conditions. My criticism concerns the appeal of the product narrative: the previous generation supplies the price baseline, favourable tasks supply the capability baseline, and together they make "stronger and cheaper" an easy reason to buy. That still does not tell me whether Opus 5.5 is worth its price alongside the alternatives available today.
The overlooked part of my usage figures: caching
I pay for Claude Pro and ChatGPT Plus. The CC Switch amounts below are API-equivalent cost estimates used to examine the usage mix, not additional bills I paid.
Over the past 30 days, claude-opus-5-5 in Claude Code accounted for 1,264 requests, approximately 360 million tokens, and an estimated API-equivalent cost of $118.58. Codex, using several GPT models, accounted for 4,612 requests, approximately 623 million tokens, and $168.75. Looking only at the totals, I would have thought I was using Codex far more. Dividing by the request count changes the picture.
My usual settings also matter: I mainly use Opus 5.5 at Medium effort, occasionally High; for GPT-6.1 Sol, I mainly use High and sometimes Medium. The Codex totals include other GPT models, so the table does not represent GPT-6.1 Sol alone. Effort settings with the same name across providers do not imply the same compute budget.
Claude averaged approximately $0.0938 per request, compared with $0.0366 for Codex: about 2.56 times as much. Average total token counts were approximately 284,800 and 135,100 per request, respectively, a ratio of about 2.11.
A request is not a task, however. A tool call can generate requests, and a single piece of work can involve many requests. Claude Code and Codex use different tool orchestration and context management, and my Codex usage spans several models. These figures describe my two usage setups; they do not show that Claude costs 2.56 times as much to complete the same task.
My personal records do not hold tasks, acceptance criteria, or time spent on rework constant. They do show how my usage setups consume resources, which gives me reason to investigate further. Consumers are entitled to judge a product against their own work rather than remain confined to the success stories a vendor selects.
A 98.8% cache hit rate, yet substantial costs
The Claude statistics show a cache hit rate of 98.8%, approximately 355 million cache-read tokens, 4.46 million cache-write tokens, and 1.27 million output tokens. Newly added standard input is shown as just 2,682 tokens; the reason for this anomaly remains unconfirmed.
Using the verified prices and assuming all cache writes use the five-minute rate gives approximately $71 for cache reads, $25.40 for output, $22.30 for cache writes, and $0.01 for standard input: about $118.71 in total. That differs by roughly $0.13 from the $118.58 reported by the software. Rounded usage figures could contribute to the difference; details such as the cache-write TTL would require the underlying logs to confirm.
The 355 million cache-read tokens account for about 98.6% of the displayed total token count, but still about 59.8% of the recalculated cost. The first percentage comes from dividing the displayed aggregate figures; it should not be confused with the software's reported 98.8% cache hit rate.
A cache hit reuses content that has already been processed, usually avoiding some of the overhead of processing it again. It receives a discount and is still billed. Even a very low cache-read price can become a major cost when multiplied by enough repeated usage.
Holding this usage mix fixed and applying the old Opus 5 rates produces an estimated cost of $237.14. At Opus 5.5 rates, it is approximately $118.71, nearly half as much. Lower cache-read pricing alone accounts for about $106.50 of savings, roughly 90% of the total savings in this fixed-usage calculation.
For a setup as cache-heavy as mine, that is a meaningful price cut. It also shows where the savings come from: most are due to a lower charge for repeatedly reading context. This calculation holds token usage constant; it does not measure how much each model generation consumes to complete the same task. My records therefore neither verify nor disprove Anthropic's claimed 40% reduction on typical workloads. The savings achieved here and the cost relative to competitors are separate questions.
The difference between my two tool setups is concentrated here too. Claude reads approximately 280,900 cached tokens per request, compared with about 130,100 for Codex; output averages approximately 1,005 and 449 tokens, respectively. The context repeatedly carried forward is far larger than the final output. Discussing agent costs only in terms of how much text appears in the answer misses a great deal of repeatedly read history.
A high cache hit rate alone does not establish that the entire workflow is efficient. Whether these costs are worthwhile depends on which history must be retained, which calls are useful, and how much acceptable work is ultimately delivered.
For subscribers, I also lack a publicly available fixed conversion table that would let me reconcile API-equivalent costs with plan allowances item by item. The $118.58 figure cannot tell me directly how quickly I would hit a usage limit. I want to know whether the same subscription tier can reliably support more work, or whether I need to pause, wait, or buy additional usage. These records do not capture those outcomes. They provide leads to investigate, rather than a controlled comparison of subscription value.
AA's lead comes with a cost
Artificial Analysis offers another perspective. When checked on October 18, Opus 5.5 in its "max with fallback" configuration had an Intelligence Index score of 58 and a cost of $5.98 per Intelligence Index task. GPT-6 Astra at max scored 53 and cost $3.26 per task. Opus scored higher and cost approximately 1.83 times as much.Opus model page、Astra model page
Between these two configurations, Opus achieves a higher score at a higher test cost. Whether the capability gain is worth the difference depends on the problem it solves. An index score of 58 rather than 53 does not mean a productivity gain of about 9%; dividing scores cannot reveal the benefit to my work.
AA tests the Max configurations, which differ from my everyday settings. The Opus entry also includes fallback. Those conditions belong alongside the figures.
AA's methodology states that its Intelligence Index cost calculations prioritise token counts reported by each provider's API. This differs from its speed tests, which use a common tokenizer. Costs also reflect benchmark weights and cache measurements. A "max" label does not establish an equal compute budget across models.AA methodology
AA's output-token chart makes the consumption more visible. Opus 5.5 Max with fallback uses a weighted average of approximately 119K total output tokens per task, including about 84K reasoning tokens. The chart labels GPT-6 Astra Max at approximately 27K total output tokens and GPT-6 Sol Max at approximately 38K. The 119K figure already includes reasoning; another 84K must not be added to it.
Using the totals labelled in the screenshot, Opus consumes about 4.4 times as many tokens as Astra and 3.1 times as many as Sol. Some component labels do not quite sum to the displayed totals, possibly because they were rounded separately. They should not be used to infer exact underlying values. The screenshot also lacks a capture date and index version, so it should not be combined with a live page as though both formed one precisely documented historical test.
These ratios describe the billed token consumption in the chart, not compute usage or the amount wasted. But when lower unit prices are presented as an advantage, higher consumption belongs in the discussion too. What useful results required those additional tokens? If the extra capability does not benefit my tasks, a leaderboard lead cannot offset my usage costs.
There is also evidence pointing in the other direction. In the same launch announcement, Anthropic claims that Opus 5.5 at the default Medium effort setting beats GPT-6 Astra's highest FrontierCode score at roughly one-fifth of its cost per task. This is a different test from AA's Max composite index, with different benchmarks, effort settings, and workflows. Cost advantages can reverse across tasks and configurations, and selecting one favourable chart can tell a very different product story. I want to know where my typical work falls.
Fuli Luo's post makes me question Anthropic's engineering economics
Fuli Luo's post about MiMo API price cuts is a piece of evidence I did not want to leave out. The Chinese X translation shown below matches the corresponding English archive. She attributes the largest cut, up to 99%, to cached input, saying that hierarchical KV-cache optimisation in the inference framework increased cache capacity roughly fivefold, equivalent to an approximately 80% reduction in caching costs. She also refers to roughly "2–3 times" of profit headroom in the original pricing and says the new prices can broadly break even when the system runs near full capacity.English archive、Original post
The value of this explanation is that it connects engineering with commercial pricing: how caching became cheaper, how much headroom the original prices left, and why the company is now willing to pass it on. These remain the team leader's own claims, not audited findings, but they at least identify mechanisms that can be examined.
Xiaomi's technical article explains further that Hybrid SWA can reduce KVCache storage to about one-seventh of a full-attention architecture. Cache management, prefix matching, and scheduling must be adapted together to realise those architectural gains. DeepSeek's earlier V3/R1 system overview also discusses prefill/decode disaggregation, expert parallelism, and load balancing. Gains in individual components do not equal a reduction in the cost of the whole service, but they give the discussion something concrete to examine.Xiaomi technical article、DeepSeek system overview
For Anthropic, a 60% cut in the cache-read price is not evidence that KVCache resource costs also fell by 60%. The Opus 5.5 launch and migration documents I read state that the model requires less compute to serve, but do not provide a before-and-after engineering breakdown sufficient for me to verify the change in unit caching costs. That gap does not establish that no optimisation took place. Nor does a lower selling price, by itself, establish an engineering breakthrough.
I am not bringing in Fuli Luo to promote another company. I want to ask Anthropic how much of this price cut comes from engineering savings already achieved, and how much comes from giving up pricing headroom to win market share. The latter is a normal commercial choice too. Consumers need not automatically treat it as a technological dividend, or place their trust in a new price list.
Compute can be bought from Musk; press conferences cannot deliver a reliable service
The phrase "borrowing compute from Musk" is more accurately described as a commercial capacity agreement. On May 6, Anthropic announced that it would use all the compute capacity at SpaceX's Colossus 1, gaining access to more than 300 megawatts and over 220,000 NVIDIA GPUs. It linked that expansion directly to higher Claude usage limits. Its partner issued a corresponding announcement.Anthropic announcement、Partner announcement
There is nothing shameful about buying external compute capacity. It does show that the capacity available to users remains closely tied to external supply. Buying more compute and using each unit more efficiently are different things. An expansion announcement cannot substitute for evidence of efficiency.
I do not rate Anthropic's service engineering as highly as its model capabilities. Using the UTC dates on its official status page, elevated errors on September 29 affected the website, Claude Code, Cowork, and the API. Opus 5.5 experienced elevated errors again on October 6. On October 7, some organisations were incorrectly paused for reaching their spending limits, causing requests to the API and other products to be refused. Users bear the consequences of these delivery failures.September 29 incident、October 6 incident、October 7 incident
This official status-page snapshot also records service incidents across several products and shows 99.59% API uptime over the past 90 days. It is not an industry-wide comparison, and it does not establish that every incident resulted from insufficient compute. Console reporting failures should not all be counted as inference API outages either. These delivery records are nevertheless enough for me to withhold a high rating for the company's engineering based on model scores alone.Official status page
Solving difficult benchmark problems and reliably meeting demand for a paid service are different capabilities. A company can promote the first while being held to account for the second. Slightly cheaper tokens do not compensate for the time lost when errors and interruptions break up a piece of work.
I see the pre-IPO cuts as price competition
This commercial context is another reason I am wary of the "stronger and cheaper" story. Reuters, reporting on a prospectus it had reviewed, said Anthropic recorded nearly $4.6 billion in revenue and more than $8 billion in operating losses in 2025, alongside substantial compute commitments. Its report also placed the Opus 5.5 launch in the context of competition with GPT-6 Astra and the expected IPO.Reuters report
In October, Reuters cited participants at an investor event as saying that third-quarter revenue reached $16.8 billion and that Anthropic told investors it was profitable for the quarter on an adjusted basis. The previous year's losses, adjusted profitability, and future spending commitments should be read separately.October 14 report
In this window, I am more inclined to interpret the price cuts as a commercial move to win market share and sustain growth expectations. Lower prices may attract more requests and customers, making the story of strong demand, expanding scale, and improving efficiency easier to sell to investors. There are commercial reasons for such a cut even without first establishing a comprehensive infrastructure breakthrough.
That is my criticism: why should users automatically turn a company's price competition into a technological victory, then count economies of scale that have not yet materialised as benefits already received? I have no evidence that Anthropic is dumping services below cost or deliberately deceiving customers, or that it will necessarily cut allowances later. I can still refuse to let this growth narrative serve as an endorsement of its service and pricing.
Opus 5.5's unit prices have fallen, and my usage mix is cheaper at the new rates. But the comparison baseline is Anthropic's own old pricing. Competitors' token consumption, users' task costs, and actual service reliability still need to be accounted for.
I still recognise Claude's model capabilities and am willing to pay for a useful product. My response to this price cut is simply not to declare a win for users too soon. The company needs to compete on price and sell a convincing IPO story; I need a tool that reliably finishes the work. There is no reason to assume those interests are the same.
- Title: Claude Opus 5.5 and the Myth of Cheaper AI: Engineering Progress or a Pre-IPO Price War?
- Author: AdenXie
- Created at : 2026-10-18 01:32:46
- Link: https://blog.adenxie.com.cn/2026/10/18/2026-10-18-claude-opus-5-5-pricing-myth/
- License: All Rights Reserved © AdenXie
