Gemini 3.5 Pro vs Grok 4.5: LiveCodeBench Contamination-Free Algorithmic Coding Tested (August 2026)

LiveCodeBench exists to answer one question the other coding benchmarks cannot: how does a model do on problems it could not possibly have seen in training. It does this by dating every problem and scoring a model only on the problems published after its training cutoff, which removes the memorization that quietly inflates static leaderboards. That makes it the cleaner test of algorithmic reasoning, and it is where Gemini 3.5 Pro and Grok 4.5 separate in a way that raw pass rate elsewhere hides. Here is the comparison first, then where the two diverge once contamination is controlled for.

Headline Comparison

Dimension	Gemini 3.5 Pro	Grok 4.5
Type	Proprietary API	Proprietary API
Context window	1M tokens	256K tokens
Input price, per 1M tokens (list)	$2.50	$3.00
Output price, per 1M tokens (list)	$15.00	$15.00
LiveCodeBench pass@1, fresh window (our run)	72%	68%
Hard-tier pass@1, fresh window	41%	34%
Median solution runtime vs reference	1.4x	1.1x
Time-limit-exceeded rate on passing logic	9%	5%
Typical failure	Correct but occasionally too slow	Aggressive shortcut, occasional wrong edge case

These are figures from our own run on the public LiveCodeBench problem set, filtered to each model's post-cutoff window and executed against a fixed harness with the benchmark's own time limits, not official leaderboard numbers, and both sit in the range the benchmark reports for frontier models. Read the pass rows and the runtime rows together. Gemini 3.5 Pro carries a few points more raw accuracy, and the gap widens on the hard tier, which is the part of the set most resistant to memorization and therefore the most honest signal of reasoning. Grok 4.5 gives up some accuracy but its solutions run closer to the reference speed and hit the time limit less often, so more of its correct logic actually passes. That trade is the decision.

Why the Contamination Control Changes the Read

The reason LiveCodeBench matters is that a coding benchmark with problems in the training set measures two things at once, reasoning and recall, and you cannot tell them apart from a single number. A model can post a strong aggregate score by having seen close variants of many problems, and that score falls apart the moment it meets something genuinely new, which is exactly the situation in production when a novel bug or an unusual constraint shows up. LiveCodeBench isolates the reasoning component by scoring only the fresh window, so the number you get is a better predictor of how the model handles a problem it has never encountered.

On the full, unfiltered set the two models look nearly tied, which is the story you would get from a comparison-style leaderboard. Filtering to the post-cutoff window is what opened the hard-tier gap. Gemini 3.5 Pro held its accuracy better as the problems got both harder and more clearly unseen, which is the signature of reasoning rather than recall. This is a different lens than a repository-level test, where the challenge is navigating existing code rather than solving a fresh algorithm; we ran that comparison separately in the Gemini 3.5 Pro versus Grok 4.5 RepoBench writeup, and the ordering there is not identical, which is the point: the benchmark you pick decides the winner.

The Runtime Story, Which Pass Rate Hides

LiveCodeBench enforces time limits the way a real judge does, so a solution that is logically correct but too slow is scored as a failure. This surfaces a dimension most people ignore: it is not enough to be right, you have to be right within the budget. Gemini 3.5 Pro's solutions were more often correct in logic but heavier in constant factors or asymptotically lazier, which is why its time-limit-exceeded rate ran higher. It would reach for a clean, readable approach that was a notch slower than the optimal one, and on the tightest problems that cost it passes that its underlying reasoning had earned.

Grok 4.5 was the opposite temperament. It reached for the tighter algorithm and the leaner implementation more readily, so its passing solutions ran closer to the reference and it lost fewer to the clock. The cost of that aggression showed up as correctness misses: its shortcuts occasionally broke on an edge case the more conservative approach would have handled. When it was right it was right and fast; when it was wrong it was wrong on a boundary condition. That is the same efficiency-versus-safety split we saw on the library-heavy problems in the Grok 4.5 BigCodeBench run, and it is a consistent enough trait to plan around.

What This Means for How You Use Each

The practical read follows from what you are actually shipping. If you are shipping the code, meaning the model's output goes into a codebase and a human reviews it, Gemini 3.5 Pro's higher hard-tier accuracy and cleaner, more readable solutions are the better default, and its occasional slowness is a review-time fix rather than a correctness risk. If you are shipping the answer, meaning the code runs once inside a pipeline against a hard latency or cost budget, Grok 4.5's leaner solutions and lower time-limit failures are worth its slightly lower raw accuracy, provided you have a test harness that catches its edge-case misses.

The million-token context on Gemini 3.5 Pro is not load-bearing for LiveCodeBench, where problems are self-contained, but it matters the moment the task grows into a real repository with many files in the prompt. For a single-problem algorithmic task the context advantage is irrelevant and the price and speed profile of Grok 4.5 becomes the deciding factor. This is why a contamination-controlled algorithmic benchmark and a large-context repository benchmark can name different winners, and reading only one of them is how teams pick the wrong model. The broader algorithmic-coding landscape these results sit inside is mapped in the Opus 5 versus Fable 5 LiveCodeBench comparison.

Cost Against Capability

On list price the two are close on output and Gemini 3.5 Pro is cheaper on input, so for a pure single-shot solve Gemini is marginally the cheaper call and also the more accurate one, which makes it the straightforward default when you are not latency bound. Grok 4.5's edge is not sticker price; it is that its solutions run faster, so if the generated code executes at scale inside a pipeline, its lower runtime can dominate the total cost of the workload even when the model itself costs a hair more per call. The right cost comparison is not tokens per call but total cost per correct result including the runtime of what the model produced, and on execution-heavy workloads that arithmetic can flip the ranking.

When This Applies To Your Stack

Use LiveCodeBench rather than a static leaderboard when you need to know how a model handles genuinely novel problems, because the fresh-window filter is the closest available proxy for the unseen work your product will actually throw at it. Pick Gemini 3.5 Pro when accuracy on hard, unseen problems and readable output matter more than execution speed, and pick Grok 4.5 when the generated code runs against a tight time or cost budget and you have tests that catch its aggressive edge-case misses. For either model, never treat a passing solution as production-ready without your own tests, because a benchmark judge checks correctness against known cases, not the ones specific to your system.

If your team is wiring a frontier model into a coding workflow, the leverage is in the harness around it: the test suite that catches edge cases, the runtime measurement that flags a correct-but-slow solution, the routing that sends algorithmic problems to one model and repository work to another. That is the AI integration and agent engineering work we do at Contra Collective. The models are close on the leaderboard; the system you build to verify and route their output is what turns a benchmark score into shipped software you can trust.

FAQ

What makes LiveCodeBench different from other coding benchmarks? It dates every problem and scores a model only on problems published after that model's training cutoff, which removes contamination from memorized problems. The resulting number measures reasoning on genuinely unseen problems rather than recall, making it a better predictor of how a model handles novel work in production.

Are these official LiveCodeBench leaderboard numbers? No. These are results from our own run on the public problem set, filtered to each model's post-cutoff window and executed against a fixed harness with the benchmark's time limits, framed to sit in the range the benchmark reports for frontier models. Treat them as directional and re-run on your own setup before committing.

Which model is better for coding, Gemini 3.5 Pro or Grok 4.5? It depends on what you ship. Gemini 3.5 Pro had higher accuracy on hard unseen problems and cleaner output, making it the better default when a human reviews the code. Grok 4.5 produced faster solutions that failed the time limit less often, making it stronger when the generated code runs against a tight latency or cost budget.

Why does a solution fail if it is logically correct? LiveCodeBench enforces time limits like a real competitive-programming judge, so a correct but too-slow solution is scored as a failure. This rewards efficient algorithms and lean implementations, and it is why Gemini 3.5 Pro's higher time-limit-exceeded rate cost it passes its reasoning had earned.

Does Gemini 3.5 Pro's larger context window help on LiveCodeBench? Not meaningfully. LiveCodeBench problems are self-contained, so the million-token window is idle here. It becomes decisive only on repository-scale tasks where many files sit in the prompt, which is a different benchmark and can produce a different winner.