Two frontier-model launches landed on September 22 with the same pitch: more useful work for less money. Anthropic released Claude Opus 5.5; OpenAI released GPT-6 Sol and its smaller sibling, Luna. If you run coding agents, the obvious comparison is dollars per million tokens. It’s also the least useful comparison on its own. An agent rereads a repository, calls tools, retries failed steps, and sometimes hands a task back to a human. The number worth comparing is cost per correctly completed task, not cost per token generated.
That distinction matters because the companies are discounting different things. Anthropic says Opus 5.5 needs fewer tokens to finish typical work and charges less for cached context. OpenAI has cut Sol’s token prices and changed when its prompt cache can be reused. Neither announcement tells you which model will finish your backlog more cheaply.
What the September 22 Releases Actually Cost#
At standard API rates, Anthropic prices Opus 5.5 at $4 per million input tokens and $20 per million output tokens. That’s 20% below Opus 5’s per-token prices. Anthropic also lists cache reads at $0.20 and cache writes at $5 per million tokens, and estimates that fewer tokens per task bring the overall cost down roughly 40% versus Opus 5 on its typical workloads. That’s a vendor estimate, not a 40% price cut guaranteed on every job. Opus 5.5’s optional fast mode costs $8/$40 per million input/output tokens instead.
OpenAI prices GPT-6 Sol and Luna at $2/$10 and $0.10/$0.50, respectively, per million input/output tokens. OpenAI describes those as cuts of at least 50% relative to its GPT-5.6 promotional prices. Luna is a different, cheaper capability tier; its price doesn’t make it a like-for-like alternative to Opus 5.5 for a difficult coding migration. Sol is the closer starting point for an agent evaluation, but even that comparison needs to be made on a shared task set.
| Model | Input / 1M tokens | Output / 1M tokens | What the headline omits |
|---|---|---|---|
| Claude Opus 5.5 | $4 | $20 | Cache reads/writes, optional fast-mode pricing, task length |
| GPT-6 Sol | $2 | $10 | Cache reuse, reasoning effort, task length |
| GPT-6 Luna | $0.10 | $0.50 | Whether it can finish the same tasks at all |
As a deliberately simplified example, a single request with 100,000 fresh input tokens and 20,000 output tokens costs $0.80 on Opus 5.5 or $0.40 on Sol at those standard rates. That arithmetic assumes identical token counts, no caching, no retries, and no other charges. It is not a prediction of what an agent session will cost: a model that needs half as many calls can beat a cheaper model on the total bill.
The Cache Is Part of the Product#
Coding agents repeatedly send the same system instructions, tool definitions, repository context, and conversation history. A high cache-hit rate turns much of that repeated input into discounted reads; a small change to the reusable prefix can turn it back into full-price input. This is why AI efficiency increasingly depends on the surrounding workflow, not only on smaller or faster models.
Anthropic’s concrete lever is a $0.20-per-million cache-read price, down from $0.50 on Opus 5. OpenAI says GPT-6 cached input can receive discounts of up to 90%, but the realized saving depends on eligibility and reuse. Its new GPT-6 caching controls add a dashboard, miss diagnostics, and explicit breakpoints. OpenAI also says you can change reasoning effort between responses without breaking reuse when you use its configuration_update mechanism; for tools, keeping definitions stable and adjusting which are allowed avoids unnecessary cache invalidation. Simply changing tool schemas or request settings without following those conditions can still cause a miss.
The interesting metric is therefore not just “tokens in.” Record fresh input, cached input, output, cache writes where billed, and cache misses per successful task. Test cold and warm runs separately. Otherwise a benchmark that starts every agent with a warm context will make an expensive production workflow look artificially cheap—or a cold-only test will miss the economics of long-running sessions.
Anthropic’s Fallback Changes What You’re Measuring#
There is a second complication that a price table cannot show. Anthropic says Opus 5.5’s safeguards can transparently reroute requests to other Claude models: most flagged cybersecurity tasks go to Opus 4.8, while flagged biology and frontier-model-development tasks go to Opus 5. Anthropic says routine software work, including identifying and fixing bugs in your own code, remains possible. This is a safeguard for particular requests, not a claim that ordinary coding sessions routinely fall back.
For a security-heavy agent evaluation, though, you cannot automatically assume every answer came from the model you selected. Compare outcomes on the actual task mix and note any routing information the platform exposes; if it doesn’t expose enough to separate routed requests, state that limitation. Do not infer a different charge or a particular fallback rate without billing data. The question is more basic: are you measuring a stable model, or a product that may change models during a workflow? Readers of my earlier GPT-6 Astra cybersecurity analysis will recognize the trade-off between capability and safeguards, but here it directly affects how to interpret an agent benchmark.
Why the Benchmark Charts Don’t Settle It#
The vendors’ launch comparisons do not provide a controlled Opus 5.5-versus-Sol answer. OpenAI’s release comparisons use older Claude models; Anthropic’s published tests use its own harnesses, effort settings, and pricing assumptions. Anthropic explicitly cautions that small benchmark margins do not necessarily translate into noticeable real-world differences. Those results are useful leads for choosing what to test, not evidence that one model is universally cheaper per completed task.
Run a small evaluation on your own work instead:
- Pick 20 representative tasks: a bug fix, a failing test, a dependency update, a refactor, and at least one genuinely long-running change. Define acceptance checks before running either model.
- Give both agents comparable repository access, tools, time limits, and review rules. Record the model and effort setting; don’t compare a fast mode with a standard mode without saying so.
- Count a task as complete only when its tests and review criteria pass. Track total API spend, fresh and cached tokens, retries, elapsed time, and human intervention per accepted task, not per successful API call.
- Repeat cold and warm-context runs, then inspect failures separately. If one agent is cheap because a human repeatedly repairs its output, include that time in the decision even if it isn’t on the API invoice.
This is the same discipline that makes an AI code-review tool worth evaluating: the number of suggestions is less important than the number of correct, actionable changes that survive review. And for a closed-set routing or classification step, it may be cheaper to use neither frontier model at all—purpose-built decision models are a useful reminder to test whether the task needs generation in the first place.
My Take#
Sol’s lower standard token prices make it the first model I’d trial for high-volume, routine agent work. But I would not migrate a production coding pipeline on that basis alone. If Opus 5.5 finishes a difficult change with fewer turns, fewer repairs, or a higher acceptance rate, the more expensive token can buy the cheaper outcome. OpenAI’s cache controls and Anthropic’s cheaper cache reads both make that result highly dependent on how the agent is built, not just which model sits behind it.
The uncomfortable implication of these simultaneous launches is that the model leaderboard is becoming a poor purchasing tool. Over the next quarter, teams that measure accepted changes per dollar and hour, including cache misses and human cleanup, will make better decisions than teams that negotiate the lowest token rate. Pick the workflow first, make success measurable, and let the invoice and the merged diff—not either company’s launch chart—decide the winner.
