GPT-6 Sol vs Claude Opus 5.5: Price, Benchmarks, and the Comparison Nobody Actually Ran

You have a model id in a config file and a decision to make this week. On September 22, 2026, OpenAI shipped GPT-6 Sol and Anthropic shipped Claude Opus 5.5, hours apart. Every comparison table you found since then has a hole in it, and the hole is bigger than it looks.

Here is the hole. OpenAI’s launch post benchmarks Sol against Claude Opus 5, because Claude Opus 5.5 did not exist when that post was written. Anthropic then released Opus 5.5 the same day at 20% below Opus 5 pricing. So the headline claim developers are quoting at each other, that Sol matches or beats Opus-tier quality for a fraction of the cost per task, was measured against a model that was superseded within hours of the measurement being published.

That does not make OpenAI’s numbers wrong. It makes them dated in a specific way, and knowing how dated is the difference between a good routing decision and an expensive one. Below: what each vendor published, where the two benchmark sets genuinely touch, what the price gap is once caching is involved, and how to test both against your own endpoints.

For the wider picture of three frontier launches inside two days, see the September 2026 AI model price war.

The spec sheet, side by side

Two rows carry most of the decision.

On raw tokens, Sol is exactly half the price of Opus 5.5 on both input and output. Not roughly half. Half. That is unusually clean for a cross-vendor comparison and it makes the mental math easy.

On the Artificial Analysis Intelligence Index, a third party score rather than a vendor claim, Opus 5.5 sits at 58 and ranks first of 212 models while Sol sits at 48. So the shape of this matchup is familiar: you pay double for the top of the leaderboard, and the question is whether your workload notices.

Sol’s context window is 872,000 tokens against Opus 5.5’s full million. For most work that never comes up. If you push an entire monorepo or a 400-endpoint OpenAPI document plus history into one call, measure it first, because the failure mode is a hard rejection rather than degraded output.

Availability matters too. Sol reached the API plus ChatGPT Work and Codex for Plus, Pro, Business, Enterprise and Edu accounts, and is not in Chat yet. Opus 5.5 shipped across Claude Platform, AWS, Google Cloud and Azure on day one, which is the difference between a procurement conversation and a config change if you already route through Bedrock or Vertex.

The comparison OpenAI could not run

OpenAI’s own cost-per-task figures are the most useful part of its launch post, and they all point at Opus 5:

Read the AutomationBench row again. Sol at extra-high reasoning beat Opus 5 at max reasoning for roughly 9% of Opus 5’s cost per task. That is the number doing all the work in the discourse.

Now put Opus 5.5 next to it. Anthropic published its own AutomationBench figure for Opus 5.5: 40.0%. OpenAI measured Opus 5 at 26.9% on AutomationBench 1.0.6. If those are the same benchmark at the same version, and that is a real if, then the Opus number Sol beat by 6.3 points has been replaced by one that leads Sol by 6.8 points. The comparison did not just age. It inverted.

Two caveats that you should carry into any argument about this:

1. OpenAI names the version, 1.0.6. The Anthropic figure we have does not carry a version string. Same-name benchmarks drift between releases, and harnesses differ between labs. Treat the 26.9 to 40.0 jump as directional until someone runs both models on one harness.
2. OpenAI still states plainly that GPT-6 Astra “continues to be our best model across the board.” Sol is the value tier of the GPT-6 family, not its ceiling, so drawing conclusions about OpenAI’s frontier from a Sol comparison is a category error. The frontier-to-frontier read is Astra against Opus 5.5, and neither vendor has published it.

There is one more overlap. Anthropic reports Opus 5.5 at 81.8% on OSWorld 2.0, while OpenAI reports Sol at 60.5% on OSWorld 2.0 offline. Those may be different variants of the same suite, and a 21 point gap is exactly the kind of number that turns out to be an apples-to-oranges artifact. Do not quote it as a head-to-head.

What the price gap really is

The per-token gap is a clean 2x. The gap you actually pay is not, and prompt caching is why.

Opus 5.5 reads cached input at $0.20 per million tokens, which is 5% of its $4 input rate. GPT-6 shipped a caching release alongside Sol that discounts cached input reads by 90%, which puts Sol’s cached reads at $0.20 per million as well. On the repeated prefix, the part of an agent prompt that never changes, the two models cost the same.

Take a concrete agent workload: 50,000 input tokens per run, 3,000 output tokens, 1,000 runs a day, with 45,000 input tokens being a stable prefix (system prompt, tool schemas, OpenAPI document, conventions file).

That is arithmetic on published rates, not a measurement, and it excludes cache writes, where Opus 5.5 charges $5 per million and Sol’s write rate is not published in what we have. The direction is reliable: the harder you lean on caching, the more the cheap model’s advantage compresses, because the discount lands on the same floor for both. Aggressive cachers are buying a 1.8x gap, not a 2x one.

Cost per token is the wrong unit anyway. OpenAI’s own internal numbers explain why: its median researcher spends over $600 a day on coding agents, and the 90th percentile spends $7,000 a day. Nobody reaches that by mispricing tokens. They reach it by running loops that retry, branch and re-read context. A model that costs double but finishes in one pass instead of three is the cheaper model.

One more piece of price context, because it gets misquoted constantly. OpenAI describes Sol and Luna as 50% cheaper than GPT-5.6 promotional pricing. Promotional is OpenAI’s own word. Against the GPT-5.6 list prices that we documented at the time in our GPT-5.6 pricing breakdown, Sol at $2/$10 is a larger cut than the headline suggests, but the headline itself is measured off a discount, not a list rate. Quote it with the qualifier attached.

Latency: the cheap model is not the fast model

Artificial Analysis measured the “max” reasoning variant of GPT-6 Sol at 115.2 output tokens per second with a 102.15 second time to first token. That is a third party measurement of the highest reasoning setting, not a vendor figure, and not representative of Sol at lower effort. Treat it as a ceiling on how bad it can get, not as a typical response time.

It still changes how you build. A hundred seconds before the first token means:

• Your default HTTP client timeout is wrong. Most libraries default to 30 or 60 seconds.
• Any load balancer, API gateway or serverless function sitting in front of the call has its own idle timeout, and it is probably shorter than your client’s.
• Streaming stops being a nicety. Without it you have no signal that the request is alive.
• Retry logic that fires on timeout will double your bill and your latency at the same time.

Anthropic’s comparable claim for Opus 5.5 is relative: 30% faster output than Opus 5. That is a vendor statement about a ratio, not a tokens-per-second figure, so it cannot be placed on the same axis as the Artificial Analysis numbers. You will have to measure both against your own workload.

This is ordinary API testing work. Send the same prompt to both endpoints, record time to first byte and total duration across enough runs to see the spread, and assert on the response schema while you are there. In Apidog you can keep both calls in one project, run them as a test scenario, and hold the latency history next to the assertions instead of in a scratch file.

The two request shapes differ enough to matter:

# Anthropic
curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1024,
    "stream": true,
    "messages": [{"role": "user", "content": "Summarize this OpenAPI path."}]
  }'

# OpenAI
curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "gpt-6-sol",
    "stream": true,
    "input": "Summarize this OpenAPI path."
  }'

Different auth headers, different body keys, different streaming event formats. Any abstraction layer you write to swap between them is code you now own, and it breaks first when either vendor ships a new field.

How to choose

For most teams the last row is the honest answer. At a 1.8x cached price gap, routing pays for itself faster than either vendor’s marketing does. Send the high-volume, well-specified work to Sol and the long, ambiguous, expensive-to-get-wrong work to Opus 5.5. Measure cost per completed task, revisit in a month, and do not copy a benchmark table out of either launch post and treat it as current. One of them compares against a model that was replaced the same afternoon.