Google announced Gemini 4 Argon on September 30, but the first users are trusted cybersecurity defense teams rather than every chat user. The company described the staged opening in its Gemini 4 Argon announcement.
| User group | Access status |
|---|---|
| Trusted cybersecurity defense teams | First wave of gradual access |
| Paying API customers | Prioritized later |
| Google AI Ultra subscribers | Prioritized later |
| Other users | No schedule announced |
As of October 1, 2026 in Beijing, Google had not published a date for broader availability.
A new model release usually prompts two questions: how much stronger is it, and when can I use it?
Gemini 4 puts a third question first. If a model can find a vulnerability, verify it, modify code, and continue through a long task, who should receive that capability before everyone else?
That question matters more to AI product builders than another argument about which model is strongest. What the model can do, what it is allowed to do, and who is responsible when it acts are becoming three parts of the same product decision.
Opening to Defenders First Is Not an Ordinary Beta
Early access runs through the Fairwind program. It serves defenders in important sectors such as government, healthcare, and telecommunications. Some partners can use Argon and connect it to the CodeMender code-security tool. The program combines access with use review and governance, and limits authorization to defensive and research work. Google DeepMind describes those controls on the Fairwind program page.
This explains why an announcement does not mean universal availability.
A tool that can discover weak points can help maintainers patch them before an incident. The same capability can also help an attacker locate an entry point faster. Restricting the first users does not mean the model can perform only security tasks. It means Google selected an initial environment with named operators, a defined purpose, and a responsibility structure.
For a defense team, finding a vulnerability is only the beginning. The team must reproduce the behavior, prepare a repair, test it, review the change, and deploy it. Each step can touch a real system. As a model becomes able to continue across more of that sequence, its permission boundary cannot depend on a prompt that merely says “be careful.”
Google’s earlier frontier safety framework placed risk assessment and mitigations inside pre-release review rather than waiting for complaints after deployment. It also said that large internal deployments can require safety assessment. The company explains that position in its strengthened Frontier Safety Framework.
For enterprise AI builders, the order is practical: define who can use the system, what it can access, and where execution must stop before wiring the model into production work.
Where Is It Stronger? Google Started With Its Own Engineering
Answering a difficult benchmark question and operating inside the developer’s own production environment are different forms of evidence. The more useful part of the Argon launch is Google’s description of internal engineering work.
Start with code. Google says Argon agents are participating in C and C++ migrations to Rust, including core libraries and the Fuchsia Zircon kernel, which contains more than 800,000 lines. The work is underway; the statement does not mean every generated change has already shipped. Critical systems still go through automated and human audits, simulation, testing, and review. The details appear in the launch announcement.
A narrower example involves the libgav1 video-decoding library. Starting from an existing Rust port, the agent repeatedly ran performance experiments, inspected compiler output, and replaced 32,000 lines of SIMD code. Google reports that the result produced the same video output and ran 2.7 times as fast as the previous Rust version. The comparison is with that Rust implementation, not the original optimized C++ version. It should not be rewritten as “AI made every codebase 2.7 times faster.”
Then look at memory. Google also says a group of Argon agents analyzed data-center performance telemetry, identified memory optimizations, implemented changes, and freed more than 300 TiB after deployment. That claim is more concrete than saying the model is good at coding: it connects monitoring data, diagnosis, implementation, and a measured operational result. These examples are company-reported and have not been independently audited.
They also clarify what “multi-step work” means. Generating code is one step. Running experiments, comparing behavior, passing review, and validating a deployed result are separate steps. AI can participate in a longer engineering process without eliminating acceptance work.
Finance, Legal Work, and Operations Are Not Just Chat Tasks
In the Vals AI leaderboard updated on September 30, Argon scored 68.9% and ranked first on the Vals Index. The index covers finance, programming, legal, and tax tasks and weights them by the associated industries’ share of the US economy. It measures a task set, not revenue or productivity already realized by customers. The ranking and method are available on the Vals Index page.
Google’s capability table extends beyond programming. The following rows compare the same benchmark within each row; the scores are not interchangeable across rows. The source is the Gemini model evaluation page.
| Evaluation | Argon | GPT-6 Astra |
|---|---|---|
| Vals Finance Agent v2 | 65.4% | 53.5% |
| Harvey legal agent evaluation | 19.6% | 5.4% |
| AutomationBench | 51.3% | 41.4% |
| LVBench long-video understanding | 91.7% | 87.5% |
| Agent’s Last Exam | 39.5% | 34.2% |
| OSWorld 2.0 offline subset | 69.2% | 72.6% |
Bold marks the higher of the two displayed models in that row. It does not mean the score is highest among every model, and scores from different evaluations cannot be directly compared.
The finance evaluation concerns multi-step research. The legal test includes research and drafting. AutomationBench measures end-to-end business tasks. These results suggest product directions, but they do not automatically translate into customer time saved or fees avoided.
Professional work is also not limited to reading text. The model page reports performance on charts and long videos. A product that depends on visual material should test that capability directly instead of assuming a strong composite score proves reliability.
The table also preserves a loss: Argon’s score on the OSWorld 2.0 offline subset is below Astra’s. Stronger performance in a professional research test does not establish a universal lead in computer operation.
Stronger Coding Still Does Not Mean Winning Every Coding Test
A first-place aggregate score does not mean every existing workflow should switch.
Google reports 77.9% for Argon on DeepSWE v1.1, above Astra’s 74.1%. On FrontierSWE v2, Argon scores 55.0% and Astra scores 65.5%. These are company-published comparisons without independent audit, and the tests should not be read as one shared success rate. The figures appear on the Gemini evaluation page.
The difference is more useful than a claim of total superiority. Migrating a codebase, fixing an issue in an existing repository, and generating a new application are different jobs. Product teams should evaluate the task that appears most often in their own product and fails most expensively.
Leaderboards can reduce the number of candidates. They cannot accept a product result on the buyer’s behalf.
Google’s methodology also limits how these numbers should be interpreted. Unless stated otherwise, Argon uses a single attempt at the highest thinking setting. Results come from public leaderboards or Google testing rather than one completely uniform contest. DeepSWE uses the mini-swe agent framework, and video evaluations provide different models with different frame counts because of API constraints. The company documents those conditions in the Argon evaluation methodology.
Both the score and the operating setup matter: task definition, tools, number of attempts, and compute budget. A long-video result is not an accuracy guarantee for every video product, and a partial computer-use benchmark is not a complete workflow success rate.
A Million Output Tokens Is Not a Million-Token Context Window
Argon raises the output-token limit to one million. That is an output limit, not the input context window. Google makes the distinction in the release announcement.
Context determines how much material the model can receive in one task. Output capacity determines how much reasoning and generated material it can produce along one trajectory. Both can affect complex work, but they are not the same capability.
A larger output budget gives a difficult task more room to continue. For a product team, however, the ability to generate more does not prove that generating more is desirable.
If a report requiring human verification becomes ten times longer, the checking burden may also grow. If an agent explains a code change at great length, the final decision still depends on whether the tests pass and whether behavior remains correct.
Longer output should therefore come with clearer stopping conditions: finish when acceptance criteria are met, roll back when validation fails, and request confirmation before a high-risk action. “The model can keep thinking” is not a reason to let a task continue indefinitely.
The product implication is that output capacity must be paired with orchestration. Teams need checkpoints, evidence, budget limits, and escalation paths. The limit is a resource, not an operating policy.
A Low Token Rate Does Not Guarantee a Cheap Task
Google published introductory rates and the prices that will apply after the promotion:
| Cost item | Introductory rate | After the promotion |
|---|---|---|
| Input tokens | $2 | $4 |
| Output tokens | $10 | $20 |
All figures are per million tokens and exclude other service charges. The announcement does not specify when the introductory period ends. The figures come from Google’s pricing disclosure.
The $2 input figure should not be treated as the price of a completed task.
At the published rate, 100,000 output tokens cost $1 during the introduction and $2 afterward. That is arithmetic for the output portion, not a task quote. Input, retries, tools, and other service charges remain outside the example.
If Argon completes in one attempt a job that another model repeatedly fails, a higher per-run bill may be justified. If it merely produces a longer answer where the previous output was sufficient, extra usage may create no value.
The useful operating metric is cost per accepted result. Multi-step work also carries the cost of failed runs, human corrections, and review time. None of those costs appears in a token-rate table.
This is especially important when model capability invites a product to attempt larger tasks. A cheaper million tokens can still support an expensive workflow if the agent runs for longer, retries more often, or leaves a larger artifact for a person to inspect.
The Next Step for Builders Is Not an Immediate Model Swap
Gemini 4 expands the set of tasks worth testing seriously. It does not issue an automatic upgrade notice to every AI product.
A team can begin with one difficult existing job: long-document research that often misses requirements, code changes that routinely fail tests, or an operational task that stalls before completion and needs a human handoff. It should preserve the current model’s result, latency, error pattern, and cost, then run the same job on Argon when access arrives.
If the result improves but takes longer, which service tier can support it? If the model needs broader permissions, which actions still require confirmation? If the introductory price ends, can the product’s current pricing absorb the standard rate? Those questions are closer to a business than adding “Powered by Gemini 4” to a product page.
Google has said that paying API customers and Google AI Ultra subscribers will receive priority in later access, but it has not announced a date. That status remains part of the launch announcement.
The waiting period can be used to prepare representative tasks and acceptance criteria. When access becomes available, the first action should not be removing the old model. It should be asking whether the job that consistently failed before can now pass a real product test.
Argon’s restricted opening is itself a product lesson. Greater capability makes permission design, verification, and unit economics more important, not less. A model is ready for a workflow only when its output can be accepted under the workflow’s actual risk and cost constraints.