Google Gemini 4 Argon: An evaluation

Gemini 4 Argon passes 85.66% of the tasks it is tested on. In our evaluation, it also produces more blocker vulnerabilities than blocker bugs. Passing tests and being safe to ship are different questions, and this model shows the gap clearly. Most of its findings are maintainability issues. Most of its severe findings are security issues.

How was Gemini 4 Argon evaluated?

Model: Gemini 4 Argon, high reasoning effort

Language: Java

Benchmark: the same Java benchmark we use for every model, covering HumanEval, MBPP and ComplexCodeEval. The run records 4,444 tasks. All of them are analyzed for code quality and security, which is where every density figure below comes from. Of those, 544 of them ship with executable tests, and the pass rate covers only those.

Analyzer: SonarQube systematic code analysis. Complexity and code smell densities are per 1,000 lines of code (kLOC). Bug and vulnerability densities, and all category breakdowns, are per million lines (mLOC).

Three terms worth defining first:

• Cyclomatic complexity: counts independent paths through a function.
• Cognitive complexity: a SonarQube metric that weights nested and deeply branched logic more heavily, reflecting how hard the code is for a human to read.
• Severity: the impact level a finding carries, inherited from the rule that raised it. It describes how much a finding affects the software qualities Sonar measures. It is not a prediction of how likely that code is to reach production.

Gemini 4 Argon key metrics at a glance

Metric

Gemini 4 Argon

Lines of code (total)

619,852

Functions

85,245

Comments density (% of LOC)

4.6%

Cyclomatic complexity per kLOC

244.39

Cognitive complexity per kLOC

148.97

Bugs

347

Vulnerabilities

193

Code smells

9,626

All findings

10,166

Overall issue density per kLOC

16.40

Functional skill (pass rate)

85.66%

Missing completions

1.55%

What is Gemini 4 Argon's functional pass rate?

The pass rate is 85.66% across the 544 test-backed tasks, which is 466 solutions passing and 78 not. Roughly one in seven fails its tests. Of all 4,444 tasks, 69 returned no usable code at all, which is 1.55%.

That matters because 33 of them fall inside the 544 test-backed tasks, the same set the pass rate is drawn from. A task with no completion produces nothing to analyze and nothing to run, so it is not a failed attempt so much as an absent one. If you are planning around this model, treat the pass rate and the completion rate as two separate questions.

How much code does Gemini 4 Argon generate?

Gemini 4 Argon generated 619,852 lines across the benchmark, spread over 85,245 functions and 22,656 classes.

That function count is the number to notice. It works out at 7.3 lines per function and about 3 statements each, with roughly 27 lines per class. This is code built from many small pieces rather than a few large ones.

Fine-grained functions are generally easier to read and test one at a time. The trade is that following a single operation can mean moving through more of them, so reviewers spend more time on call paths and less on any individual body.

Comment lines total 30,029, which is 4.6% of output. There is a reasonable amount of inline context for anyone picking the code up later.

How complex is Gemini 4 Argon's generated code?

Cyclomatic complexity is 244.39 per kLOC and cognitive complexity is 148.97 per kLOC.

Read those two together rather than separately. Cyclomatic counts decision points. Cognitive weights the nested ones more heavily. Cognitive sitting well below cyclomatic says the branching is frequent but mostly flat, so there are many decisions and comparatively little logic buried inside other logic.

Combined with 7.3 lines per function, that is a consistent picture: short functions, plenty of branches, shallow nesting. Neither figure tells you whether the code works, but both indicate how much a reviewer has to hold in their head at once, and shallow beats deep on that measure.

What bugs does Gemini 4 Argon generate?

It produced 347 bugs across the benchmark, a density of 560 per mLOC.

Reliability severity

Per mLOC

BLOCKER

CRITICAL

MAJOR

310

MINOR

182

The severity profile is weighted toward the middle. Blocker and critical together are 42 findings, or 12% of all bugs, and major carries more than half the total on its own. For a team triaging reliability work, most of it sits in the tier that wants fixing without stopping the release.

Bug category

Per mLOC

Concurrency / threading

Performance / structure

Exception handling

Type safety / casts

API contract violation

Resource / stream leaks

Null / data value

Pattern / regex

Control flow mistake

Uncategorized

Data structure

No single bug category dominates, and that has a practical consequence. The largest, concurrency and threading, is 58 findings, or 17% of the total. The next six all land between 34 and 57. Seven categories therefore cover 319 of the 347 bugs with no single one carrying the group.

The consequence is that there is no single lever for bug remediation here. A team that fixes every concurrency finding has cleared 17% of the reliability work and left six other categories largely untouched.

Concurrency findings still deserve attention disproportionate to their count. They are among the harder bugs to catch in review and to reproduce once they ship, because they depend on timing and on the environment they run in. The rules that flag them are narrow and specific: double-checked locking, a lock not released on every path out of a method, synchronizing on a field that gets reassigned, a counter incremented on a volatile field, and calls to wait or notify made without holding the lock.

What security vulnerabilities does Gemini 4 Argon generate in code?

Gemini 4 Argon produced 193 vulnerabilities, a density of 311 per mLOC. This is the smallest group of findings by volume and the most severe by profile.

Security severity

Per mLOC

BLOCKER

CRITICAL

213

MAJOR

MINOR

Blocker and critical together are 154 of the 193 findings. Four out of five security findings sit at critical or above, which is the inverse of the bug profile, where the same two tiers were 12%.

The blocker row is the one to sit with. There are 22 blocker vulnerabilities here, which is more than the 21 blocker bugs, even though there are 347 bugs and only 193 vulnerabilities. Put across the whole run, vulnerabilities are 1.9% of all findings and 28% of the blocker-level ones. Security is a small share of the work and a large share of the risk.

Vulnerability category

Per mLOC

Cryptography misconfiguration

127

Insecure system resource handling

Inadequate error handling (I/O)

XML external entity (XXE)

Uncategorized

Injection attack

Hard coded credentials

Certificate validation omissions

Web API security misconfiguration

Path traversal injection

Where the bugs were spread thin, the vulnerabilities concentrate. Cryptography misconfiguration and insecure system resource handling together are 129 of the 193 findings, so two categories hold two thirds of the security surface. Both are well covered by automated analysis. Where reliability review has to stay broad, security review can be narrowed to two categories and still cover most of it.

Crypto misconfiguration covers weak algorithms, insecure key sizes, and random number generators used in ways they should not be.

The long tail is short but worth naming because the categories are specific. Hard coded credentials appears 7 times and path traversal once. These are small numbers, and they are the kind of finding where one instance reaching a production branch is the problem rather than the volume.

How maintainable is Gemini 4 Argon-generated code?

The run produced 9,626 code smells, a density of 15.53 per kLOC. This is 95% of all findings by volume.

Maintainability severity

Per mLOC

BLOCKER

CRITICAL

2,691

MAJOR

6,321

MINOR

5,814

INFO

645

Major and minor carry 7,522 of the 9,626 findings between them, and blocker is 36. The volume is real but it sits low on the severity scale. The 1,668 critical findings, 17% of the total, are the part to prioritize.

Code smell category

Per mLOC

Collection / generics parameter type

3,896

Design / framework best practices

2,559

Regex / pattern / string format

1,881

Cognitive computational complexity

1,721

Naming / style / documentation

1,497

Dead / unused / redundant code

1,366

Assignment / field / scope visibility

1,144

Control / conditional logic

994

Deprecation / obsolete API

329

Uncategorized

137

Structure / architecture

Collection and generics is the largest category at 25% of all smells. One caveat on reading any row in this table: each category groups a lot of rules, 17 Java rules in the case of collection and generics, and they are not all the same kind of problem. That row spans raw types and missing type parameters, redundant casts, and collection handling that could be simpler, so the total does not tell you how much of it is any one of those.

How many tokens does Gemini 4 Argon use?

Tokens

Gemini 4 Argon

Input

1,517,336

Output

6,362,719

Reasoning

11,886,018

Total

19,766,073

One accounting note before reading these. In this run, reasoning tokens are reported separately from output tokens rather than inside them, and the three figures add to the total. Not every provider reports it this way, so this is not a number to set against a reasoning figure from another model without checking first.

The headline is the ratio. Gemini 4 Argon spent 11.9 million tokens reasoning and 6.4 million producing code, which is about 1.9 thinking tokens for every token written. Reasoning alone is 60% of the total spend.

Per line of generated Java that works out at roughly 10 output tokens and 19 reasoning tokens. This is a model that deliberates, which is consistent with the high reasoning effort setting this run used. If you are budgeting for it, the reasoning side is the larger line item by a wide margin.

What are the biggest risks of using Gemini 4 Argon-generated code in production?

Three places to point verification effort.

Security is first, and it is first by severity rather than by volume. There are 22 blocker vulnerabilities and 132 critical ones, in a group that is under 2% of all findings. Two categories hold two thirds of it, and both are well covered by automated analysis, so of the three risks here this is the one that narrows down cleanly.

The spread of the bugs is second. With 347 bugs spread across seven categories of roughly the same size, reliability review cannot be narrowed to one or two rule groups. Clearing the largest category, concurrency, addresses 58 findings and leaves 289. Plan for breadth.

Missing completions are third. In total, 69 tasks returned nothing, and 33 of those sit in the test-backed subset. This is not a code quality measure at all, which is exactly why it is easy to miss. A task that produces no code produces no findings and no test result, so it looks clean in every table in this article.

Three takeaways:

• Most findings are maintainability issues. Security findings are the most severe. Code smells are 95% of the 10,166 findings. Vulnerabilities are 1.9% of them, but 80% of those are blocker or critical, against 12% of bugs and 18% of code smells.
• Bug remediation has no single lever. The largest bug category is 17% of the total, and seven categories are all roughly the same size. Reliability review has to stay broad.
• It spends more on reasoning than on writing. It used 11.9 million reasoning tokens against 6.4 million output tokens, and 19.8 million in total. The total is about two and a half times the GPT-6 runs we have published, which used medium effort where this run used high. If you are estimating spend, start from the reasoning figure rather than the amount of code you expect back.

What to do next

If you adopt Gemini 4 Argon, point automated checks at cryptography misconfiguration and insecure resource handling first. Together they hold two thirds of its security findings. Keep reliability review broad, because no single bug category carries the load. And track missing completions separately, because a task that returns no code never shows up as a finding. SonarQube flags the first two through algorithmic analysis on every change, at the speed the model writes code.

Full evaluation results for Gemini 4 Argon, along with every other model we have measured, are on the Sonar LLM Leaderboard.