Gemini 4 Argon Ships With a 1M-Token Output Limit. Here Is What That Means for Your Agents.

Cheap tokens, mixed benchmarks, and a prompt injection claim you cannot verify yet. A practical read for developers building on frontier models.

One million output tokens in a single response. That is the headline spec of Gemini 4 Argon, which Google DeepMind announced on September 30, 2026. The previous Gemini ceiling was 64K. For anyone running code migration agents or long-document pipelines, that number changes what a single model call can do.

It also changes what a single model call can break.

This post skips the launch hype and looks at Argon from the point of view of someone who has to ship an agent on top of it: what you can access, what the numbers say, and where the security responsibility actually lands. For the full breakdown with comparison data, see the original NeuralTrust analysis of Gemini 4 Argon's benchmarks, pricing and security.

What you can actually use today

Probably nothing yet. According to Google's announcement, Argon is rolling out first to trusted cyber defenders through the Fairwind Program. Paid API customers and Google AI Ultra subscribers come next, with no date attached.

When it does open up, the pricing is aggressive:

• $2 per million input tokens and $10 per million output tokens at the introductory rate
• $4 and $20 after the introductory period ends
• 95% off cached input

Google has not said how long the introductory rate lasts, and the original article notes it has not explained how reasoning tokens are billed either. Treat both as open questions in any cost model you build.

One more gap worth knowing: Google states the 1M output limit but does not state an input context window. Some outlets report 1M input as well. We could not trace that to Google, so do not assume it.

Reading the benchmarks honestly

Google's own numbers look strong. Argon posts 77.9% on DeepSWE v1.1, 51.3% on Zapier's AutomationBench, and 91.7% on LVBench for long video understanding. Google also claims the lead on the Vals Index, Vals Finance Agent v2, and Harvey's Legal Agent benchmark.

Independent evaluators paint a more uneven picture:

• Vals AI puts Argon first on its Vals Index at 68.9%, at $15.68 per test.
• Artificial Analysis scores it 52.6 on its Intelligence Index, behind Claude Opus 5.5 at 57.6 and roughly level with GPT-6 Astra at 52.7. Only Argon's "High" setting was tested.
• Terminal-Bench 4.0 is the weak spot. Vals measures Argon at 57.6% and ranks it sixth in its table, well behind the leaders on terminal-based agent work.

Argon is also token hungry. Artificial Analysis reports it used 110M tokens across its index against an 82M median. It still came out cheapest per task at $1.99 because the per-token price is low. That trade holds at introductory pricing. Double the rate and the math gets tighter.

The takeaway for builders: Argon looks best on legal, finance, automation, and long-output work. If your agent lives in a terminal, test before you switch.

The 1M output problem

Google's showcase use case is migrating C/C++ codebases to Rust, with projects ranging up to the 800K+ line Fuchsia Zircon kernel. In one example, Argon replaced 32K lines of SIMD code in libgav1, and Google reports the resulting Rust decoder runs 2.7x faster than the existing Rust port.

Impressive. Now think about the review side. A single maximal response costs up to $10 at the intro rate or $20 at standard pricing, which is fine. The hard part is that no human is going to line-review a million tokens of generated code in one pass. Long outputs need the same treatment as any untrusted artifact: chunked diffs, automated tests, staged rollout, and a rollback plan.

Long outputs also widen the data leakage surface. The more text an agent emits and passes to tools, the more places sensitive data can slip out.

"Leads the benchmark" is not a security control

Google says Argon leads Gray Swan's indirect prompt injection benchmark. It has not published a numeric score in the announcement text, and other vendors make similar claims about the same benchmark. NeuralTrust's own Claude Opus 5.5 security analysis reports that Opus 5.5 tied for the lowest injection success rate on Gray Swan's testing. Without published numbers on a shared methodology, these claims are hard to compare.

More importantly, a lower injection rate is still not zero. OWASP ranks prompt injection as LLM01 in its 2025 Top 10 for LLM Applications and is explicit that indirect injection arrives through external content like web pages and files. For agents, that also means tool output, retrieved documents, and messages from other agents. OWASP's recommended mitigations are mostly architectural: least privilege, output validation in deterministic code, segregating untrusted content, and human approval for high-risk actions.

None of those live inside the model. They live in your system.

Google lists real model-level work here: refusal training, automated red teaming, adversarial training against injection, and monitors that can halt a run based on reasoning or actions. Good. Keep it as a layer, not the layer. Also note that the Fairwind cohort is receiving Argon without cyber guardrails, by design.

Put the policy where the agent acts

The practical answer is to enforce rules at the boundary between the agent and its tools, independent of which model is generating the plan. If you swap Argon in for Opus or Astra next quarter, your controls should not change.

Here is a minimal sketch of the idea. A policy check sits between the model's proposed tool call and its execution:

from dataclasses import dataclass

WRITE_TOOLS = {"git_push", "db_write", "send_email", "deploy"}
MAX_ARGS_CHARS = 20_000


@dataclass
class ToolCall:
    agent_id: str
    tool: str
    args: dict
    source_context: str  # "user", "retrieved_doc", "tool_output"


def authorize(call: ToolCall, allowed_tools: set[str]) -> str:
    if call.tool not in allowed_tools:
        return "block"

    # Instructions that originate from untrusted content never trigger writes directly
    if call.tool in WRITE_TOOLS and call.source_context != "user":
        return "require_approval"

    # Long outputs flowing into tools are a leakage risk
    if len(str(call.args)) > MAX_ARGS_CHARS:
        return "require_approval"

    return "allow"

This is deliberately simple. In production you also want identity propagation, per-agent scopes, PII detection on arguments, and audit logs. The point is that the decision happens outside the model, so it works the same whether the plan came from Argon, Opus, or something you self-host.

That is the pattern behind NeuralTrust's Agent Gateway (TrustGate), which routes calls to any model provider and applies the same policies across MCP tools and agent-to-agent handoffs, and Agent Runtime Security (TrustGuard), which inspects prompts, tool calls, and outputs inline and can block, transform, or flag them. If you want to go deeper on threat models like tool abuse and memory poisoning, Agent Security collects frameworks and research on securing autonomous agents.

What to do this week

1. Do not plan production around Argon yet. Access is restricted and dates are not public.
2. Build your own eval set now. Use your real tasks and your own injection payloads, not vendor tables. Run it against Argon the day you get a key.
3. Model the cost at standard pricing. $4/$20, not $2/$10, and account for Argon's high token usage.
4. Gate write actions. Any tool that pushes, deploys, sends, or writes should require a policy decision outside the model.
5. Treat long outputs as untrusted artifacts. Chunk, test, and stage them before they touch anything real.

Argon looks like a credible, cheap frontier model with one unusual capability. Whether it is safe in your stack depends far more on the controls around it than on any single benchmark result.