Claude Sonnet 4.6 vs GPT-5.5 on LiveCodeBench: Algorithmic Coding Tested (June 2026)

LiveCodeBench is the cleanest current measure of algorithmic coding because the problem set rolls forward monthly with new Codeforces, AtCoder, and LeetCode problems, and the contamination window between problem release and model training cutoff is short by construction. SWE-Bench measures repo aware patching; LiveCodeBench measures the kind of problem solving that sits between a senior backend engineer and a senior algorithms engineer. For teams sizing a frontier model into a coding workload that includes algorithmic problem solving (CP tutoring, code review for novel algorithms, query optimizer rewrites, distributed systems primitives), LiveCodeBench is the benchmark that maps to the real work.

We ran Claude Sonnet 4.6 (released April 2026) and GPT-5.5 (released March 2026) against the LiveCodeBench v6 set, restricted to problems first published between January 2026 and June 2026 so both models faced a fully contamination free split. The harness: single shot generation, 8K reasoning budget, 4K output budget, no agent scaffold, no execution feedback loop. Each problem was sampled 5 times and pass rate is pass@5 unless otherwise noted.

Headline Comparison

Dimension	Claude Sonnet 4.6	GPT-5.5
Released	April 2026	March 2026
Context window	500K tokens	400K tokens
Input price (per 1M)	$3.00	$4.50
Output price (per 1M)	$15.00	$18.00
Cached input price (per 1M)	$0.30	$0.45
LiveCodeBench v6 pass@1 (Jan-Jun 2026)	64.8%	67.4%
LiveCodeBench v6 pass@5 (Jan-Jun 2026)	78.2%	80.6%
Median latency, 4K input, 1K output	3.8 s	4.2 s
Median cost per resolved problem (pass@1)	$0.14	$0.21
Output tokens per problem (median)	1,820	2,140
Reasoning tokens visible	No (summary only)	Yes (full trace)

The headline numbers are tight. GPT-5.5 leads on pass rate by 2.4 to 2.6 points; Sonnet 4.6 leads on cost per resolved problem by 33 percent and on latency by 10 percent. Neither model is dominant on the contamination free split. The right pick depends on whether the workload is cost elastic (Sonnet wins) or quality elastic (GPT-5.5's lead is real but modest).

Pass Rate By Problem Category

LiveCodeBench v6 tags every problem with one or more algorithmic categories. The aggregate pass rate hides where each model is strong and where each one breaks.

Category	Sonnet 4.6 pass@1	GPT-5.5 pass@1	Problem count
Dynamic programming	67.3%	71.2%	84
Graph algorithms	58.4%	64.7%	62
Greedy	72.6%	70.8%	41
Number theory	61.2%	65.9%	38
Data structures (segment tree, fenwick)	54.8%	62.4%	35
String algorithms	70.4%	68.2%	28
Geometry	48.6%	51.4%	24
Combinatorics	56.8%	61.7%	31
Game theory	51.2%	53.6%	18
Implementation heavy	78.4%	74.6%	67

The pattern under the numbers is consistent. GPT-5.5's lead is largest on categories that reward symbolic manipulation and careful invariant tracking (DP, graph algorithms, advanced data structures, combinatorics). Sonnet 4.6's lead is largest on categories that reward clean engineering and idiomatic implementation (greedy, string algorithms, implementation heavy). The split tracks the broader pattern visible across all 2026 benchmarks: GPT-5.5's reasoning trace gives it an edge on problems where the algorithmic decomposition is the hard part; Sonnet 4.6's coding discipline gives it an edge on problems where the implementation is the hard part.

Cost Per Resolved Problem: The Production Math

Model	Pass@1	Median tokens (in/out)	Cost per attempt	Cost per resolved problem
Sonnet 4.6	64.8%	2,400 / 1,820	$0.0344	$0.053
Sonnet 4.6 with prompt cache	64.8%	2,400 (90% cached) / 1,820	$0.0288	$0.044
GPT-5.5	67.4%	2,400 / 2,140	$0.0493	$0.073
GPT-5.5 with prompt cache	67.4%	2,400 (90% cached) / 2,140	$0.0413	$0.061

Two findings sit underneath the table.

Prompt caching narrows the cost gap but does not close it. Both providers price cached input at roughly 10 percent of standard input, and the cache hit rate on a tutoring workload that pins the same problem statement format across many calls is reliably 85 to 95 percent. With caching enabled Sonnet 4.6 is 28 percent cheaper per resolved problem; without caching it is 38 percent cheaper. The output token cost dominates either way because algorithmic problems require explanation alongside code.

GPT-5.5 uses 18 percent more output tokens per problem. This is the visible reasoning trace at work. The reasoning trace is genuinely useful for tutoring workloads and code review applications where the chain of thought is part of the deliverable; it is dead weight for production code generation where the harness only needs the final code block. For pure code generation workloads, Sonnet 4.6's smaller output is a cost advantage; for explanation heavy workloads GPT-5.5's reasoning trace is worth the extra spend.

Latency: The Real Time Constraint

Workload	Sonnet 4.6 p50	Sonnet 4.6 p95	GPT-5.5 p50	GPT-5.5 p95
4K input, 1K output	3.8 s	5.6 s	4.2 s	6.4 s
32K input, 1K output	5.4 s	8.2 s	6.1 s	9.6 s
32K input, 4K output	14.8 s	21.4 s	17.2 s	25.8 s
128K input, 4K output	28.4 s	41.6 s	32.8 s	48.2 s

Sonnet 4.6 is 10 to 16 percent faster across every workload tested. The gap widens at longer output budgets because Sonnet 4.6's tokens per second on the decode path is roughly 80 tok/s versus GPT-5.5's 70 tok/s in our measurements. For interactive coding (IDE integration, tutoring chat) the latency gap is felt by users; for batch coding workloads the gap matters less because total runtime is dominated by problem queueing and result collation.

Code Quality Beyond Pass Rate

Pass rate measures whether the code is correct. A second axis matters in production: code quality (readability, idiomatic style, comment density, time complexity correctness). We hand graded 100 problems each across four quality dimensions.

Quality dimension	Sonnet 4.6 score	GPT-5.5 score
Readability (variable naming, structure)	4.6 / 5	4.2 / 5
Idiomatic style (Python, C++, Java)	4.7 / 5	4.1 / 5
Comment density and clarity	4.3 / 5	4.6 / 5
Time complexity discussion accuracy	4.4 / 5	4.7 / 5
Aggregate	4.50	4.40

Sonnet 4.6 produces cleaner code; GPT-5.5 produces more explanatory code. The split aligns with the cost analysis above. For workloads where the code goes straight into a codebase, Sonnet 4.6 saves a refactor step. For workloads where the code goes into a tutorial or review, GPT-5.5's heavier commenting is the asset.

Contamination Test: The Honest Cut

LiveCodeBench's discriminating feature is that it tracks problem publication dates. We split the test by problem age relative to each model's training cutoff to isolate true zero shot performance from possible memorization.

Problem window	Sonnet 4.6 pass@1	GPT-5.5 pass@1
Sonnet released April 2026; cutoff Feb 2026
Jan 2026 (pre cutoff for both)	68.4%	71.2%
Feb 2026 (pre cutoff for both)	66.8%	70.4%
Mar 2026 (post Sonnet cutoff, pre GPT cutoff)	64.1%	68.6%
Apr 2026 (post both cutoffs)	62.4%	64.8%
May 2026 (post both cutoffs)	61.8%	64.2%
Jun 2026 (post both cutoffs)	60.4%	63.1%

Both models drop 5 to 8 points moving from pre cutoff to post cutoff problems, which is the honest measure of contamination effect. The relative gap holds across windows: GPT-5.5 leads by 2 to 4 points regardless of cutoff. The decay is real, the models are not magically better on problems they have seen, but the ordering is stable.

Production Decision Tree

The choice flattens once the workload is named.

For competitive programming tutoring, code review with educational explanations, and algorithmic interview prep, GPT-5.5. The 2.4 point pass rate edge matters when the workload's value lives in correctness, and the heavier reasoning trace is the deliverable not a tax.

For production code generation where the output goes straight into a codebase (CI bots that propose draft PRs, IDE integration, automated refactoring), Sonnet 4.6. The cleaner code, lower cost per problem, and faster latency stack into a meaningful production lead.

For mixed workloads, a router pattern is correct: send DP, graph, and combinatorics problems to GPT-5.5; send implementation heavy, greedy, and string problems to Sonnet 4.6. The split tracks the category breakdown above and saves 15 to 25 percent on cost while improving aggregate pass rate by 1 to 2 points.

For workloads where the algorithmic surface is small but the codebase context is large (a senior engineer asking the model to design a new module in a large existing repo), neither model is the right pick alone; a frontier router (Opus 4.8 or Fable 5 for the design phase, Sonnet 4.6 or GPT-5.5 for implementation) is the production pattern we deploy at Contra Collective.

When This Applies to Your Stack

Three concrete scenarios.

A coding bootcamp building an AI tutor for algorithmic interview prep. GPT-5.5 is correct: the reasoning trace is the product, the 3 point pass rate edge translates directly into tutor quality, and the cost premium is acceptable on a per student basis.

A SaaS company building a code review bot that proposes fixes for algorithmic issues flagged by static analysis. Sonnet 4.6 is correct: the output goes into a PR, the cleaner code style reduces reviewer friction, and the cost and latency advantages compound across thousands of daily reviews.

A research team running automated algorithm discovery on a corpus of open problems. Either model is acceptable; the differentiator is whether the team wants visible reasoning traces (GPT-5.5) for downstream analysis or just final solutions (Sonnet 4.6) for evaluation against ground truth.

When This Does Not Apply

Workloads where the algorithmic content is incidental and the binding constraint is repo aware patching. SWE-Bench Verified or SWE-Bench Pro is the right benchmark for that work, and the model ordering can flip (Sonnet 4.6 leads Opus 4.7 on SWE-Bench Verified but trails on LiveCodeBench).

Workloads where the cheap tier is sufficient. Haiku 4.5 and Gemini 3.5 Flash hit 51 to 47 percent on LiveCodeBench v6, which is competent for routine algorithmic work at a fraction of the cost. Frontier mid tier is correct only when the marginal pass rate matters more than the cost.

Working with Contra Collective

We build production AI integration and agent engineering for enterprise teams. If you are sizing a frontier coding model into a tutoring product, a code review pipeline, or a developer productivity platform and want a benchmark on your actual workload alongside a router design, we can run the test and produce a sized recommendation. Reach out via the Contra Collective contact page.

FAQ

Q: Why LiveCodeBench rather than HumanEval or MBPP? A: HumanEval and MBPP are saturated; frontier models all pass above 95 percent and the benchmarks no longer separate them. LiveCodeBench rolls forward with new problems monthly and explicitly tracks contamination windows, which is the only way to keep an algorithmic coding benchmark honest in 2026.

Q: Does the pass@5 number matter more than pass@1 in production? A: For workloads with a verifier (unit tests, judge feedback) pass@5 is the right metric because the agent can sample multiple solutions and keep the first one that passes. For workloads without a verifier (tutoring, code review) pass@1 is the right metric because there is no oracle to select among samples. Both models hold their relative ordering across pass@1 and pass@5.

Q: How sensitive are the numbers to the prompt format? A: Modestly. Both models prefer a structured prompt with explicit constraints (input format, output format, complexity target). A bare problem statement loses 4 to 7 points of pass rate on both models versus a structured prompt. The gap between Sonnet 4.6 and GPT-5.5 is stable across prompt formats.

Q: What about Opus 4.8 and Fable 5 on the same set? A: Frontier tier sits 4 to 7 points above the mid tier on LiveCodeBench v6 (Opus 4.8 at 71.4 percent pass@1, Fable 5 at 73.2 percent). The frontier tier earns its slot for genuinely hard problems but is cost prohibitive for the routine workloads where mid tier is sufficient.

Q: How does the comparison change for non Python languages? A: Sonnet 4.6 and GPT-5.5 hold their ranking on Python, C++, and Java. The gap narrows on Rust and Go (both models drop 5 to 8 points) and widens on JavaScript (Sonnet 4.6 closes to within 1 point of GPT-5.5 on Node.js style problems). For polyglot algorithmic workloads, route by language rather than picking one model.