Google's Best Bug Hunter Is a Small Model Run Five Times. You Can't Have It.

On July 21 Google shipped a Gemini variant fine-tuned for security work, and on Google's own V8 test it found 55 confirmed vulnerabilities against 36 for Claude Opus 4.6.

The result did not come from a bigger model. It came from a cheap specialist called up to five times inside a harness that merges the findings, and that pattern is yours to copy today.

The model itself goes to governments and trusted partners only, which makes this the clearest case yet of a lab shipping a capability it will not sell you.

Three models, one of them locked

Google released three Flash models on July 21. Gemini 3.6 Flash went generally available at $1.50 per million input tokens and $7.50 per million output, with computer use built in and a 17 percent cut in output tokens versus 3.5 Flash. Gemini 3.5 Flash-Lite went out the same day at $0.30 and $2.50. Both are in AI Studio right now.

The third one, Gemini 3.5 Flash Cyber, is not in AI Studio. It is not in the API. Google's own wording is that it "will be exclusively available to governments and trusted partners via CodeMender soon, expanding over time."

Flash Cyber is a small model, built on 3.5 Flash, fine-tuned to find, validate and patch vulnerabilities. It is the most interesting thing in the release, for two reasons that have nothing to do with each other.

The numbers

Google ran it against V8, the JavaScript engine inside Chrome. V8 is a brutal target. Millions of lines of performance-obsessed C++, a long history of memory corruption bugs, and years of attention from every fuzzer and every researcher with a Chrome bug bounty in mind. It is not a benchmark you clear by pattern matching on CVE writeups.

Flash Cyber found 55 unique confirmed issues. Mainline 3.5 Flash, the model it was fine-tuned from, found 47. Claude Opus 4.6 found 36. Ten of the issues Flash Cyber surfaced were missed by both of the other two.

Read that gap again. A fine-tune of a Flash-tier model beat a frontier model by roughly 50 percent on confirmed findings, in a domain where false positives are the entire problem.

The word "confirmed" is doing real work there. Flash Cyber does not just flag suspicious code. In one of Google's examples it generated what the writeup calls a 100 percent reliable remote code execution exploit that bypassed standard mitigation techniques. The model proves the bug by writing the thing that exploits it.

The harness is half the result

CodeMender, the agent this model lives inside, does not call Flash Cyber once and read the answer. It invokes the model multiple times, up to five for a single final report, so separate agents can walk different code paths. Their output gets reconciled into one consolidated report.

That is the whole trade. Instead of one expensive pass from a large model, you take five cheap passes from a small specialist and spend the savings on coverage. Five calls to a Flash-tier model still lands well under the token cost of frontier inference, which is why Google could afford to configure it that way in the first place.

This is where most teams get the lesson backwards. The interesting claim is not that fine-tuning works. It is that fine-tuning plus sampling plus reconciliation, on a model a tier below frontier, produced findings a frontier model missed. The harness was not compensating for a weak model. It was buying breadth that a single pass structurally cannot give you, because one pass picks one path through the code and commits to it.

When you can copy this, and when you cannot

The recipe is portable, with one hard requirement.

You need a machine-checkable oracle. Security research has a nearly perfect one: the exploit either fires or it does not. That is what makes five noisy passes better than one careful pass. You can afford to be wrong four times because the verification step is free, deterministic, and does not require a human to read anything.

The same shape works in other places where truth is cheap to check. Does the test suite go green. Does the query return rows. Does the generated schema validate. Does the migration apply and roll back. In those domains, fine-tune something small, run it several times against different entry points, and let a reconciliation step keep only what survives verification. You will usually beat one call to something expensive, and you will pay less.

Where it falls apart is anything scored by human judgment. Five drafts of a policy memo do not converge on correctness, they converge on average. Without an oracle, sampling more just gives you more to read, and the reconciliation step turns into an unpaid editing job.

So the honest test before you copy this: name the check that decides whether a candidate answer is right, and confirm a machine can run it. If you cannot name it, you are buying variance, not coverage.

The part that should worry you

Now the second reason this release matters.

Google is not withholding Flash Cyber because it is unfinished. Google is withholding it because it works. The stated rationale is to give frontline defenders a head start on finding and fixing critical vulnerabilities before they can be exploited, while mitigating against broader misuse.

That is a reasonable position, and it is also an admission. A model tuned to find memory corruption bugs in C++ and write reliable exploits for them does not care which side of the fence you are on. The same run that hands a Chrome engineer a patch hands someone else a working RCE. There is no defensive-only version of a working exploit that bypasses standard mitigations.

Every lab has published safety policies about dual-use capability. This is one of the first times the policy visibly changed the product line. Two models on the shelf, one behind a government pilot, all announced in the same blog post.

Plan for more of this. The gap between the best model that exists for a task and the best model you can put a credit card against is going to widen, and it will widen first in exactly the places where capability is symmetric: offensive security, biology, large-scale influence. Your security roadmap should not assume that frontier vulnerability-finding arrives in your API tier on any particular schedule. It might arrive through a vendor product like CodeMender, wrapped in an agreement, or it might not arrive at all.

What to do this week

Two things, and they pull in different directions.

First, steal the architecture. Pick one task in your stack with a real verification step, and stop reaching for the biggest model by reflex. Fine-tune or few-shot a small one, run it three to five times against different slices of the problem, and add a merge step that keeps only verified output. Measure cost and recall against your current single-call setup. Google just published the result of that experiment on a hard target, and the cheap side won.

Second, adjust your expectations about access. The assumption that anything a lab builds eventually shows up on a pricing page held for about three years. It stopped holding on July 21.