Gemini 3.5 Flash Cyber: What Shipped, Pricing & Who It's For

Google DeepMind's July 21 launch post says Gemini 3.5 Flash Cyber, running inside its CodeMender agent, "found and submitted validated patches for 61 vulnerabilities" across open-source projects during a limited pilot. Reuters and The Hacker News both carried the figure the same day, and @GoogleDeepMind's July 23 thread led with it. It's the line every write-up has repeated since.

So pull it apart. 61 is a real claim about a real system, but what it counts is narrower than "61 bugs fixed," and the gap decides whether this model is close to being useful to you or still a demo running on Google's home turf.

The 61 is Google's own pilot number, on repositories Google chose

The figure comes from an internal pilot, not a third-party benchmark and not a public deployment. Google DeepMind ran CodeMender, its autonomous code-security agent, with Gemini 3.5 Flash Cyber as the reasoning engine, against a set of open-source projects the company selected. Google ran the harness, Google picked the targets, and Google decided which of the agent's outputs counted as a "validated patch." No outside lab reproduced the run before the number went out.

Access is the tell here. Google shipped 3.5 Flash Cyber alongside two general-purpose siblings, Gemini 3.6 Flash and 3.5 Flash-Lite, but only the Cyber variant is gated. Per the launch post, it's available to governments and vetted security partners in a pilot, not to the general Gemini API. That means the 61 is the output of a controlled program with hand-picked participants and hand-picked codebases, which is the normal way a capability first ships, and also the reason a single headline number from it should not be read as a general benchmark.

CodeMender itself isn't new. Google DeepMind introduced the agent in 2025 as a system that traces a vulnerability to its root cause, writes a candidate fix, critiques its own work, and runs the patch through validation before a human sees it. What's new in July is the model doing the reasoning. So the 61 is really a claim about how a security-tuned Flash model performs inside an agent loop Google already built, on a workload Google already curated.

"Patched" means a fix that cleared Google's checks, not a bug closed in the world

Read literally, each of the 61 is a case where the agent detected a vulnerability, generated a candidate patch, and that patch survived CodeMender's own validation gate. That gate is the interesting part. CodeMender's design runs a generated fix against tests and static checks and its own critique pass, and discards the ones that fail. So 61 is a count of patches that passed Google's automated review, not a count of patches anyone downstream accepted.

That's a legitimate thing to measure. A model that reliably produces fixes clean enough to clear an automated gate is doing real work, and for a Flash-tier model, tuned to be cheap and fast rather than the frontier reasoner, clearing that gate 61 times is the whole pitch. The narrow reading is defensible.

The narrow reading is also all you get. The number describes the top of the funnel, where the agent produces something that looks correct to Google's harness. It says nothing about the bottom of the funnel, where a maintainer decides whether to merge it.

What the count leaves out: acceptance, false positives, and which bugs these were

Three exclusions do most of the damage to "61 vulnerabilities fixed."

• Maintainer acceptance. Google's post frames the 61 as patches "submitted," not patches merged. A patch that passes an internal validator but gets rejected upstream, because it breaks an edge case, changes behavior, or a maintainer simply distrusts machine-written security fixes, is not a fixed vulnerability. Google didn't publish a merge rate, so the real-world close rate is unknown.
• False positives and regressions. The 61 is a count of successes. It doesn't come paired with how many candidate patches the agent generated in total, how many were wrong, or how many introduced a new bug that the validation gate missed. Without the denominator, you can't tell whether 61 came from 70 attempts or 700.
• Vulnerability class. "Vulnerability" spans a huge range, from a memory-safety flaw in a C library to a logic error in an auth check. Google hasn't broken the 61 down by class or severity. CodeMender's earlier public work leaned heavily on memory-safety issues in well-structured C/C++ codebases, which are exactly the cases where automated root-cause analysis works best. If the 61 are concentrated there, the number is real but far less transferable than it sounds.

None of these is a gotcha. They're the standard gaps between a lab's internal count and a defensible security claim, and the reason a serious reader waits for the merge rate and the false-positive rate before treating 61 as evidence of anything general.

Your repo isn't the pilot's, and the Cyber price isn't public

Now put the number against your own situation, which is where it mostly evaporates.

You almost certainly can't run it. The Cyber variant is limited to governments and security partners; general developers get 3.6 Flash and 3.5 Flash-Lite through the normal channels, not the cyber-tuned model. So for most people the 61 isn't a capability you can test against your own code, it's a capability you're being told about.

Even if you had access, your codebase isn't the pilot's. Google's selected open-source projects are, by construction, the kind of well-known, well-structured repositories where an automated agent has the best shot. A sprawling internal monorepo with thin tests, mixed languages, and years of undocumented decisions is a harder target, and nothing in the 61 tells you how the model does there.

Then there's the word in the title Google hasn't filled in: pricing. The launch post did not publish a per-token or per-seat price for 3.5 Flash Cyber. The standard Flash line is Google's cheap, high-throughput tier, so the base assumption is that a Cyber variant sits somewhere near it. An agent loop that critiques and re-runs its own patches burns far more tokens than a single call, so the cost that matters is cost-per-validated-patch, not the sticker rate, and Google has published neither. Anyone budgeting around this model is guessing.

The comparison that's actually available is to the siblings. Gemini 3.5 Flash shipped earlier as Google's agentic workhorse, and 3.6 Flash and 3.5 Flash-Lite are the general models from this same drop. The Cyber model's whole claim to distinctness is the security tuning plus the CodeMender integration. The 61 is the only quantified evidence Google has offered that the tuning does something the general Flash models can't, and it's evidence produced under conditions Google controlled end to end.

The number would turn out wrong the moment Google publishes what it's currently withholding: if a meaningful share of those 61 patches were rejected by the projects they were sent to, or if the pilot repositories turn out to have been seeded with already-catalogued bugs, "61 vulnerabilities patched" collapses into "61 patches Google's own harness approved." Until the merge rate and the target list are public, that's the more accurate way to read it.