Google releases Gemini 3.8 Flash and a gated Flash Cyber model for vulnerability work
A benchmark, a pricing schedule and an access programme each teach something about how AI models are now shipped.
Google on 2 September released Gemini 3.8 Flash, a general-purpose model in its lower-cost Flash tier, alongside a restricted variant called Gemini 3.8 Flash Cyber aimed at security professionals. The announcement was published on Google's blog under its Gemini models section.
According to the post, Gemini 3.8 Flash delivers gains in software engineering, agentic tasks and multi-step reasoning. Google says the model outperforms larger models on DeepSWE v1.1, a long-horizon software engineering benchmark, and scores 54.9 percent on HLE-Verified, a multi-step reasoning test. Introductory pricing is $0.75 per million input tokens and $3.75 per million output tokens until 31 December 2026, after which the rates rise to $1.50 and $7.50 respectively.
Gemini 3.8 Flash Cyber is built for vulnerability detection and automated patching. Google reports that it exceeds previous versions on the CyberGym vulnerability-discovery benchmark, achieves a success rate above 70 percent on an internal set of real-world vulnerability detection tasks spanning 20 programming languages, and reaches 47.2 percent pass@1 on CWE-Bench patching. Google's Chrome Security team is cited as finding that the model produced 2.6 times more correct patches to Chrome vulnerabilities than the best commercial models it compared against.
The Cyber variant is not generally available. Access runs through a new Fairwind Program that Google describes as being for trusted defenders, and requires an application. The general model is available to developers in Google AI Studio, Android Studio and Google Antigravity; to enterprises through Gemini Enterprise; and to consumers in the Gemini app, Google Search's AI Mode and Google Sheets.
Why it matters
The release pairs a broadly available model with a gated one, which is becoming a pattern for capabilities that help defenders and attackers equally. A model that can find and patch vulnerabilities across 20 languages is valuable to a security team and to anyone probing that team's software, so the access decision matters as much as the benchmark. The pricing schedule, with rates doubling at year end, also signals that introductory costs for frontier-class small models are a marketing window rather than a floor. Teams building on these APIs should plan for the later number.
The release pairs a broadly available model with a gated one, which is becoming a pattern for capabilities that help defenders and attackers equally.
- Input, introductory$0.75
- Output, introductory$3.75
- Input, from 2027$1.50
- Output, from 2027$7.50
Figures: Rates published by Google on 2 September 2026; introductory pricing runs until 31 December 2026.
What you can learn from this
Model tiers trade capability for cost, but the gap is narrowing. Vendors typically ship a large flagship and a smaller, faster "Flash" or "mini" model distilled from it. Smaller models run cheaper because they have fewer parameters to compute per token. When a small model beats larger ones on a long-horizon task, it usually reflects training on many agentic trajectories rather than raw size, which is why benchmark results now depend as much on training data as on parameter count. The trade-off is that small models tend to carry less general knowledge and do worse on unfamiliar domains.
pass@1 measures a single attempt, and that is the honest number. A pass@k score reports how often at least one of k generated answers is correct. pass@1 means one shot, no retries, which mirrors how most production systems call a model. A patching score of 47.2 percent pass@1 means roughly half of attempted fixes worked first time under the benchmark's test conditions, and the rest would need human review or a retry loop before they could be merged. Benchmarks that report pass@5 or pass@10 look better but assume you can afford to run and check several attempts.
Automated vulnerability repair is a loop, not a single call. Practical systems find a candidate bug, reproduce it in a sandbox to confirm it is real, generate a patch, rebuild, and re-run the reproduction to confirm the fix. Each stage filters out false positives from the one before. Language models slot into the find and patch stages, while the reproduce and verify stages remain conventional tooling that grounds the model's output in observable behaviour.
Gated access is how vendors handle dual-use capability. Offensive security skills are symmetric: a model that can locate an exploitable flaw helps whoever runs it. Structured-access programmes restrict such models to vetted users, log usage, and can revoke access. This is a policy control rather than a technical one, and it works only as long as the same capability is not reproduced in openly available models. Access programmes also give the vendor a channel to observe how the capability is used in practice.
Input and output tokens are priced differently for a reason. Generating a token requires a full forward pass through the model for each one, while input tokens are processed together in a single batched pass. That is why output rates run several times higher than input rates. Prompts that are long but produce short answers are cheap; agents that think out loud at length are expensive, and that asymmetry should shape how you design prompts.
We teach this
How to use this in practice
Recalculate your model spend at the post-December prices. Pull last month's token usage from your provider's dashboard, split into input and output, and multiply by both the introductory and the later rates. Include any cached-token discounts your provider offers, since caching changes the input side of the bill considerably, and repeat the calculation for your projected growth in usage. Done looks like a spreadsheet showing the monthly bill under each schedule and the percentage change, so the budget conversation happens now rather than in January.
Run a five-task pass@1 check on your own repository. Choose five small, closed issues from your codebase where the fix is known, give a model only the issue text and the repository, and accept or reject its first patch by running your test suite. Use a fresh branch for each attempt and keep the model's patch as a diff so you can review its reasoning later. Five is small, but it is enough to see whether the model follows your codebase's conventions. Done looks like a score out of five and notes on the failure modes, which tells you more about fitness for your work than any published benchmark.
Compare a static analyser against a model on the same file. Install Semgrep with
pip install semgrep, runsemgrep --config autoon one module, then ask a model to review the same module for security issues. Static analysers are deterministic and fast but rule-bound; models are flexible but inconsistent, so the overlap tells you where each is reliable. Done looks like a two-column list of findings, marking which were found by both, by only one, and which turned out to be false positives.Diagram the find-reproduce-patch-verify loop for your CI pipeline. Draw the four stages and, for each, write which existing tool in your pipeline could fill it, such as your test runner for verification or a container for reproduction. Then estimate how long each stage would take per bug, since a fast finder feeding a slow verifier just builds a queue. Done looks like a diagram where every stage has a named tool or an explicit gap, with a rough time next to each.
Sources
- Introducing Gemini 3.8 Flash and 3.8 Flash Cyber — Google DeepMind
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report