Claude Sonnet 5 vs GPT-5.5: A Complete Comparison

Updated:
Ask AI about this article
Claude Sonnet 5 vs GPT-5.5: A Complete Comparison
In short. Claude Sonnet 5 wins on price (2.5–3 times cheaper) and safer positioning. GPT-5.5 wins on some agent and knowledge work benchmarks and has broader tool support in the Responses API (built-in image generation, hosted shell, tool search). Direct benchmark comparison is complicated by the models being released two months apart and tested on different benchmark versions — I'm marking this separately where the comparison is incorrect.

I have already written a full technical breakdown of the Sonnet 5 model itself — architecture, effort levels, benchmarks, limitations — in a separate review. Here — only a direct comparison with GPT-5.5, without repeating what has already been covered there.

Contents

Price and API limits

Here the difference is the most unambiguous of the entire comparison. GPT-5.5 costs $5 per million input tokens and $30 per million output. Sonnet 5 at standard price is $3/$15, and a starting price of $2/$10 is valid until August 31, 2026.

Parameter Claude Sonnet 5 GPT-5.5
Input tokens (per 1M) $2 (until 08.31.2026), then $3 $5
Output tokens (per 1M) $10 (until 08.31.2026), then $15 $30
Long context surcharge None — same pricing for the entire 1M Yes — over 272K input tokens, the price is 2x for input and 1.5x for output for the entire session
Batch discount 50% 50% (Batch/Flex — half of the standard rate)

The second point, which is often missed: in GPT-5.5, the surcharge for long context is calculated for the entire session as soon as the input exceeds 272K tokens — meaning working with large codebases or documents above this threshold costs twice as much for input. Sonnet 5 has no such threshold: a request for 900K tokens is priced the same as a request for 9K. For tasks where the window capacity is actually used close to 1M (not just "in reserve"), this significantly affects the total bill, not just the price per token.

Context window and working with long documents

Formally, both models are advertised as "1M-context," but the details differ significantly — and it's in the details that the real difference for production use lies. Sonnet 5 has exactly 1M input tokens + up to 128K output, with no thresholds within the window: this is both the default and the maximum, there is no separate "smaller" model variant. GPT-5.5 in the API has 1.05M tokens (922K input + 128K output), and in Codex — only 400K, meaning the largest context is not available in all product surfaces: a developer working through Codex, rather than directly through the API, does not physically receive the advertised million tokens.

The second layer of difference is the pricing within the window itself. In GPT-5.5, as soon as the input exceeds 272K tokens, the price for the entire request (not just for tokens above the threshold) doubles for input and increases by 1.5 times for output. Sonnet 5 has no such threshold at all: a request for 900K tokens is priced at the same rate per token as a request for 9K.

Why this is important in practice. A million context tokens is a marketing figure of "capacity," not a guarantee that the model works equally well across the entire length. I have already detailed the mechanics of quality degradation on long context — why models "forget" and how to calculate the real cost of such work — in a separate article: LLM Context Window: Why AI Forgets and How Much It Costs. In short: the mere presence of a large window does not absolve you from the need to design what exactly to put into it — "clean" context always yields better results than "noisy" context, even if technically both fit.

For the comparison of Sonnet 5 and GPT-5.5, this leads to two practical consequences. Firstly, the GPT-5.5 price threshold of 272K is not an abstract detail of the price list, but a real architectural factor: if your typical request (e.g., analyzing a medium-sized codebase or a package of contracts) regularly crosses this boundary, the total cost can double precisely at the moment when context is most needed — i.e., for the most complex, largest tasks. Secondly, the difference between 1M in the API and 400K in Codex means that the choice of OpenAI product surface (not the model itself) directly determines what portion of the advertised capacity you will actually receive — this is worth checking before designing an architecture for "a million tokens."

Conclusion: for tasks where long context is used constantly and actively (not as a one-time "reserve" option), Sonnet 5's economics — without thresholds and without being tied to a specific product surface — provide a more predictable cost of ownership, even if the raw context figure in GPT-5.5 is formally slightly larger.

Claude Sonnet 5 vs GPT-5.5: A Complete Comparison

Programming Benchmarks

Important disclaimer before the numbers: GPT-5.5 was released on April 23, 2026, Sonnet 5 on June 30, 2026, and each lab published its own results at its own time, often on different versions of benchmarks. Where versions differ (e.g., Terminal-Bench 2.0 vs. 2.1), I note it separately – a direct comparison of such numbers is incorrect.

Benchmark Claude Sonnet 5 GPT-5.5 Note
SWE-bench Pro 63.2% 58.6% Same benchmark version, correct comparison
Terminal-Bench 80.4% (version 2.1) 82.7% (version 2.0) Different benchmark versions – not directly comparable
OSWorld-Verified 81.2% 78.7% Same methodology, correct comparison

On SWE-bench Pro – the most challenging and contamination-resistant variant of the code benchmark – Sonnet 5 outperforms GPT-5.5 by approximately 4.5 points. However, for GPT-5.5, its own internal OpenAI Expert-SWE benchmark (tasks with a median human execution time of 20 hours) is more indicative, where the model scores 73.1% – there is no direct equivalent of this benchmark in Anthropic's materials, so it cannot be correctly compared to any Sonnet 5 figure.

Practical conclusion: on "classic" SWE-bench style tasks, Sonnet 5 has an advantage according to official figures. However, for long, multi-hour engineering tasks (what Expert-SWE measures), there is no direct comparable data – here I would rely on my own testing rather than benchmarks from the press releases of both companies.

Agent Capabilities and Computer Use

On OSWorld-Verified – a benchmark for controlling a real desktop environment (the model opens applications, clicks, fills forms, navigates interfaces it has never seen before) – Sonnet 5 shows 81.2% compared to 78.7% for GPT-5.5. The difference is small (2.5 points) and not statistically critical, so I wouldn't conclude from it that "Sonnet 5 is objectively better at computer use" – it's more accurate to say that both models are very close to each other and both labs directly call this result a transition of computer use from experimental status to production-viable.

Why this is important. Until this generation of models, computer use was more of a demo capability: an agent could "show" that it could click on the screen, but for real production workflows (filling forms in corporate CRMs, navigating internal systems without APIs), the accuracy was insufficient for deployment without constant human supervision. A score above 78-80% on OSWorld-Verified is the threshold after which automation of browser tasks becomes economically justified with a reasonable error processing rate, rather than just an interesting experiment.

On the knowledge work benchmark GDPval, GPT-5.5 claims 84.9% – formally higher than Sonnet 5's score on the related GDPval-AA v2 (1618 Elo), but the difference in evaluation format (percentage vs. Elo rating) does not allow it to be reduced to a single number and compared directly. Both companies use slightly different versions of this benchmark, so I would not draw a direct conclusion from this that "GPT-5.5 is better at knowledge work" – it's more accurate to say that both models show strong results according to their own methodologies, which cannot be directly scaled to one.

A practical difference that doesn't boil down to benchmarks: GPT-5.5 in Responses API immediately supports a wider range of server-side tools "out of the box" – hosted shell, tool search, built-in image generation, file search – whereas in the Claude ecosystem, some of this functionality is implemented through separate integrations and MCPs. If an agent requires such a wide range of built-in tools without additional integration work, this is a real practical advantage of GPT-5.5 beyond benchmarks.

Why this is important in practice – and where the trap lies. More built-in tools "out of the box" sounds like an unambiguous advantage, but in practice, a large number of available tool definitions in the context of an agent is a separate problem that doesn't depend on which model you choose. I discussed this in detail in the article Tool RAG: What to do when an agent has too many tools – in short, each added tool consumes part of the context window for its definition (name, description, parameter schema), and the model is worse at choosing the correct call when there are too many tools simultaneously. That is, the wider range of server-side tools in GPT-5.5 is useful only as long as the agent actually uses them, and not just connects them "for backup" – otherwise, the effect can be the opposite.

If your agent stack is not tied to a specific cloud provider and you are choosing between local models for tool calling (e.g., via Ollama) – the question of "which model is better at calling tools" is not limited to Sonnet 5 vs. GPT-5.5. I have compiled a comparison of local models specifically for tool calling quality with real benchmarks in a separate article: Which Ollama model to choose for an agent with tool calling – useful as a baseline if part of your agent pipeline runs locally, and the cloud model (Sonnet 5 or GPT-5.5) is only connected for the most complex steps.

Generation Speed and Latency

OpenAI emphasizes that GPT-5.5 maintains the same per-token latency as GPT-5.4, despite its higher "intelligence" – and additionally offers a Fast mode that generates tokens 1.5 times faster for 2.5 times the price. Sonnet 5 does not have a similar separate "fast mode" – speed is controlled by the effort level: lower levels (low, medium) provide significantly lower latency than xhigh, at which independent measurements record increased time to first token due to deeper internal reasoning.

Direct comparison of "tokens per second" between models is incorrect without fixing the same conditions (provider, effort/reasoning level, prompt length) – both companies talk about speed in their own terms, which cannot be put into a single table without independent benchmarking on the same harness.

Security, Limitations, and Guardrails

Here, the labs' approaches are diametrically opposed. Anthropic deliberately keeps Sonnet 5's cyber capabilities low: in a joint test with Mozilla on Firefox 147 vulnerabilities, the model did not create a working exploit even once, and for cybersecurity work that requires reduced limitations, the company directly recommends Opus 4.8, not Sonnet 5.

OpenAI, conversely, rates GPT-5.5's cyber capabilities as "High" according to its own Preparedness Framework and immediately implements enhanced classifiers and Trusted Access for Cyber – an extended access program for verified defenders. Independent testers also recorded a 93% pass rate on the internal cyber range and discovered a universal jailbreak within six hours of red teaming – meaning the model is more powerful in this area, but also requires a more complex containment system.

Another point on security: Apollo Research noted that GPT-5.5 "lies" about completing objectively impossible programming tasks in 29% of samples – an increase from 7% in GPT-5.4. There is no direct equivalent of this test for Sonnet 5 in Anthropic's public materials, so I cannot compare directly – but the very fact of the increase in GPT-5.5's score is worth considering if your agent workflow relies on the model's honest reports of task completion without separate result verification.

For teams where predictable, conservative model behavior in the agent cycle is critical (rather than maximum raw capability) – Sonnet 5 appears to be the safer default choice.

Multimodality and Tool Support

Capability Claude Sonnet 5 GPT-5.5
Input modalities Text, images, files Text, images
Effort levels / reasoning effort low, medium, high, max, xhigh none, low, medium (default), high, xhigh
Computer use Yes Yes
Built-in image generation No Yes (via Responses API)
Prompt caching Yes, reading from cache is significantly cheaper than base input token Yes
Structured outputs Yes Yes

An interesting coincidence: both models almost verbatim repeat each other in the nomenclature of effort levels (low/medium/high/xhigh are common to both, Sonnet 5 adds max, GPT-5.5 adds none for complete reasoning disabling). This speaks more to industry convergence towards a single mental model of "controllable depth of thought" than to borrowing in either direction.

Summary Comparison Table

Criterion Winner
Price per token Claude Sonnet 5
Long context pricing Claude Sonnet 5 (no surcharge)
SWE-bench Pro Claude Sonnet 5
OSWorld-Verified (computer use) Claude Sonnet 5 (slight advantage)
Built-in server-side tools GPT-5.5 (wider out-of-the-box set)
Cyber capabilities (for legitimate defensive tasks) GPT-5.5 (higher declared access level)
Default agent behavior conservatism/safety Claude Sonnet 5

What to choose for coding

Here I will not limit myself to retelling others' benchmarks — I ran both models through my own tasks before writing this section, because I am solving the same question for myself: what to use for the main agent loop in my own Spring Boot projects.

For classic SWE-bench style tasks (fixing bugs in real repositories, reviews, refactoring), Sonnet 5 has an advantage according to official figures and a significantly lower price for the same amount of work. In my own testing on the AskYourDocs codebase (Spring Boot, Spring AI, working with pgvector), I ran the same tasks through both models — fixing a bug in chunk indexing and a small refactoring of the service layer. Sonnet 5 consistently completed the task without intermediate prompts and, more importantly for me, wrote a test that reproduced the problem before suggesting a fix — the same as I already described in the review of the model itself. GPT-5.5 also gave a working result on the same tasks, but more often required a clarifying prompt halfway through when the task context was not entirely clear from the request itself.

This is not a strict benchmark — these are two or three real cases, not a thousand tasks with a controlled methodology, so I am not presenting it as scientific proof of superiority. However, the direction aligns with the official SWE-bench Pro figures, and that is why I trust these figures more than if they contradicted my own experience.

For long, multi-hour engineering sessions, where GPT-5.5 reports strong results on its own Expert-SWE, I do not have comparable data — I have not run 20-hour tasks through either model, and I am honestly stating this, not making up a figure retrospectively. There are no direct comparable data in principle here, because OpenAI measures this scenario on its internal benchmark, for which Anthropic has no direct analogue.

My conclusion after my own testing: for daily work on bugs, reviews, and refactoring in real production code, I would choose Sonnet 5 — both for the subjective feeling of "completing the task" and for the price, which is an order of magnitude more noticeable with frequent use than with a one-off test. However, if your main scenario is precisely long, multi-hour agent sessions on a large codebase, I would not rely on my experience or on the benchmarks of any of the companies — here it is worth dedicating a day and running both models on your own backlog task, because this is exactly the scenario where I myself do not yet have enough data for a confident conclusion.

What to choose for agent automation

On computer use, both models are close (81.2% vs. 78.7%), so the deciding factor is not raw accuracy, but the ecosystem of tools and the cost of mass execution. If the agent actively uses OpenAI's built-in server-side tools (hosted shell, tool search, image generation) without the desire to integrate them separately — this favors GPT-5.5. If the main criterion is the cost of thousands of agent calls per month and predictable, conservative model behavior — Sonnet 5 has the advantage.

What to choose for teams with a limited budget

Here the choice is unambiguous. Sonnet 5 at its starting price is 2.5 times cheaper for input tokens and 3 times cheaper for output tokens, and at its standard price — still 1.7–2 times cheaper. Add the absence of a surcharge for long context (while GPT-5.5 doubles the input cost beyond 272K tokens) — and for any high-volume scenario (mass RAG queries, production agents with a large number of calls per day), the economics are clearly on Sonnet 5's side.

Frequently Asked Questions

Which model is cheaper — Claude Sonnet 5 or GPT-5.5?
Claude Sonnet 5. At its starting price of $2/$10, it is 2.5–3 times cheaper than GPT-5.5 ($5/$30), and at its standard price ($3/$15) — 1.7–2 times cheaper.

Which model is better for coding?
On SWE-bench Pro, Sonnet 5 is ahead (63.2% vs. 58.6%). For long, multi-hour tasks, there is no direct comparable data — I recommend testing on your own code.

Which model has a larger context window?
Formally, GPT-5.5 has a slightly larger one (1.05M vs. 1M), but without the surcharge for length, Sonnet 5 is more economically viable for real-world use of large contexts.

Which model is safer for agent tasks?
Sonnet 5 consciously maintains lower cyber capabilities and shows a lower level of undesirable behavior according to Anthropic's assessment. GPT-5.5 is more powerful in this area, but also requires a more complex containment loop from the user.


Read also: