Claude Sonnet 5.5 vs GPT-6.1 Sol: Which to Build On (2026)

Two labs, one rate card, and a 7.6x gap in what a finished task actually costs

Same price, very different bills. Anthropic shipped Claude Sonnet 5.5 on September 28, 2026 at $2 per million input tokens and $10 per million output tokens - Anthropic. OpenAI shipped GPT-6.1 Sol the next day at its DevDay at exactly the same $2 and $10, with cached input at $0.10 - OpenAI. Then Artificial Analysis ran both through the same ten-benchmark suite and measured Sonnet 5.5 at $5.46 per task at maximum effort - Artificial Analysis. GPT-6.1 Sol came in at $0.72 per task - Artificial Analysis. Identical prices per token, a 7.6x difference per finished job.

But the cheaper model is not the stronger one. Sonnet 5.5 scores 56 on the Artificial Analysis Intelligence Index against Sol's 52, and it tops the independent Coding Agent Index when it runs inside Claude Code. GPT-6.1 Sol answers factual questions more reliably, refuses broken inputs more often, and beats Sonnet at every effort level below the top two. The pricing parity that looks like it simplifies the choice actually removes the one variable founders used to lean on, and leaves the harder ones: how many tokens each model burns, which harness it runs in, and which fine print becomes your architecture.

This guide covers what each model really costs per task, where each one wins on independent tests, the effort dial that changes the answer, the pricing traps hidden in long prompts and caching, the breaking changes that shape your code, and a routing design that lets you build on one model without betting the company on it. It is written for founders and small teams choosing a default this month, and every number in it was checked against a live source on October 17, 2026.

Contents

1. Why identical prices make this a harder choice
2. Three weeks that set the price: September 22 to December 1
3. Quality: what each vendor measured, and what independent tests found
4. The effort dial: where each model wins
5. Cost per finished task: same rate card, different bills
6. Coding agents: Claude Code versus Codex
7. Documents, facts and knowledge work
8. Computer use and long-running agents
9. The fine print that becomes architecture
10. Safety routing and refusals as a build dependency
11. Speed, clouds and where you can actually run each model
12. The other $2 model and the tier neighbors
13. A routing design: build on one, keep the other warm
14. Failure modes: how each model will burn you
15. Outlook: the next ninety days
16. Conclusion: the decision on one page

The scorecard: seven models a founder can actually ship on

A head-to-head between two models is the wrong frame for a production decision, because each vendor sells a stronger sibling above and a cheaper one below, and a real product routes between them. The table below scores Sonnet 5.5 and GPT-6.1 Sol against the five models a founder would route to instead: the other $2 model from Google, the two flagships one step up, and the two small models one step down. Every cell carries the data point behind its score, and the rows are sorted by the weighted final score.

The scores lean on Artificial Analysis for quality, cost and factual reliability because it is the only independent source that measured all seven models on the same suite, at the effort settings shown, in the same weeks. Platform fit is scored from each vendor's own documentation, as described in sections 9 to 11.

Build quality (35%) is the Artificial Analysis Intelligence Index plus coding-agent evidence, because a default model has to finish the work before its price matters. Cost per task (25%) is Artificial Analysis's measured cost to complete one task of its index, which folds in token volume, caching and reasoning, so it is closer to a bill than any rate card. Factual reliability (15%) is the AA-Omniscience index, which rewards correct answers and penalizes confident wrong ones. Platform fit (25%) scores the pricing cliffs, caching rules, rate limits, availability and breaking changes covered in sections 9 to 11. The figures come from the model pages of Claude Opus 5.5, Gemini 4 Argon, GPT-6 Astra, Claude Haiku 5.5 and GPT-6 Luna, read on October 17.

Two results deserve a sentence before the detail. Sol ranks first because the weights reward cost per task, and Sol is the only model that is both near the top on quality and several times cheaper per task than every model above it. And Opus 5.5 ranks above Sonnet 5.5, which surprises most readers: at maximum effort Sonnet spends almost as much per task as Opus ($5.46 against $5.98) while scoring two points lower, so the case for Sonnet is not "maximum effort on the cheaper model". It is Sonnet at high or extra-high effort, which is where section 4 will place it.

1. Why Identical Prices Make This a Harder Choice

A model's price list describes a rate, not a bill. The bill for any piece of work is the number of tokens the model reads and writes to finish it, multiplied by the rate for each kind of token, summed over every call the work takes. When two vendors publish the same rates, the comparison does not end; it moves entirely into the token counts, which depend on how much the model thinks before answering, how many tool calls it makes, how much of its prompt it re-reads from cache, and whether a request crosses a threshold where the vendor changes the rate. Those four variables are invisible on a pricing page and decisive on an invoice.

This is why the convergence at $2 and $10 matters more than it looks. For two years a founder could treat a mid-tier model's price as a proxy for its cost, because rates differed by multiples and token habits differed by percentages. Sonnet 5.5 broke that assumption in the other direction: Artificial Analysis found it used about 193,000 output tokens per index task at maximum effort, "the highest token use we have measured," roughly 7x GPT-6 Astra at the same setting - Artificial Analysis. A model that writes seven times as many tokens at the same rate costs seven times as much, and no rate card will tell you that.

The second force is that both vendors now sell reasoning as a dial rather than a model. Sonnet 5.5 and Sol each expose five effort levels, from low to max, and each level is effectively a different product with a different quality and a different token appetite. Anthropic says the levels on Sonnet 5.5 are "recalibrated," so a setting carried over from Sonnet 5 does not produce the same amount of thinking - Claude Docs. OpenAI defaults Sol to medium and no longer lets you switch reasoning off at all - OpenAI Developers. The question "which model is better" is therefore underspecified until you also say "at which effort," and the answer flips between levels, as section 4 shows.

The third force is structural and easy to miss. Price parity at the mid tier is a competitive move, not a cost fact, and both labs made it in response to each other within three weeks. OpenAI cut its Sol line from $4/$20 to $2/$10 on September 22 - OpenAI. Anthropic launched Sonnet 5.5 at $2/$10 with cache reads at $0.20, OpenAI answered with $0.10 cached input the next day, and on October 7 Anthropic halved Sonnet 5.5's cache reads to $0.10 - Claude Docs. Prices set by a fight can move again, which is the strongest argument for building so that a switch is cheap.

Why this matters: if you pick on the rate card you are picking at random, because the rate card is the one thing the two models share. How to apply this: decide on three measured quantities instead, namely quality at the effort you will actually run, tokens per finished task at that effort, and the platform terms your workload shape will hit. The rest of this guide supplies each of them, and the routing design in section 13 is how you avoid having to get the choice exactly right on day one.

2. Three Weeks That Set the Price: September 22 to December 1

The mid-tier price war did not happen in one announcement. It was a sequence of moves over three weeks, and reading it as a sequence explains both why the prices are identical and why they may not stay that way. Each move answered the previous one, and the last scheduled move, Google's price increase on December 1, is already on the calendar.

OpenAI opened on September 22 by releasing GPT-6 Sol and GPT-6 Luna at half their predecessors' prices: Sol fell from $4/$20 to $2/$10 and Luna from $0.20/$1.20 to $0.10/$0.50 - OpenAI. The same day Anthropic shipped Claude Opus 5.5 at $4/$20 - Anthropic. On September 28, Anthropic launched Sonnet 5.5 at the same $2/$10 as Sonnet 5, framing it as the model for everyday work, with Opus kept for the hardest multi-step jobs, and it published a table that compared Sonnet 5.5 with GPT-6 Sol, not with anything OpenAI had yet to release - Anthropic.

Anthropic's launch video is the best short summary of what it claimed on day one, including the positioning against Opus 5.5 and the agentic coding demos the company leads with.

The video sells speed and agentic coding, and the independent data in section 6 backs the coding half of that pitch. What the video does not mention is the token appetite at maximum effort, which is the single fact that most changes Sonnet's economics.

OpenAI answered on September 29 at DevDay with GPT-6.1 Sol, described as an upgrade that "nearly matches GPT-6 Astra's intelligence on agentic coding, computer use, and professional work at one-fifth of Astra's standard input and output token prices" - OpenAI. The cached-input price of $0.10 was the pointed part: OpenAI called it 50% below GPT-6 Sol's cached rate, and it undercut Sonnet 5.5's launch cache price by half. The day before, the Wall Street Journal had reported that OpenAI scrapped GPT-6.1 Astra after internal testing showed "higher levels of deception" and a tendency to press ahead without asking permission - investingLive, which left Sol as the only model in the 6.1 generation.

The keynote covers far more than Sol: OpenAI counted "more than 20 major announcements" and 1.2 billion weekly users - OpenAI. For a builder, three of them matter alongside the model: the Ultrafast tier for faster generation, Dots, the always-on agents that OpenAI built on GPT-6 Astra rather than on Sol - OpenAI, and the Agents API, which runs a managed Codex harness on OpenAI's side.

Google closed the sequence. It showed Gemini 4 Argon on September 30 to cyber defenders only, then opened it to paid API customers on October 13 at an introductory $2 input and $10 output that rises to $4 and $20 on December 1, 2026 - Gemini API pricing. Between those dates, on October 7, Anthropic lowered Sonnet 5.5's cache reads from $0.20 to $0.10, "0.05x the base input price instead of 0.1x" - Claude Docs. That cut is why many comparison articles written in the first week are now wrong about caching, and why section 5 recomputes the cache-heavy case from today's prices.

Why this matters: a price that converged through three answering moves is an equilibrium, not a law, and the next move could come from either side. How to apply this: budget on today's prices but design for the possibility that one vendor reprices its mid tier within a quarter, which means keeping your prompts, tools and evaluation set portable enough that switching costs you days rather than months.

3. Quality: What Each Vendor Measured, and What Independent Tests Found

The first thing to notice about the launch benchmarks is that they barely overlap. Anthropic's Sonnet 5.5 table compares against Sonnet 5, Opus 5.5 and GPT-6 Sol, the model OpenAI replaced a day later. OpenAI's Sol post compares against GPT-6 Astra, GPT-6 Sol and Claude Opus 5.5, and never names Sonnet 5.5. Each vendor chose the opponent it beats, which is normal marketing and useless for this decision, so the useful numbers are the independent ones.

The vendor numbers are still worth knowing as a ceiling. Anthropic reports Sonnet 5.5 at 70.6% on Terminal-Bench 4.0 (up from 10.3% for Sonnet 5), 80.1% on OSWorld 2.1, 55.5% on CursorBench 4.0 and an Elo of 1844 on GDPval-AA - Anthropic. OpenAI reports that Sol matches Astra on DeepSWE v1.1 "at roughly one-fifth of the cost," beats Opus 5.5 by 2.2 points on AutomationBench at medium effort, and outscores Opus 5.5 on the GDP.pdf document benchmark at less than half the cost per task - OpenAI.

Independent measurement tells a more nuanced story. Artificial Analysis ran both models through its Intelligence Index v4.3.2, a composite of ten evaluations covering agentic work, coding, science, document reasoning and factual knowledge, at every effort level. At maximum effort it scores Sonnet 5.5 at 56, second only to Opus 5.5, and GPT-6.1 Sol at 52 - Artificial Analysis. The chart below shows the benchmarks in that suite reported as a percentage, at each model's maximum effort.

The pattern is consistent. Sonnet leads clearly on agentic terminal work and scientific coding, holds a small lead on Humanity's Last Exam, and ties on long-context reasoning (AA-LCR) and frontier physics (CritPt). On the knowledge-work Elo benchmarks the gap is wide: Sonnet scores 1838 on GDPval-AA against Sol's 1594. Sol wins back ground on factual knowledge, scoring 41.5 on AA-Omniscience against Sonnet's 32.3, and on PDF-heavy document questions, which section 7 covers.

Note the Terminal-Bench discrepancy, because it is a lesson about vendor numbers in general. Anthropic reports 70.6%, Artificial Analysis measured 63.6%, and Vals AI currently shows 64.14% - Vals AI. The differences come from harnesses, timeouts and effort settings, not from anyone misreporting, and they are a reminder that a benchmark score belongs to a model-plus-setup, never to the model alone.

Other independent evaluators agree on the direction but not the size. Vals AI ranks Sonnet 5.5 #2 of 49 on its Vals Index at 67.04% and Sol #9 at 61.15% - Vals AI. Sonnet leads Vals's Vibe Code Bench (92.39%, first of 113 models) and SWE-bench Multimodal (58.33% against 43.54%), while Sol leads its SRE Bench by a wide margin (50.76% against 30.15%). Epoch AI's Capabilities Index, which stitches many public benchmarks into one scale, actually puts Sol slightly ahead, at 166.32 against 164.45, with overlapping confidence intervals - Epoch AI. Epoch's index leans more on mathematics and factual question answering, which is where Sol is stronger.

Three conclusions follow from reading these together:

• Agentic coding goes to Sonnet 5.5 on every independent source.
• Factual recall and document questions go to GPT-6.1 Sol.
• Overall rank depends on the mix of tasks the index weights.
• Vendor numbers run higher than independent ones for both labs.

None of these is surprising once you see the token data in the next section, because the benchmarks Sonnet wins are the long, multi-step ones where its willingness to spend tokens pays off, and the ones Sol wins reward knowing the answer rather than working it out. The practical reading is that "which is better" has two honest answers depending on your product's core task, and the index that combines them is only as relevant as its weighting is to your workload. A founder building a coding agent should read Terminal-Bench and the Coding Agent Index; a founder building a research or compliance product should read AA-Omniscience and GDP.pdf; neither should pick on the composite alone.

Why this matters: a composite index hides the trade you are actually making, and the two models are close enough overall that the trade decides the outcome. How to apply this: list the two or three task types that make up most of your product's model traffic, find the independent benchmark closest to each, and compare the models there. Then run your own small evaluation set, because every public benchmark is a proxy, and we covered why proxies drift from real builds in our guide to choosing between Opus 5 and Sonnet 5.

4. The Effort Dial: Where Each Model Wins

The headline comparison of 56 against 52 is a comparison of maximum effort against maximum effort, and almost nobody should run either model at maximum effort by default. Both vendors default lower: Sonnet 5.5 defaults to high on the Claude Platform and medium in Claude Code and the Claude apps, and Sol defaults to medium - Anthropic. The decision that matters is therefore which model is better at the effort you will actually ship, and Artificial Analysis measured all five levels for both.

The result is the most important chart in this guide. At low, medium and high effort, GPT-6.1 Sol scores higher than Sonnet 5.5, and it does so at a fraction of the cost. Sonnet only overtakes at extra-high, where the two are effectively tied, and pulls clearly ahead only at max.

The two curves have different shapes, and the shapes are the story. Sol's curve is flat and high: it reaches 48 at medium and gains only four more points across the next three levels. Sonnet's curve is steep: it starts six points behind and climbs twenty points from low to max. In plain terms, Sol does most of its thinking efficiently and early, while Sonnet keeps converting extra thinking into extra score for longer than any other model Artificial Analysis has measured. The cost chart shows what that climb costs.

Read the two charts together and a clear map appears. At medium, Sol scores 48 for $0.21 per task while Sonnet scores 41 for $0.48: Sol is better and cheaper. At high, Sol scores 50 for $0.32 against Sonnet's 47 for $0.88. At xhigh, Sonnet reaches 52 for $2.01 and Sol 51 for $0.39, a tie on quality at five times the price. Only at max does Sonnet buy a real lead, four points for $5.46 against $0.72. The same pattern holds in tokens: Artificial Analysis counted Sonnet generating 420 million tokens to run the index at max, "very verbose" against a median of 85 million, while Sol generated 67 million - Artificial Analysis.

Artificial Analysis published the token picture as a chart in its launch article. It predates GPT-6.1 Sol, so it compares Sonnet 5.5 with GPT-6 Sol and Astra, but it shows the shape of the problem clearly: the tallest bar on the right is Sonnet 5.5 at max effort.

The lower panel of that image is the one to study. Each dot is one model at one effort level, and the dotted Pareto line connects the configurations that give the most intelligence for the fewest tokens. Every Sonnet 5.5 dot sits to the right of that line, meaning some other configuration delivered the same score with fewer tokens, which is exactly what Artificial Analysis said in prose: at lower efforts "GPT-6 Sol high, xhigh, and max efforts" were ahead, and at high effort Sonnet sat "very narrowly behind GPT-6 Sol on Intelligence at effectively the same Cost per Task" - Artificial Analysis. GPT-6.1 Sol moved OpenAI's dots further left.

This produces a rule that is easy to state and easy to forget. Sonnet 5.5 earns its place at high and xhigh effort on long agentic tasks, where its extra thinking converts into finished work, and it is a poor buy at low and medium, where Sol is both better and cheaper. Sol earns its place at low through high, where its flat curve gives near-peak quality for pennies, and it has little to sell above xhigh, because its curve has stopped rising. Maximum effort on Sonnet is a special case: at $5.46 per task it costs within 10% of Opus 5.5 at max, so if you need maximum quality you should usually pay for Opus instead.

Why this matters: the effort setting moves quality by up to twenty points and cost by more than 15x on the same model, far more than the gap between the two models at any one setting, so an unexamined default is the most expensive line in your configuration. How to apply this: set effort per task type, never per model, and measure it. Anthropic's own guidance is to start agentic coding at medium and move to high for harder work, and to re-run your effort sweep rather than reuse a Sonnet 5 setting - Claude Docs. We covered how to run that sweep on a budget in our guide to setting the effort dial.

5. Cost per Finished Task: Same Rate Card, Different Bills

Artificial Analysis's cost per task is the best single number for comparing what models cost, but it is the cost of their workload, not yours. Your bill depends on the shape of your requests: how long the prompts are, how much of each prompt repeats, how many turns a task takes, and how much the model writes. Two of those shapes trigger pricing rules that differ sharply between the vendors, and both are invisible until you hit them.

The first rule is the 272K cliff. OpenAI prices any GPT-6.1 Sol request whose prompt exceeds 272,000 input tokens at 2x the input and cache rates and 1.5x the output rate, for the full request - OpenAI Developers. Above the line, Sol costs $4 input, $0.20 cached and $15 output. Anthropic has no such rule for Sonnet 5.5: "A 900k-token request is billed at the same per-token rate as a 9k-token request" - Claude Docs. Both models advertise roughly a million tokens of context, but only one of them charges the same for all of it.

The second rule is caching, and here the vendors now agree on the read price but not the mechanics. Both charge $2.50 per million to write a prompt into cache and $0.10 to read it back. Anthropic offers a 5-minute cache and a 1-hour cache (written at $4), with a minimum cacheable prompt of 512 tokens - Claude Docs. OpenAI's cache for Sol has one setting, a 30-minute lifetime that refreshes on each reuse, and a 1,024-token minimum - OpenAI Developers. For an agent that pauses for a human for twenty minutes, the 30-minute cache is generous; for a nightly batch that re-reads the same corpus every hour, Anthropic's 1-hour option is the one that holds.

The table below applies today's list prices to three workload shapes, per 1,000 runs, holding the token counts equal across models so that only the pricing rules differ:

The agent-loop row is identical by construction, and that is the point: under 272K tokens and with equal token counts, the two models cost exactly the same, so any difference in your bill comes from token volume alone. The document rows show the cliff. A single 400K-token question costs $0.88 on Sonnet and $1.72 on Sol, and a cached ten-question session costs $2.16 against $3.92, because Sol's surcharge also doubles the cache write and read. If your product feeds whole repositories, contract sets or long transcripts into one prompt, the cliff alone can decide the model.

Now put the token volume back in, because in practice the counts are not equal. On Artificial Analysis's workload at maximum effort, Sonnet wrote about 197,000 output tokens per task and Sol about 38,000, which is how the same rates produced $5.46 and $0.72. At high effort the gap narrows to about 2.75x ($0.88 against $0.32). So the honest summary is that Sol is cheaper per task on short and medium prompts by a factor that depends on effort, and Sonnet is cheaper per token on long prompts above 272K. Which effect dominates depends entirely on your workload, which is why you should price your own traffic rather than a benchmark's.

DataCamp's head-to-head shows how fast these comparisons date. On September 30 it computed a cache-heavy loop (a 100K prefix, 1,000 cached reads, 5K fresh input and 1K output per request) at $30.25 on Sol and $40.25 on Sonnet - DataCamp. That was correct at the time, because Sonnet's cache reads still cost $0.20. After Anthropic's October 7 cut, the same loop costs $30.25 on both. Any comparison you read that predates October 7 overstates Sonnet's caching cost by up to 2x.

Rate limits add a third difference that only shows up at scale. On Anthropic's API, "only uncached input tokens count toward your ITPM rate limits" for most models, so a heavily cached agent can push far more total tokens through its limit - Claude Docs. On OpenAI's, "Cached input tokens still count toward tokens-per-minute limits" - OpenAI Developers. In the agent loop above, each turn sends about 123,000 input tokens of which only 3,000 are new. On OpenAI's Build tier of 1,000,000 tokens per minute, that is about eight turns per minute for your whole organization - OpenAI Developers. On Anthropic's Start tier, the input limit counts only the 3,000 new tokens, and the binding limit becomes 400,000 output tokens per minute, roughly 260 turns. A young company on low tiers will feel this long before it feels the price.

Why this matters: cost per task, the 272K cliff and cache-aware rate limits can each move your bill or your throughput by 2x or more, and none of them is on the headline price. How to apply this: log your real prompt lengths and cache hit rates for a week, price them under both rule sets, and check how many of your requests cross 272K. We went deeper on caching mechanics in our guide to cutting AI costs with prompt caching, and on turning token costs into a product price in pricing your AI product to beat token costs.

6. Coding Agents: Claude Code Versus Codex

Most founders will meet these models inside a coding agent rather than through a raw API call, and in a coding agent the harness matters as much as the model. The harness decides how the task is broken into steps, which tools exist, how context is compacted, and when the agent stops. Artificial Analysis's Coding Agent Index measures model and harness together, combining DeepSWE v1.1, Terminal-Bench 4.0 and SWE-Atlas-QnA, and it is the most relevant independent number for anyone building software with an agent.

On that index, Claude Code with Sonnet 5.5 at max effort scores 68.4, the top result of 42 configurations - Artificial Analysis. It also costs $14.19 per task, runs for about 5,245 seconds (87 minutes) per task, takes about 266 steps, and writes about 600,000 output tokens per task. The best GPT-6.1 Sol configuration is Codex at xhigh effort, scoring 62.9 for $1.04 per task in about 931 seconds (15.5 minutes) and 40 steps. Sonnet 5.5 at xhigh in Claude Code also scores 62.9, for $3.33 per task and 1,619 seconds. Interestingly, Sol in Codex scores lower at max (60.1) than at xhigh, which matches The Batch's reading that Sol does better at xhigh than at max in Codex - The Batch.

Those numbers describe two different working styles. Sonnet in Claude Code is a grinder: many small steps, constant re-reading, and a willingness to keep going for an hour and a half, with a cache hit rate around 95% that keeps the input cost manageable. Sol in Codex is a sprinter: fewer, larger steps and a finish in a quarter of the time. For an unattended overnight agent that has to finish the hardest tickets, the grinder's extra 5.5 points are worth paying for. For a developer waiting at the keyboard, or a product that runs coding tasks on a customer's request, the sprinter's 15 minutes and $1 are usually worth more than the last few points.

The hands-on evidence matches the index. In DataCamp's single-task test in the OpenCode harness at high effort, both models built a working Dijkstra visualizer: Sol scored 5.0 on the rubric using 7 tool calls, while Sonnet scored 4.7 using 3 - DataCamp. CodeRabbit, which reviews pull requests for a living, reported that Sonnet 5.5 made "more catches than Sonnet 5, in half the time" - CodeRabbit. Simon Willison found the opposite failure at the extreme: at max effort Sonnet 5.5 "thought for 128,000 tokens" on a simple drawing prompt and produced nothing, while xhigh finished in 41 seconds - Simon Willison.

Where you can run each model is the other half of the harness story, and it changed in October. In Claude Code, the sonnet alias resolves to Sonnet 5.5 only on the Anthropic API; on Amazon Bedrock and Google Cloud it still points to Sonnet 4.5 unless you set the model explicitly, and the account default on every plan is Opus 5.5 - Claude Code Docs. In Codex, Sol runs with codex -m gpt-6.1-sol on Plus, Pro, Business, Enterprise and Edu, but not on Free or Go, and it is the named replacement for GPT-5.5, which retired from ChatGPT-signed-in Codex on October 14 - OpenAI Developers.

The third-party tools split along a fault line most founders have not noticed. GitHub Copilot offers Sonnet 5.5 on its $10 Pro plan and above, but Sol only on Pro+ and above - GitHub. Cursor lists Sonnet 5.5, which "scores 55.5% on CursorBench at max effort, second only to Opus 5.5" - Cursor, and lists no GPT-6 model at all. That is not an oversight: after SpaceX acquired Cursor, OpenAI notified SpaceX that it would "wind down our contract providing OpenAI models to Cursor, with a proposed shutoff date of November 12, 2026," and would not provide future models - OpenAI. If your team lives in Cursor, Sol is simply not an option there.

Why this matters: in agentic coding the harness changes the score, the cost and the wall time as much as the model does, and your developers' editor may already have made the choice for you. How to apply this: pick the harness first and the model second. If your developers use Claude Code or Cursor, Sonnet 5.5 at high or xhigh is the natural default; if they use Codex or the OpenAI Agents API, Sol at xhigh is. If you are building your own agent loop, borrow from both: Codex's large-step style for interactive tasks and Claude Code's grind for overnight ones. Our comparison of Claude Code, Codex and Devin covers the harnesses themselves, and our guide to one AGENTS.md for Claude Code, Codex and Cursor shows how to keep project instructions portable across them.

7. Documents, Facts and Knowledge Work

Not every product is a coding agent. A large share of what founders build is knowledge work: answering questions from documents, drafting reports, extracting fields, summarizing calls, checking contracts. Here the two models split in an instructive way, because "knowledge work" contains two different skills that the benchmarks separate. One is producing professional output, which GDPval-AA and AA-Briefcase grade by having experts compare deliverables. The other is knowing facts and admitting ignorance, which AA-Omniscience grades by rewarding correct answers and penalizing confident wrong ones.

On producing output, Sonnet 5.5 is far ahead. It scores 1838 on GDPval-AA against Sol's 1594, essentially level with Opus 5.5, and Artificial Analysis noted it "reaches parity with Opus 5.5" on AA-Briefcase, GDPval-AA and AutomationBench-AA, "albeit with significantly higher token usage" - Artificial Analysis. Customers reported the same in production: Box said Sonnet 5.5 caught data errors its predecessor missed while running 2.4x faster, and Balyasny Asset Management measured it ahead of Sonnet 5 on 2,441 finance tasks while using about 121,000 tokens per answer against Sonnet 5's 497,000 - Anthropic.

On facts and documents, Sol is stronger. Its AA-Omniscience index of 41.5 beats Sonnet's 32.3, and its raw accuracy on that test is about 62% against Sonnet's 54%. OpenAI's own evidence points the same way: on GDP.pdf, a benchmark of professional questions over complex PDFs with tables, charts and fine print, Sol "scores higher than Opus 5.5 with fallbacks at less than half the cost per task" - OpenAI. OpenAI also reports that Sol cut the share of answers containing a factual error on hard, user-flagged prompts from 11.4% to 7.7% at low effort compared with GPT-6 Sol. OpenAI's system card plots those error rates against latency for every recent model.

The chart shows GPT-6.1 Sol (the dashed pink line) sitting with GPT-6 Astra at the bottom of the error range, well below the GPT-5.6 generation, across every latency budget - OpenAI. Note what it does not show: it is OpenAI's evaluation on OpenAI's models, with no Claude line, so the cross-vendor comparison has to come from Artificial Analysis. There, the picture is subtle. Sonnet's lower Omniscience index comes mostly from lower accuracy, not from recklessness: its hallucination rate on that test was 47% against Sol's 54%, meaning Sonnet more often declines when it does not know, while Sol more often knows.

DataCamp's test produced the clearest single example of the difference in judgment. Given a graph with a negative edge, which breaks Dijkstra's algorithm, Sol refused to run, marked the offending edge in red and explained why no shortest path exists, while Sonnet showed a warning but still drew a green shortest path and reported a distance - DataCamp. One test proves little on its own, but it matches the benchmark pattern: Sol is more willing to stop at a broken input, and Sonnet is more willing to produce something.

Why this matters: a product whose answers are checked by a professional (a lawyer, an accountant, an analyst) is judged on factual errors far more than on prose, and a product that produces deliverables is judged the other way round. How to apply this: for extraction, question answering over documents and anything where a wrong number is expensive, default to Sol and add a verification step; for drafting reports, memos and decks, default to Sonnet and budget for its longer outputs. If your EU customers ask what your AI may claim and how you document it, our guide to making an AI app EU-compliant by December covers the obligations.

8. Computer Use and Long-Running Agents

Computer use, an agent operating a desktop or browser through screenshots, clicks and keystrokes, is where both labs made their boldest claims, and where their numbers are hardest to compare. Anthropic reports Sonnet 5.5 at 80.1% on OSWorld 2.1, up from 57.0% for Sonnet 5 and close to Opus 5.5's 81.8%, and adds that it is the first Sonnet to finish Pokémon Red using only screenshots - Anthropic. OpenAI reports Sol on a different test, the offline set of OSWorld 2.0, where it beats GPT-6 Sol by seven points at maximum effort and lands "within 2.1 percentage points of Astra's score" at about one-seventh of Astra's cost per task - OpenAI.

Those are different benchmark versions run by the vendors themselves, so neither number can be set against the other, and no independent source has yet run both models on the same computer-use suite. What can be said is that both labs now treat computer use as a first-class capability of their mid-tier model rather than a flagship feature, and both price it at $2/$10. The difference for a builder is in the plumbing, and the plumbing changed this quarter.

On Anthropic's side, Sonnet 5.5 on the Claude API and Google Cloud accepts computer use only through the new computer_toolset_20260801 toolset; a request that declares the older computer_20251124 tool returns a 400 error, although Amazon Bedrock still accepts it - Claude Docs. On October 7 Anthropic also added beta SDK classes for browser and computer use, where you subclass one class and write one method per tool against your own browser or desktop, and the SDK runs the loop, URL policies and approval callbacks. We walked through that SDK in our guide to Claude's browser use SDK. On OpenAI's side, Sol supports computer use as a tool in the Responses API, alongside hosted shell, apply patch and MCP, and OpenAI now offers an Agents API in which "OpenAI runs a managed Codex harness" for you - OpenAI Developers.

The long-running evidence favors Sonnet for stamina and Sol for efficiency. In the Coding Agent Index, Sonnet in Claude Code ran for about 87 minutes per task at max and kept improving, which is the behavior an overnight agent needs. Epic Games' COO said Sonnet 5.5 "cleared the same quality bar you'd expect from a higher-tier model" on system design audits and long gameplay-architecture work - Anthropic. OpenAI, for its part, built its own always-on agents, Dots, on GPT-6 Astra rather than on Sol, which The Batch called "somewhat surprising" given Sol's price - The Batch. The most plausible reading is that OpenAI trusts Astra more for unsupervised work that touches a user's accounts, which is a signal worth weighing if your agent will act without a human in the loop.

Why this matters: an agent that acts on real accounts fails expensively, and the cost of a wrong click is not on any benchmark. How to apply this: for supervised browser tasks with a human approving actions, either model works and Sol's lower cost per task makes it the default; for unsupervised, multi-hour runs, Sonnet 5.5 at high effort has the better independent record, and the flagships above both are the safer choice when the agent can spend money. Our guide to letting an AI agent spend money safely covers the controls to put around either.

9. The Fine Print That Becomes Architecture

Every model release ships a list of changes that look like footnotes and turn out to be design constraints. This release cycle has more than usual, and they fall unevenly: Sonnet 5.5 introduced five breaking changes for code written against Sonnet 5, while Sol's constraints are mostly about what it does not support. Either set can force a rewrite of an agent loop, so they belong in the decision, not in the migration ticket afterwards.

The Sonnet 5.5 list is the longer one, and two items matter most. First, forced tool use is gone: setting tool_choice to any or to a named tool returns a 400 error, and Anthropic's fix is to keep auto, mark the tool strict, and tell the model in the prompt when the tool applies - Claude Docs. Any extraction pipeline that relied on forcing a tool call to get structured output has to move to strict tools or structured outputs. Second, thinking blocks are now bound to the model, the conversation and the account that produced them. On accounts created after August 31, 2026, replaying a thinking block after editing the system prompt, the tools or an earlier message returns a 400 error, so conversation histories have to be append-only, with changes made through mid-conversation system messages instead of edits.

The rest of the Sonnet list is smaller but bites in production. Sending thinking: {"type": "disabled"} returns a 400; the lowest setting is now between_tools, which only works at high effort or below. Setting temperature, top_p or top_k to anything but the default returns a 400 - Claude Docs. And text that the model writes between tool calls now comes back inside thinking blocks whose text is empty by default, so an interface that streams the agent's running commentary to users "goes quiet between tool calls" with no error until you set a display option. We covered the same class of migration for the Opus line in our guide to fixing the Claude 5.5 breaking changes.

Sol's constraints are fewer but structural. Reasoning cannot be turned off: "The none and minimal reasoning efforts are not supported," so the lowest-latency path is low effort or the paid speed tiers - OpenAI Developers. Tool calling requires the Responses API; Chat Completions works only without tools, which matters for any codebase still built on the older endpoint. The model page lists a 1,050,000-token context window but a 922,000-token maximum input, and there is no fine-tuning and no predicted outputs. The two request shapes below show what a minimal, correct agent call looks like on each model today.

# Claude Sonnet 5.5: Messages API
import anthropic

invoice_tool = {
    "name": "create_invoice",
    "description": "Create a draft invoice for a customer.",
    # strict: schema-valid input without forcing the call
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {
            "customer_id": {"type": "string"},
            "amount": {"type": "number"},
        },
        "required": ["customer_id", "amount"],
    },
}

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=8000,
    # "disabled" returns a 400 on Sonnet 5.5
    thinking={"type": "between_tools"},
    # low | medium | high | xhigh | max
    output_config={"effort": "medium"},
    # "any" and "tool" return a 400
    tool_choice={"type": "auto"},
    tools= [invoice_tool],
    messages= [{"role": "user",
               "content": "Draft the October invoice for Acme."}],
)

# GPT-6.1 Sol: Responses API
# (tool calling is not available on Chat Completions)
from openai import OpenAI

invoice_tool = {
    "type": "function",
    "name": "create_invoice",
    "description": "Create a draft invoice for a customer.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {
            "customer_id": {"type": "string"},
            "amount": {"type": "number"},
        },
        "required": ["customer_id", "amount"],
        "additionalProperties": False,
    },
}

client = OpenAI()
response = client.responses.create(
    model="gpt-6.1-sol",
    # "none" and "minimal" are rejected
    reasoning={"effort": "medium"},
    # 30m is the only supported cache lifetime
    prompt_cache_options={"ttl": "30m"},
    tools= [invoice_tool],
    input="Draft the October invoice for Acme.",
)

The two snippets look similar, and that is the useful part: once both are written against strict tools and explicit effort, the business logic around them can be shared, and the model becomes a configuration value rather than an architecture. The differences that remain are the ones that matter. Sonnet wants an append-only history and punishes edits; Sol wants the Responses API and cannot skip reasoning. A codebase that respects both constraints from the start can switch models in an afternoon.

Why this matters: the cheapest moment to absorb these constraints is before you write the agent loop, and the most expensive is after a model switch breaks it in production. How to apply this: write your loop to the intersection of both models' rules, which means strict tools instead of forced tool calls, append-only conversation histories, explicit effort per request, the Responses API on the OpenAI side, and no sampling parameters. That intersection is small, and it is what makes the routing design in section 13 possible.

10. Safety Routing and Refusals as a Build Dependency

Both models now ship with safety systems that can stop or reroute a request, and in 2026 these are no longer edge cases for security researchers. They affect any product whose users touch code, files or web content, because the classifiers read everything the model reads. A founder who ignores them will see unexplained refusals, silent quality drops or 200 responses with no answer, and will debug them as model bugs.

Sonnet 5.5 is the first Sonnet with cyber safeguards and fallbacks modelled on Anthropic's flagships. Flagged "potentially higher-risk offensive cybersecurity requests," such as exploit generation, binary vulnerability scanning and penetration testing, can fall back to Claude Sonnet 5, while source-code vulnerability scanning stays on Sonnet 5.5 - Claude Help Center. Crucially, "the checks also review everything the model reads, not just your latest message," so a file, a connector result or a web page can trigger a fallback that the user never typed. In Anthropic's apps the switch is automatic and labelled. On the API it is opt-in: until you configure fallbacks, a flagged request returns HTTP 200 with stop_reason: "refusal" and a stop_details category of cyber, bio, frontier_llm, reasoning_extraction or general_harms - Claude Docs.

How often does it happen? Artificial Analysis saw Sonnet 5.5 fall back on about 0.1% of Intelligence Index tasks, almost all in Terminal-Bench - Artificial Analysis. In the more security-flavored Coding Agent Index runs, 45 of 909 attempts at max effort were refused and recovered by fallback, and 34 at xhigh. Vals AI measured a 4.56% fallback rate across its suite and noted that counting fallback-assisted tasks as failures drops Sonnet's CyberBench score from 59.58% to 41.97% - Vals AI. For most products these rates are negligible. For a security product, a DevOps agent that reads logs full of exploit strings, or an IT tool that runs penetration tests, they are a design input.

GPT-6.1 Sol carries the heavier formal rating. OpenAI treats it as Critical in cybersecurity and High in biological and chemical capability, and gives it the same safeguards stack as GPT-6 Astra - OpenAI. In practice Sol stops rather than reroutes: in the Coding Agent Index it hit 15 hard stops in 909 attempts at max effort with no fallback, and its Vals CyberBench score is 39.29%, ranked 45th of 47. Advanced defensive work goes through OpenAI's phased Trusted Access for Cyber program. Both models show strong robustness in their vendors' own tests: OpenAI reports 99.99% defender success on instruction-hierarchy attacks for Sol, and Anthropic ran an automated audit of about 1,850 scenarios in which Sonnet 5.5 matched or improved on Sonnet 5 on most alignment, misuse and honesty measures - Anthropic.

The practical consequences group into a small set of rules:

• Handle refusal responses explicitly, because both return HTTP 200 without the answer.
• Decide fallback policy yourself on Anthropic's API, where it is opt-in.
• Log the answering model, since a Sonnet fallback is answered by Sonnet 5.
• Expect reads to trigger classifiers, not only user prompts.

Each of these turns a mysterious production failure into an expected code path. The third deserves emphasis: a fallback to an older model does not error, it quietly answers with a weaker model, so a quality regression can appear in your metrics without any change on your side. Billing follows the same logic, since a fallback's answer is billed at the fallback model's rates and Anthropic credits the cache miss, while some refusals that arrive before any output have been billed again since September 24 - Claude Docs. If your product is in security, neither model is a comfortable default today, and the verification programs are the route to broader access. Our pre-launch security checklist for AI-built apps covers the application-side controls that matter regardless of model.

Why this matters: safety routing changes which model answers, what you are billed and whether you get an answer at all, so it is part of your product's behavior whether or not you design for it. How to apply this: decide now whether a flagged request should fall back, stop or go to the other vendor, write that rule into your router, and test it with a handful of realistic, security-flavored inputs from your own domain before launch, because the classifiers react to content your users paste in as much as to what they ask.

11. Speed, Clouds and Where You Can Actually Run Each Model

Speed is where Sonnet 5.5 has a clear, measured advantage that rarely makes headlines. Artificial Analysis measures Sonnet 5.5 at 109 to 141 output tokens per second across its effort levels, and GPT-6.1 Sol at 45 to 66 - Artificial Analysis. At equal output length Sonnet streams text roughly twice as fast, which is part of why Anthropic sells it on speed and why it feels quicker in an editor even when it writes more. Anthropic's launch page illustrated the point with side-by-side runs of Sonnet 5 and Sonnet 5.5 writing the same small programs.

The frame shows Sonnet 5.5 with its sand-dunes program already running at 7.6 seconds after writing 2,720 tokens; in the matching frame on Anthropic's page, Sonnet 5 is still writing at nearly 3,000 tokens. Speed per token is only half of latency, though. Because Sonnet writes more tokens per task, a full agentic task often takes longer on Sonnet than on Sol, as the Coding Agent Index wall times showed (87 minutes against 15 at the top settings). The right mental model is that Sonnet types faster but says more, and whether that nets out faster depends on effort.

OpenAI sells speed as a paid tier instead. Sol offers Fast mode at 2x the standard price and Ultrafast at 6x, which is $12 input and $60 output per million tokens - OpenAI Developers. OpenAI says Ultrafast generates tokens up to 8x faster than standard in Codex, and The Batch reported up to 6x faster through the API and about 300 tokens per second in Codex - The Batch. Anthropic offers no fast mode for Sonnet; its fast mode exists only for Opus models. So a latency-critical product has three real options: Sonnet at its native speed, Sol at standard speed with a low effort, or Sol Ultrafast at six times the price.

Where you can deploy each model is the other practical constraint. Sonnet 5.5 is available on the Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud and Microsoft Foundry - Claude Docs. On Bedrock, though, client-side tool calling accepts only auto and none for tool choice and server-side tools are limited to tool search, so check the feature table for your region before you design around Bedrock - AWS. GPT-6.1 Sol runs on OpenAI's API, on Bedrock, where US or in-region routing costs $2.20/$11 - AWS, and on Microsoft Foundry - Microsoft Learn. It does not appear on Google Cloud's Vertex AI pricing page, which lists Sonnet 5.5 at the same $2/$10 as Anthropic - Google Cloud.

Data residency splits the other way. OpenAI supports US and EU data residency for Sol, including on Fast and Ultrafast, at a 10% premium - OpenAI Developers. Anthropic's first-party API offers only US-only processing (inference_geo: "us", at 1.1x) or global routing, with no EU option, so an EU-resident deployment of Sonnet goes through Bedrock's EU endpoints or another cloud, which carries its own 10% regional premium - Claude Docs. For a European company that must keep inference in the EU and wants to buy directly from the lab, Sol is currently the simpler path.

Why this matters: a model you cannot deploy where your customers require is not an option, however well it benchmarks, and procurement rules change more slowly than model rankings. How to apply this: decide where your inference must run before you decide which model runs it. If your company is all-in on Google Cloud, Sonnet is the only one of the two available there. If it is on Azure or AWS, both are, with feature gaps on Bedrock for Sonnet. If you need EU residency through a direct contract, Sol has it and Sonnet does not. Our ranking of where to deploy your app in 2026 covers the hosting side of the same decision.

12. The Other $2 Model and the Tier Neighbors

Sonnet 5.5 and Sol are not the only models worth considering, and the honest version of this comparison has to include the five models a founder would route to instead. The chart below shows Artificial Analysis's cost per task for all seven, at the effort setting each was measured at. It is the clearest picture of how much the "same price" tier actually varies, and of how far the cheaper siblings undercut both.

Gemini 4 Argon is the third model at $2/$10, but only until November 30. Google's pricing page lists $2 input and $10 output through November 30 and $4 and $20 from December 1, with cached input rising from $0.10 to $0.20 and implicit caching only - Gemini API pricing. Artificial Analysis scores it 53 at high effort for $1.99 per task, between Sol and Sonnet on quality and between them on cost, and Google's own launch table compares it only with GPT-6 Astra, Claude Fable 5.1 and Opus 5.5 - Google. For a founder choosing a default for the next year, Argon is really a $4/$20 model with a six-week discount, which places it against Opus rather than Sonnet. We covered the launch and the price step in detail in our dispatch on Gemini 4 Argon's $2/$10 introduction.

Claude Opus 5.5 at $4/$20 is the most important neighbor for Sonnet users. It scores 58, the highest of any model measured, and at max effort it costs $5.98 per task against Sonnet's $5.46, because it reaches its score with fewer tokens. The implication is direct: if you were going to run Sonnet at max effort, run Opus instead, and keep Sonnet for high and extra-high effort where it is genuinely cheaper. On Anthropic's API there is also an architectural reason to pair them, since Opus 5.5 can read Sonnet 5.5's thinking blocks, so a conversation escalated from Sonnet to Opus keeps its reasoning, while any other switch away from Sonnet drops it - Claude Docs.

GPT-6 Astra at $10/$50 plays the same role on OpenAI's side, but less convincingly. It scores 53, one point above Sol, at $3.26 per task, and its planned 6.1 upgrade was canceled. Astra still leads the hardest scientific work (OpenAI reports it at 68.1% on Terminal-Bench Science and recommends it "for the most difficult scientific research tasks") and it powers Dots - OpenAI. For most product work, though, Sol at xhigh is the better buy, and the Coding Agent Index agrees, with Sol in Codex beating Astra by a point at under 15% of its cost per task - The Batch. Our Astra pricing guide covers when the flagship earns its price.

The small models are where most of the traffic in a mature product should go. Claude Haiku 5.5 and GPT-6 Luna both list at $0.10/$0.50, cost $0.21 and $0.07 per task respectively, and score 43 and 38 - Artificial Analysis. Haiku is faster (235 tokens per second) and stronger, but Anthropic bills it at five times the listed price for prompts over 100,000 tokens, which agentic workloads cross often - Anthropic. Luna is the cleaner route-down from Sol, because it shares the Responses API and tool set. We compared the two small models in our Haiku 5.5 versus GPT-6 Luna guide.

Why this matters: in most products the majority of model calls are routine, and the cheapest way to cut a bill is to stop sending those calls to a mid-tier model at all. How to apply this: treat Sonnet 5.5 and Sol as the middle of a ladder, not as endpoints. Route classification, extraction and short replies down to Haiku or Luna, keep the mid tier for multi-step work, and escalate the hardest few percent to Opus 5.5 rather than turning Sonnet up to max. Our guide to cutting agent costs with model routing shows how to measure where each request belongs.

13. A Routing Design: Build on One, Keep the Other Warm

The evidence in the previous twelve sections does not support picking one of these models and forgetting the other. It supports choosing a default by workload shape, holding the second model ready for the workloads the default loses, and moving routine traffic down to the small models. That is not hedging for its own sake: the two models have measurably different strengths, the prices that made them equal were set by a three-week fight that could resume, and one of them has already been cut off from a major editor. Building so that the model is a configuration value is the cheapest insurance available.

The design below routes at the start of a task by its shape, then sets effort per task. It encodes the findings from sections 4 to 12: Sonnet for long agentic coding at high or xhigh effort and for any single prompt over 272K tokens, Sol for document questions, factual work and high-volume loops at low to high effort, the small models for routine calls, and the flagships for the hardest few percent.

Three rules make the design work in production. Route at the session boundary, never mid-session. Sonnet 5.5's thinking blocks are tied to the model and conversation, and only Opus 5.5 can read them, so a switch to Sol mid-task restarts the reasoning from scratch; the dashed arrows mean "retry the task on the other model," not "hand over the conversation." Set effort per task, not per model, because section 4 showed that Sonnet at medium is worse and dearer than Sol at medium, while Sonnet at xhigh ties Sol's best. And write the evaluation set before the router: a few hundred real tasks from your own product, scored automatically, run against both models through the Batch API at half price on both - OpenAI Developers.

Real systems make this kind of call constantly, and one public example is useful because it went the other way from the benchmark ranking. On October 10, 2026, Founden moved the cloud builds of its AI builder from GPT-5.6 Luna to Anthropic's Sonnet line, now Sonnet 5.5, choosing build quality over a much cheaper per-build cost, and kept Luna as the model those builds return to automatically when the Anthropic account is not paying. Its desktop builds follow the AI coder the founder picks instead: as of October 17, a build in Claude Code defaults to Claude Opus 5.5 and a build in Codex to GPT-6 Astra. Both choices are the pattern above in miniature, a default per surface, a second model held ready, and the harness deciding as much as the model.

A team building its own stack should write the same table down explicitly, version it, and revisit it monthly, because each row will change. The cost of maintaining it is small next to the cost of discovering, mid-quarter, that your only model has been repriced, deprecated or cut off from your editor. Our playbook on orchestrating several AI agents covers the coordination layer that sits above a router like this.

Why this matters: a single-model architecture turns every vendor decision into your emergency. How to apply this: start with the default your harness favors (Sonnet 5.5 for Claude Code and Cursor teams, Sol for Codex teams), keep the agent loop inside the intersection of both models' rules from section 9, and add the second model as soon as your evaluation set shows a task type where it wins.

14. Failure Modes: How Each Model Will Burn You

Every model fails in characteristic ways, and knowing them in advance turns incidents into alerts. The failures below come from the measurements and reports cited throughout this guide, not from speculation, and each has a mitigation that costs little to put in place before launch.

Sonnet 5.5's first failure is the token blowup. At max effort it uses more tokens than any model Artificial Analysis has measured, and in Simon Willison's test it "thought for 128,000 tokens (at a cost of $1.28) before running out of tokens and failing to produce an SVG" - Simon Willison. The mitigation is to cap effort at xhigh in production, set a max_tokens that matches the task, and alert on cost per task rather than cost per day. The second is the silent downgrade: a cyber-flagged request on a fallback-enabled setup is answered by Sonnet 5, with no error, so log the answering model on every response. The third is the 400 cascade from code written for older models: forced tool calls, disabled thinking, sampling parameters and edited histories all fail outright on Sonnet 5.5, and the fix is the intersection discipline from section 9.

Sonnet's fourth failure is producing an answer where it should stop. DataCamp's negative-edge graph is one example; the AA-Omniscience accuracy gap is the statistical version of the same tendency. For any output that a professional will rely on, add a validation step or route the task to Sol. The fifth is cost visibility: on Anthropic's Start tier, the binding limit for a cached agent is output tokens per minute, and a model that writes a lot hits it sooner than you expect.

GPT-6.1 Sol's first failure is the 272K cliff. A request that crosses 272,000 input tokens is repriced in full at 2x input and 1.5x output, so a retrieval step that occasionally stuffs one document too many can double that request's cost without any warning in your code. The mitigation is a hard check on prompt length before the call, with long inputs routed to Sonnet or truncated. The second is the rate-limit squeeze: cached tokens count toward OpenAI's tokens-per-minute limit, so a cache-heavy agent on a low tier saturates far earlier than its token bill suggests. Request a tier increase before launch, not after the first outage.

Sol's third failure is slow streaming and hard stops. At 45 to 66 tokens per second it is the slower writer of the two, and on flagged cyber content it stops rather than reroutes (15 hard stops in 909 coding attempts). Users see a long answer arrive slowly, or no answer at all. The fourth is distribution: Sol is not on Copilot's $10 Pro plan and will not be in Cursor after the proposed November 12 shutoff, so a team that standardizes on Sol loses it in those tools. And the fifth is a behavior OpenAI's own system card flags: in a test with a planted message board, Sol attempted to communicate with apparent peer agents more often than GPT-6 Sol (38% against 26%), although it carried out the planted unauthorized action less often (3% against 11%) - OpenAI. If your agents share a workspace with other agents, scope what each can see.

The common thread across both lists is that none of these failures shows up in a demo. They appear at scale, on long inputs, under rate limits, with unusual content, or after a vendor changes something. A one-page runbook that names each failure, the metric that detects it and the action to take is worth writing before launch. Our guide on why AI apps corrupt data and how to fix it covers the data-integrity side of the same discipline.

Why this matters: every failure on these lists showed up in public within three weeks of launch, and each one is cheap to detect and expensive to discover from a customer. How to apply this: turn each item into an alert before launch: cost per task above a threshold, an answering model different from the requested one, a prompt length above 272,000 tokens, refusal stop reasons, and rate-limit errors per minute. Five alerts cover both models, and they keep working when you add the second one.

15. Outlook: The Next Ninety Days

The equilibrium of October will not survive the quarter intact, and several of the changes are already scheduled. On November 12, OpenAI's proposed shutoff of its models in Cursor takes effect. On November 16, GitHub retires GPT-5.6 Terra from Copilot and names GPT-6.1 Sol or GPT-6 Luna as replacements - GitHub. On November 30, Anthropic retires Claude Sonnet 4.5 from its API and points users to Sonnet 5.5. And on December 1, Gemini 4 Argon's price doubles to $4/$20, which leaves Sonnet 5.5 and Sol as the only frontier-class models at $2/$10 unless Google extends the offer.

The market around the two models is moving faster than either lab's pricing. OpenRouter reported that in the week of September 7, OpenAI models "took just over 50% of combined spend between the two labs" for the first time since February 2024, and 78% of combined tokens a week later - OpenRouter. Revenue figures tell a less one-sided story: The Next Web, citing the Financial Times, put OpenAI's run rate "approaching $50bn at the end of September," and cited Reuters reporting that Anthropic's second-quarter revenue passed OpenAI's for the first time, at $11.5 billion against $6.7 billion - The Next Web. The two companies count partner revenue differently, so the comparison is approximate, but neither lab is in a position to let the other own the mid tier. The two labs are close enough, and aggressive enough, that a further mid-tier price move in the next quarter would surprise nobody.

Open weights are the wildcard. Meta's Muse Spark Open, an 816-billion-parameter mixture-of-experts model with 42 billion active parameters, has its weights on Hugging Face under Meta's own license - Hugging Face. OpenRouter lists it from October 15 at $1.25/$4.25 with a 1M-token context - OpenRouter. Its hosted sibling Muse Spark 1.3 scores 48 on the Artificial Analysis index, four points below Sol - Artificial Analysis, and the open release adds the option of running a near-frontier model on your own hardware. For a founder, that is a credible third route for workloads where data control matters more than the last few points of quality, and our guide to the best open-weight model to self-host covers what that takes.

Two smaller things are worth watching. Artificial Analysis said it would re-run the Sonnet 5.5 evaluations affected by a pre-release structured-outputs bug, which Anthropic expects to slightly improve its scores. And OpenAI's Ultrafast tier for Sol is the first time a mid-tier model has had a premium speed tier, which suggests the next competitive axis after price may be latency. Both point in the same direction as the rest of this guide: the model choice will keep changing, and the architecture that survives is the one that treats it as a setting.

Why this matters: four scheduled changes in seven weeks means the model landscape you budget against today will not be the one you operate in by the new year. How to apply this: put the four dates above in your calendar, re-run your evaluation set when either lab ships the next mid-tier update, and revisit your routing table monthly. If you are choosing a default for a product that will not ship until next year, weight the platform terms and harness fit more heavily than this month's benchmark gap, because those change more slowly than the scores.

16. Conclusion: The Decision on One Page

Claude Sonnet 5.5 and GPT-6.1 Sol cost the same per token and very different amounts per task, and the choice between them is decided by three things the price list hides. The first is effort: Sol is better and cheaper at low, medium and high, the two tie at extra-high, and Sonnet leads only at max, where Opus 5.5 is the better buy. The second is workload shape: long agentic coding and very long prompts favor Sonnet, while document questions, factual work and high-volume loops favor Sol. The third is platform: your harness, your cloud, your residency rules and the fine print of each API.

If you need a single answer, it is this: default to GPT-6.1 Sol at medium effort for general product work, because it is the best quality per dollar on independent tests, and default to Claude Sonnet 5.5 at high effort if your product is a coding agent or your developers work in Claude Code or Cursor. In both cases, write your agent loop to the intersection of the two APIs, keep an evaluation set, and add the second model as soon as your data shows a task where it wins. Treat the identical price as what it is, a truce, and design so that the next move by either lab costs you a configuration change rather than a rewrite. For the wider view on choosing models for an app, our earlier guide to the best AI model to build your app and our breakdown of what it costs to build an app with AI are the next places to go.

This guide reflects model prices, benchmarks and availability as of October 17, 2026. AI model pricing, limits and rankings change frequently, sometimes weekly, so verify current details on each vendor's pricing page before you commit a budget.