A rate cut is real. A task price is still missing.
OpenAI introduced GPT-6 Sol and GPT-6 Luna on September 22. Anthropic released Claude Opus 5.5 the same day. The launches put new price cards beside new claims about capability and efficiency, giving developers an immediate reason to revisit model budgets.
For standard short-context API requests, OpenAI lists GPT-6 Sol at $2 per million input tokens and $10 per million output tokens. GPT-6 Luna is $0.10 and $0.50. The comparable promotional GPT-5.6 rates were $4 and $20 for Sol, and $0.20 and $1.20 for Luna. Anthropic lists Opus 5.5 at $4 per million input tokens and $20 per million output tokens, down from Opus 5 at $5 and $25.
Those are meaningful price changes. For an unchanged token trace, using the same endpoint conditions and cache behavior, lower rates reduce the API bill. But “unchanged” carries most of the analytical weight. A coding agent or business workflow does not send one fixed prompt and stop. It reads context, calls tools, receives results, reasons again and sometimes retries. Each run can produce a different mix and amount of billable input and output.
That leaves three different measures: the rate per token, the API spend for one run, and the cost of a task that passes a defined acceptance check. A lower rate guarantees none of the latter two if the run consumes more tokens, needs more attempts or succeeds less often.
Simon Willison’s launch-day comparison of Opus 5.5, Sol and Luna is a useful starting point because the releases arrived close together while a reliable read on new models still takes evaluation. The question for a buyer is what the headline prices—and the first task-cost claims—can establish before independent, comparable results exist.
The rate card has more than one line
The headline prices also leave out how context and caching change the bill. OpenAI’s API pricing distinguishes short-context from long-context use. Its published standard rates for GPT-6 Sol rise from $2 input and $10 output per million tokens in the short-context tier to $4 and $15 in the long-context tier. Luna’s listed rates rise from $0.10 and $0.50 to $0.20 and $0.75. Cached reads and cache writes have separate prices as well.
| Model | Short-context input | Cached input read | Output | Important condition |
|---|---|---|---|---|
| GPT-6 Luna | $0.10/M | $0.01/M | $0.50/M | Long-context rates are higher |
| GPT-6 Sol | $2/M | $0.20/M | $10/M | Long-context rates are higher |
| Claude Opus 5.5 | $4/M | $0.20/M | $20/M | Cache writes have separate duration-based rates |
Prices are per million tokens. OpenAI’s standard long-context rates are $0.20/$0.02 cached/$0.75 output for Luna and $4/$0.40 cached/$15 output for Sol. Anthropic prices an Opus 5.5 cache read at $0.20 per million tokens, five percent of its standard input rate; cache writes cost more and depend on whether the cache lasts five minutes or an hour. The table is a snapshot of listed rates, not a universal estimate of what a workflow will pay.
OpenAI says its caching changes can provide a 90% discount on cached input reads. It also reports that GitHub saw the share of prompt tokens requiring fresh processing fall by more than half across billions of requests. Those are company-reported figures. They do not tell every customer what share of its own prompts will be cache hits. That depends on whether an application repeats the same prefixes, how long the cache lasts and how the workflow is built.
One pricing detail also deserves care: OpenAI describes the new rates as a 50% reduction against GPT-5.6 promotional pricing. Sol’s listed input and output rates are half the old promotional prices. Luna’s input rate is half, while its listed output rate falls from $1.20 to $0.50 per million tokens. Readers comparing a specific workload should use the actual input, cache and output lines rather than assume every component changes by the same percentage.
Why task-cost claims do not line up yet
Both companies now publish task-cost results alongside token prices. OpenAI reports results for benchmarks including AutomationBench, FrontierCode, DeepSWE and OSWorld. On AutomationBench, it lists GPT-6 Sol at xhigh effort with a 33.2% score and a $0.27 task cost. The company also compares models at different effort settings and notes that a Claude Fable 5.1 comparison omits fallback costs. Some competitor results come from public reports rather than runs under one common setup.
Anthropic’s Opus 5.5 results use adaptive thinking, usually at maximum effort, with test-specific exceptions. Its announcement gives standard-error ranges for several comparisons. For AutomationBench, Zapier ran and reported the results; Anthropic says safeguard interventions counted as failures and that the early-access run did not use the same setup as public leaderboard results. Anthropic also attributes a 40% cost reduction against Opus 5 to a combination of lower token rates and fewer tokens per task.
These are useful signals, not a shared price-performance contest. The conditions matter: model effort, harness, task set, price date, safety behavior and whether retries or fallback models are counted. A benchmark can show what happened under its own rules. It cannot settle how much a different company will pay to complete its own workflow.
I would not discard vendor task-cost data; it makes the right unit of comparison visible. But I would not combine the two companies’ reported cents-per-task figures into a single ranking. Even the same benchmark name can hide different run dates, model versions and failure accounting. Until those variables match, a cross-vendor winner would be more precise than the evidence.
The workload changes the token count
Independent research helps explain why a rate card is not a task estimate. A Stanford Digital Economy Lab working paper studied agent trajectories from eight earlier frontier models on SWE-bench Verified. In that coding benchmark, the authors found that input tokens drove more of the aggregate cost than output tokens. Repeated runs of a task could use up to 30 times as many tokens as one another, and higher token use did not reliably bring higher accuracy.
A separate August preprint examined 2,700 Kimi K3 coding runs at three reasoning-effort settings. The author found that reducing a full task specification to a bare user story raised token use by an average of 29.7%; prompt sensitivity varied substantially by task. This is one model and an initial study, not evidence that GPT-6 or Opus behaves the same way. It does show why two teams can send the same nominal task to a model and receive very different bills when their instructions and workflows differ.
Neither study tests the September releases. Their relevance is narrower: task definitions, context sent back to the model and repeated runs can move token volume enough to affect the bill. A new model could use fewer tokens for the same accepted work, more tokens to reach a similar result, or a different mix depending on the harness. We do not yet have a public shared study that answers those questions for Sol, Luna and Opus 5.5.
The arithmetic gives one simple check. If a token rate falls by half, token use can double before the token bill returns to its old level, assuming the same input/output mix and cache conditions. That is not a prediction about these models; it is the threshold a buyer can test against its own traces. Success rates complicate it further: if a cheaper run fails more often and must be repeated or reviewed, the cost per accepted result may rise even as the cost per attempt falls.
What a buyer should measure
A useful model comparison starts with a representative set of tasks and a clear definition of success. Run each model through the same harness, tool permissions and task specification. Record the exact model version, effort setting, price date, context size, cache policy, input and output tokens, retries, fallback calls, latency and whether a person had to correct the result.
Then report the total API charges across all attempts divided by the number of independently verified successful tasks. Keep human review and operational time visible as separate parts of total ownership cost; do not quietly fold them into a token price. Report a distribution of results as well as an average, so unusually long or failed runs do not disappear inside one blended number.
A team should also compare at the quality it actually needs. An inexpensive model that passes a bounded extraction check may be the right choice for that task. A long coding migration may justify a higher token rate if the model finishes with fewer retries and less review. Neither result makes one model the best default everywhere.
This is where the September pricing moves can help immediately. Lower input and output rates reduce the cost of fixed-volume calls, and lower rates can make controlled experiments or high-volume, well-bounded tasks cheaper to run. A stable repeated context may benefit from cache pricing. These are practical advantages, even before anyone can claim a general task-cost winner.
The new baseline is lower; the verdict is not in
The September 22 releases reset what buyers can pay per token for several capable closed models. They also make cost per completed task a more urgent product question: both providers are publishing it, but in ways that still leave gaps in cross-vendor comparison.
My decision standard is straightforward. Treat the posted rates as real budget inputs and test them against your own workload. Treat broad savings claims as provisional until the model, task, quality bar, effort, caching and failure accounting are comparable. The next useful evidence is not another isolated rate cut; it is a public or customer-run comparison that shows token traces and verified outcomes under the same conditions.
For now, buyers have a lower price ceiling to work with, not proof that delegated work costs less. That is enough to justify a measured trial. It is not enough to change a production default on price alone.