Pioneer, the summit where CX leaders redefine what’s possible, is on October 7th.

Join leaders from Fin, Anthropic, Clay, and Kalshi for an insightful conversation on the state of AI transformation.

You’ll discover how some of the most innovative minds in CX have transformed their organizations, learn how they think about CX, and hear how they're planning for what's next.

Join the conversation in San Francisco, or tune in virtually.

Reserve your spot

Opus 5.5 and GPT-6 Sol, explained through five diagrams about agents, caching, and the cost of finished work.

ResearchAudio.io · September 24, 2026

Imagine giving two agents the same bug. One produces a patch, passes review, and stops. The other needs three attempts. The second agent can have cheaper tokens and still leave you with the larger bill.

That is the useful question behind the launches of Claude Opus 5.5 and GPT-6 Sol: how much do you pay to get work you can actually accept? Here is the story in five pictures.

Published standard API prices. Cache writes, cache reads, special modes, and tool charges have separate economics.

Anthropic reports that Opus 5.5 generates output over 30% faster than Opus 5 and costs about 40% less on its typical-workload tests. That workload estimate combines pricing and token efficiency; it is not a promise for every application.

OpenAI positions Sol as a more affordable GPT-6 option for coding, tools, and professional work. Its input and output rates are half those of GPT-5.6 Sol's promotional prices.

The capability claims are worth testing, too. Anthropic reports 54.4% on FrontierCode v1.1 Main for Opus 5.5 at max effort. OpenAI reports 68.8% on DeepSWE v1.1 for Sol at max effort. These are different evaluations, so the percentages do not establish a head-to-head winner. See the linked launch pages for configurations.

Both releases make it worth rerunning your own evaluations. Neither price sheet tells you which model will finish your particular job with fewer corrections.

A simplified agent workflow. The application controls execution, verification, and when the loop stops.

A request to “fix the bug” can become many model calls. The agent reads files, proposes an edit, runs tests, examines failures, and tries again. Each pass can grow the context and produce more output. A sandbox or external API may also charge for the work it performs.

Keep failed and abandoned tasks in the numerator. Otherwise, a model that gives up cheaply can look efficient. Track human review time alongside the bill, because a patch that takes an hour to inspect may still be expensive.

Illustrative calculation using the published prices. It does not claim that either model needs a particular number of attempts.

Assume each attempt uses 100,000 input tokens and 10,000 output tokens. With no caching, Sol costs $0.30 and Opus costs $0.60. If Sol takes three such attempts and Opus takes one, the totals become $0.90 and $0.60.

If both finish in one attempt, Sol is cheaper in this example. At two Sol attempts, the token bills tie. Real attempts rarely have identical token usage, which is exactly why you should measure the full trace instead of estimating from the first call.

Try this: take 20 representative tasks from your backlog. Give both models the same tools, starting context, acceptance criteria, and budget. Compare accepted results, total cost, elapsed time, and reviewer minutes. Use multiple runs where practical to see how variable the results are.

The diagram isolates a stable prefix. Real conversations also accumulate history, and cache eligibility is provider-specific.

OpenAI's caching update adds diagnostics and explicit prefix breakpoints, with discounts of up to 90% on eligible cached input tokens. That discount applies to the cached input portion, not to the entire agent bill.

Put stable instructions and tool definitions where they can remain reusable. Keep changing content toward the end. Then inspect actual cache hits and billed usage. A large prompt is not automatically a well-cached prompt.

Proposed application architecture, not a claim that one model should always sit above the other.

Start with the model that meets your quality bar at the lowest measured cost. If it fails, use the failure to decide what happens next. Missing context may call for retrieval. A test failure may justify another attempt. A recurring reasoning failure may justify a different model.

Avoid treating every failure as a reason to buy more tokens. Set a retry limit and a spending limit. If the agent reaches either, stop and hand over the trace, the attempted changes, and the checks that still fail. Switching providers also requires separate cache and context handling.

Pick one recurring job: a small code fix, a document extraction task, or a workflow across two tools. Define what “done” means before running it. Then compare Sol and Opus on that job, including the attempts that fail.

The model to keep is the one that gets acceptable work done within your budget. These releases give you new candidates. Your traces tell you which one belongs in production.

Source pages checked September 24, 2026. Vendor statements are attributed. Calculations and routing policy are editorial analysis; no comparative model test was conducted.