Gemini 4 Argon Lands in Cursor: 52.8% on CursorBench Matches Opus 5.5

The model arms race in AI coding tools has taken another step forward. Google's Gemini 4 Argon is now officially available in Cursor, and according to the published numbers, it scores 52.8% on CursorBench at default reasoning effort — putting it on the same level as Opus 5.5.

Two Key Numbers: 52.8% and $2/$10

For developers keeping an eye on AI coding assistants, there are two numbers worth remembering in this announcement.

The first is 52.8%. That's Gemini 4 Argon's score on CursorBench, measured at "default effort" — meaning the result wasn't achieved by maxing out the thinking budget, but reflects how the model performs in everyday use. The official announcement explicitly states this matches Opus 5.5's performance.

The second is the pricing of $2/M input, $10/M output. That price bracket is competitive among current first-tier coding models, especially considering the model it claims to match is the Opus series. For teams running large volumes of code completion, refactoring, and debugging requests daily, input token costs tend to dominate, and a $2/M input price means long-context scenarios stay more manageable than with premium-priced models.

What is CursorBench? It's a coding capability benchmark maintained by the Cursor team, with problems drawn largely from real in-editor workflows — code completion, cross-file edits, bug localization, and refactoring tasks — scored uniformly by the Cursor team in a controlled environment. Compared to benchmarks like HumanEval or SWE-bench, which lean academic or focus on repo-level fixes, CursorBench is closer to the actual experience of "writing code with AI in an IDE," which is why it's often used as a first-hand reference for how a model performs in Cursor. That said, it's still a vendor-built benchmark: the problems aren't public, the difficulty distribution is unknown, and cross-source score comparisons require attention to whether the methodology is consistent.

What $2/M and $10/M mean. Here, M stands for million tokens. LLMs bill input (the prompts and code context you send) and output (the code and explanations the model generates) separately, and input is usually much larger than output — a long-context request might stuff tens of thousands of tokens of codebase snippets into the prompt, so input pricing often determines total cost. $2/M input means $2 per million input tokens; $10/M output means $10 per million generated tokens. Output pricing being roughly 5x input is a common ratio among mainstream models today, since generation requires token-by-token forward computation, which is more compute-intensive.

What "Matching at Default Effort" Really Means

The phrase "matches at default effort" carries more weight than a simple score comparison.

Reasoning models generally involve a trade-off: the longer they think, the higher the answer quality — but latency and cost rise in tandem. Many models achieve their best scores at maximum reasoning budget, then get automatically downgraded in everyday use by tools like Cursor, creating a gap between actual experience and leaderboard results.

Gemini 4 Argon's emphasis on hitting 52.8% at default effort implies that users don't need to manually crank up the reasoning tier to get near-top-tier quality. For a latency-sensitive, high-interaction environment like Cursor, this directly affects usability.

Of course, CursorBench is only a single-dimension evaluation. How well it reflects real engineering capability — cross-file refactoring, understanding dependencies in large codebases, handling ambiguous requirements — still needs to be validated by developers on their own projects.

What is "effort" / reasoning budget? Newer reasoning models produce an internal chain of thought before answering, and the length of that thinking is controlled by a tier parameter on the tool side — commonly labeled low / medium / high, or expressed directly as a token budget. Higher tiers give the model more chances to try and self-check, typically improving accuracy on complex tasks, but also raising first-token latency and total cost. Tools like Cursor automatically select the tier based on task type, and users can manually raise it. So "default effort" refers to the tier the tool selects on its own without human intervention — not the model's capability ceiling.

Why are default-effort scores more meaningful? Many high leaderboard scores are achieved at maximum reasoning budget, and once auto-downgraded in daily use, they can't reach that level — creating the "top-tier on the leaderboard, second-tier in practice" gap. Default-effort results are closer to the real quality developers get the moment they open their editor, which is exactly why the official announcement emphasizes this testing condition.

Cursor's Model Strategy: Not Betting on a Single Vendor

Adding Gemini 4 Argon to Cursor's model list continues Cursor's long-standing multi-model strategy.

For Cursor, offering Anthropic's Opus series, Google's Gemini series, and other optional models simultaneously essentially hands the decision of "which model to use" back to users. Different tasks call for different model flavors: some teams prefer a model's stability in a particular language, others care more about cost, and still others switch between fast and slow models depending on task complexity.

The flip side of this strategy is competitive pressure. When two models tie on the same benchmark, price and real-world feel become the deciding factors. The $2/$10 pricing combined with the "peak performance at default effort" positioning is clearly an attempt to win users on the value-for-money front.

The engineering implications of a multi-model strategy. As an editor layer, Cursor doesn't train foundation models itself — it aggregates models from multiple vendors via APIs and hands routing decisions to users. This means the same code context can be sent to different models, with users switching by task. The cost is that the editor must adapt to each model's context window, tool-calling format, and streaming output protocol separately, and keep up quickly when model versions update. For users, the upside is avoiding lock-in to a single vendor's price hikes, rate limits, or outages; the downside is that behavioral differences between models make it hard to standardize prompts and rules files across a team.

How Developers Should Read This Update

For developers already using Cursor, this is more about practical implications than news value.

The pragmatic approach: take a few typical hard tasks from your own project — say, an interface refactor spanning multiple files, or refactoring legacy code with no test coverage — and run them through both Gemini 4 Argon and your current primary model, comparing result quality and token consumption. Models with similar benchmark scores often differ far more noticeably on real codebases than the leaderboard numbers suggest.

For cost-sensitive scenarios that still need strong coding capability, the $2/$10 pricing makes it a worthwhile addition to your comparison list. And if your team's workflow has been tuned around a particular model for a long time, switching purely because of one benchmark score may not be worth it.

More model choice is a good thing in itself. What really needs judging is which model delivers consistently usable results in your codebase, under your task distribution.

One-line Summary

Gemini 4 Argon lands in Cursor, scoring 52.8% at default effort to match Opus 5.5, priced at $2/$10.

Paragraph Summary

Google's Gemini 4 Argon is now officially available in Cursor, scoring 52.8% on CursorBench at default reasoning effort — which the official announcement says matches Opus 5.5 — with pricing at $2 per million input tokens and $10 per million output tokens. The article argues that "matching at default effort" deserves more attention than the score itself, since it means users get near-top-tier quality without manually raising the reasoning tier — especially important for latency-sensitive coding scenarios. Meanwhile, Cursor continues its multi-model parallel strategy, handing the choice back to users, with price and real-world feel becoming the key competitive variables between models. For developers, the pragmatic move is to run real-world comparisons using typical hard tasks from their own projects, rather than switching based on a benchmark score alone.