Claude Opus 5.5 and GPT-6 Sol Both Cut the Same Price, and It Wasn't the Headline One
Two labs shipped models ninety minutes apart on September 22. Read past the benchmark tables and they made the same argument about where your money actually goes.
Anthropic's Claude Opus 5.5 page contains a sentence you do not usually see on a launch announcement. After listing benchmark scores where its new model leads on almost every row, the company writes that "benchmark margins have become a less reliable guide to real-world differences," and adds that in its own use, the gap between Opus 5.5 and Claude Fable 5.1 "is narrower than these scores suggest." A lab spent months training a model and then told you not to weight the scoreboard too heavily.
So what should you weight instead? Anthropic answers that in the pricing table, and the answer is one line item most people have never looked at.
Cache reads. They drop from $0.50 per million tokens to $0.20. That is a 60% cut. Input and output tokens fall from $5 and $25 to $4 and $20, which is 20%. The headline price moved a fifth; the number nobody talks about moved by three times as much.
Anthropic explains why in a parenthetical: cache reads "make up the majority of agentic and coding work costs."
Ninety minutes later OpenAI released GPT-6 Sol and GPT-6 Luna with a flat 50% cut against their GPT-5.6 predecessors, Sol to $2 input and $10 output per million and Luna to $0.10 and $0.50. Cached input reads carry a 90% discount. And alongside the price cut, OpenAI shipped three things that have nothing to do with intelligence: a prompt caching dashboard, a diagnostics tool that explains missed caching opportunities, and explicit breakpoints so developers can choose where a cached prefix ends.
Nobody ships a diagnostics tool for something that already works. That is the tell.
The thing both labs are admitting
Here is what I think happened, and I want to be clear it is a reading rather than a disclosure. Neither company says "your harness has been wasting your money." But look at what OpenAI actually fixed.
From their announcement: developers can now "increase reasoning effort for harder tasks or lower it for simpler follow-ups" and "enable or disable tools as your agent's needs change," and both of those "now preserve earlier context for cache reuse."
Read that backwards. Before today, changing reasoning effort mid-conversation broke the cache. Toggling a tool broke the cache. Those are not exotic operations. Those are the two most ordinary things an agent harness does on every task, over and over, for hours. Every time your orchestrator decided a subtask needed less thinking, or handed the model a narrower toolset for one step, it silently threw away the prefix and paid full freight to rebuild it.
You would never have seen this in your token count. The tokens were the same. Only the price per token changed, and the invoice did not itemize which of them were cache reads versus fresh reads at five times the cost.
GitHub gives a number for the scale of the fix: across billions of requests to OpenAI models, the caching improvements cut the share of prompt tokens requiring fresh processing by more than 50%.
More than half. That is not a rounding error in somebody's billing. That is half the prompt processing in one of the largest agent deployments on earth, being redone for no reason, until somebody looked.
What actually invalidates a cache
Anthropic's prompt caching documentation is more specific than its announcement, and it is worth reading for the list alone. The cache-debugging section tells you to verify that tool_choice, image usage, the thinking configuration, and output_config.effort "remain consistent between calls." A separate note states that changes to tool_choice, or the presence or absence of images anywhere in the prompt, will invalidate the cache and force a new entry.
Sit with that second one. Anywhere in the prompt. One image attached at turn three poisons the prefix for every turn after it.
Then there is the breakpoint rule, which is the one I suspect burns the most people. The docs say cache writes happen only at the breakpoint, and if that block changes, "the prefix hash never matches." They name the usual culprits directly: timestamps, per-request context, the incoming message. If you have a system prompt that ends with the current date, or a tool list your framework serializes fresh each call, you have been paying write prices forever and your hit rate is roughly zero.
And my favorite, because nobody would ever guess it: the docs warn that keys in tool_use content blocks need stable ordering, because "some languages (for example, Swift, Go) randomize key order during JSON conversion, breaking caches." Your cache hit rate can depend on your programming language's map iteration semantics. That is not a configuration problem you can reason your way to. You have to measure it.
The cache lifetime is 5 minutes by default, with a 1-hour TTL available. The minimum cacheable prompt is 512 tokens on Fable 5.1, Mythos 5.1, Opus 5.5, Opus 5, Fable 5 and Mythos 5, and 2,048 tokens on Mythos Preview and Opus 4.7. If your system prompt is short, you are not caching at all and no price cut helps you.
My position
The efficiency story is the real story of this release cycle, and the benchmark coverage is going to miss it almost entirely.
Anthropic puts the all-in cost drop at 40% on typical workloads at default settings, and that number comes from two separate effects stacked: cheaper tokens, and fewer tokens consumed per task. On their own charts, Opus 5.5 at default medium effort scores 54.6% on FrontierCode, higher than every other model listed, which the company says beats GPT-6 Astra's top score for roughly a fifth of the cost per task. Deloitte's quoted evaluation found the lowest effort setting caught 72% of known bugs against Opus 5's 56% at high effort.
If those hold up in your workload, the implication is not "models got 40% cheaper." The implication is that the max-effort default most of us adopted in 2025 out of caution has been, for a year, mostly waste. That is a harder thing to hear than a price cut.
The counterargument deserves a hearing: every one of those figures is a vendor's framing of a test the vendor designed or a quote from a customer the vendor selected for the launch page. None of it is independent. I take the direction seriously and the magnitudes not at all until I have run my own.
Put this into practice
Four steps, cheapest first. None of them requires switching models.
Measure before you change anything. Anthropic ships a cache diagnostics endpoint that compares consecutive requests and reports which part of the prompt diverged. OpenAI's new diagnostics tool does the equivalent on their side. Run it against a real agent session, not a toy one. You are looking for a hit rate, and if you have never measured it, assume it is worse than you think.
Find your unstable prefix. Check whether your system prompt or tool serialization contains anything that changes per request: a timestamp, a session ID, a user name, a counter. Pin it or move it after the breakpoint. This single fix is usually the difference between a 10% hit rate and an 80% one.
Audit where your harness toggles things. Every place your orchestrator changes tool_choice, swaps the tool list, or adjusts effort mid-conversation was, until this week, a cache flush. Some of those will now be free on the new models and some will not. Make a list of them and test each one rather than assuming the announcement covers your case.
Try default effort on a real task and compare the bill, not just the output. Take a task you currently run at max, run it at default, and compare three numbers: did it succeed, how many tokens did it burn, what did it cost. If the success rate holds, you just cut your bill by more than the price change did.
One more, if you are on Anthropic's API and running scheduled work: the docs describe a pre-warm request using max_tokens: 0, which reads your prompt, writes the cache at the breakpoint, and returns immediately with an empty content array and stop_reason: "max_tokens". It bills a cache write and zero output tokens. For a burst of parallel agents sharing a prefix, that is a way to pay for the write once instead of racing.
What I cannot tell you
I have not run Opus 5.5 or GPT-6 Sol against a production workload. Everything above about their performance is their measurement of their own model, and in several cases their measurement of a competitor's model, which is a category of evidence I would not accept from anyone else either.
I have not verified GitHub's "more than 50%" figure, and I cannot: it is a claim about GitHub's internal traffic that appears in OpenAI's announcement, with no methodology, no time window given beyond "the past several months," and no way for an outsider to check it.
The caching documentation I quote describes Anthropic's API behavior as documented, not as observed. I did not run an experiment to confirm that a Go map really does break a cache in practice, and the docs could be describing a hazard that is rarer than the warning implies.
I also have not resolved the most interesting contradiction on offer. Anthropic's documentation says output_config.effort must stay consistent between calls or you lose the cache. OpenAI's announcement says changing reasoning effort mid-conversation now preserves the cache. Those may be describing two genuinely different implementations, or Anthropic's docs may simply predate Opus 5.5. I could not tell from the pages, and I am not going to guess. If you depend on that behavior, test it rather than trusting either sentence, including mine.
And the largest limit is structural: both of these companies have an obvious interest in you believing their model is cheap per task, and cost per task is a much softer measurement than accuracy. It depends on your prompt, your harness, your effort setting, your retry policy, and your cache hit rate. Every one of those is something you control and they do not, which is exactly why the number is so easy to present favorably.
Where that leaves you
The price that moved most this week is the one that was never on your dashboard. Both labs cut it, both shipped instruments to watch it, and one of them said plainly that it is most of what agentic work costs.
You do not need to switch models to act on that. You need to find out what your cache hit rate is, which takes an afternoon, and then decide for yourself whether the model was ever the expensive part.
Sources: Anthropic, Claude Opus 5.5 · OpenAI, Introducing GPT-6 Sol and Luna · Anthropic prompt caching documentation
Medium metadata
- Title: Claude Opus 5.5 and GPT-6 Sol Both Cut the Same Price, and It Wasn't the Headline One
- Subtitle: Two labs shipped models ninety minutes apart on September 22. Read past the benchmark tables and they made the same argument about where your money actually goes.
- Tags: AI, Prompt Caching, LLM, AI Agents, Software Engineering
- Canonical: import from the fervorai.dev URL