Gemini 4 Argon has been generally available since October 13, 2026, and it lifts Google’s output ceiling from 64K tokens to about 1M, so the model can “generate hundreds of thousands of tokens in a single trajectory.” Google’s developer guide documents how. A normal request still stops at 65,536 output tokens by default. Set max_output_tokens higher on the Interactions API with background: true, and the server keeps generating in hops of up to 64K until it reaches the limit, up to 1,048,576 tokens minus your input. Google warns that hard prompts take minutes.
The line worth reading twice in the launch post is not the limit. It is what Google did with output that size. Google says it has used Argon internally on C/C++ to Rust migrations ranging from “tens of thousands of lines in core libraries like re2, libgav1 up to 800K+ lines for the Fuchsia Zircon kernel,” and that those rewrites are “undergoing rigorous automated and manual auditing, emulation testing, and review before rolling out to production.” The lab that trained the model still reviews before it ships. A team whose agents can now return results under a ceiling sixteen times higher needs a review plan before it needs the model.
TL;DR
A million-token output limit moves the bottleneck from generating code to accepting it. Now that a single run can return that much, split the work into Tasks a person can review in one sitting, each with a written definition of done and a per-Task timeout, require evidence on every Task, and do the review-capacity arithmetic first. Agents research, execute, test, and report. People set direction, grant authority, and accept the result.
What changes when one run can return this much
Review capacity is the number of finished agent results a team can read, judge, and accept in a day, and it is set by people, not by the model. A higher output limit only raises how much can arrive at once.
The old ceiling worked as accidental scope control: a response could only be so long, so work came back in pieces with stopping points between them. Google’s stated reason for the new limit points the other way, toward headroom to “solve tough problems in one go.” For a reviewer, “in one go” means one result, one decision, and no checkpoint where a person could have said “wrong direction.”
The ceiling is also shared. Argon’s 1,048,576-token window covers input, thinking and output together, so a run that reads 300K tokens of code has about 748K left for thinking and writing. That is still more than anyone reads line by line in a sitting.
Then there is quality. At the announcement, Bloomberg reported anonymous Google employees saying Argon underwhelms on some coding and front-end work relative to its benchmarks; Google called that inaccurate. Google’s own table has Argon trailing on two of its four agentic coding rows (our comparison walks through them). A benchmark is a claim about a test set. Your diff is a claim about your codebase, and it gets accepted on evidence, whichever model wrote it.
Scope the Task, not the token budget
The unit you control is the Task, not the token count. Let the model’s ceiling set the size of the work and you get the largest result it can produce. Set it yourself and you get results a person can accept. Google’s own guidance agrees: keep the 65,536 default for standard tasks, and use background mode at 131,072 or 262,144 tokens for complex reasoning and coding, not the maximum.
Google’s own description already splits the work by library and kernel. Split a port the same way: one Task per module a reviewer can finish in one sitting. In Sharkly that is a parent Task with a sub-task per module, plus “blocks / is blocked by” links where one module must land first. Goal, scope, and acceptance criteria live in the Task description, for the Agent and the reviewer alike:
SH-412 Port the tokenizer module to Rust
Parent: SH-400 Port the parser library to Rust
Blocked by: SH-411 Port the shared buffer types
Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work
Two Agent settings back this up. The per-Task timeout fits the Task, not the model: above the longest honest run for one module, below the run you would regret paying for. Max concurrency (assigned tasks) caps how many modules are in flight, because forty sub-tasks running together produce forty results waiting for the same reviewer.
The decision pair: give one run the whole job when automated checks can cover the whole result, such as a mechanical rename behind a compiler and a full test suite. Split it when a person has to judge any part, which for a language migration is most of it. Runs that outlive your workday need the same preconditions: a stop condition, a waiting state, and a person who owns the morning.
Put the evidence on the Task
A large result without evidence is not a review. It is a re-run, performed by a person, slowly.
The libgav1 example shows what good evidence looks like. Google says Argon replaced 32K lines of SIMD code in an existing Rust port, and the result “runs 2.7x faster than the Rust port, with identical video output.” The second half of that sentence is what makes 32K lines reviewable: the same inputs went through old and new code, and the outputs matched. That is differential testing, and it frees the reviewer for what a comparison cannot reach: unsafe code, error paths, and whether a speedup holds on real workloads.
Every run should return four things to the Task:
| Evidence on the Task | The reviewer question it answers |
|---|---|
| Change summary | What changed, where, and why? |
| Test, typecheck, and build output | Does it still pass the checks we already trust? |
| What was verified, and how | Did behavior stay the same, and on which inputs? |
| Known limits | What should I look at myself? |
That is the shape Sharkly’s own workflow describes: the Agent runs typecheck, tests, and the build, then attaches the change summary, verification results, and known limits; a person accepts, requests changes, or decides the merge and release step. The Agent’s final response is stored on the Task and the execution log sits in the Executions tab, so the evidence returns to the Task instead of a terminal. Reviewing with task-level evidence covers the reading order, and handoff templates give the report a fixed format.
Passing checks is not acceptance, and neither is a merge: in Sharkly, merging a linked pull request does not change the Task status. Automated checks verify what they can, and AI review agents shows where that ends. A person decides whether the change does what the Task asked.
Do the review-capacity math before the run
Review is a queue: results arrive, a person clears them, and if arrivals beat clearances the queue grows. A bigger output limit changes the arrival side only. A worked example, with hypothetical inputs rather than any real project:
| Example input (hypothetical) | Value |
|---|---|
| Modules in the migration | 40 |
| Reviewer time per module, diff only | 2 hours |
| Reviewer time per module, with differential evidence and a change summary | 30 minutes |
| Hours one reviewer can give to careful review per day | 3 |
Diff only, the migration costs 80 reviewer hours, about 27 working days. With evidence on every Task, it costs 20 hours, about seven days. One huge run or forty smaller ones, the reviewer’s side of the ledger is the same size.
What changes is the decision. Forty Tasks arrive at a pace you control and each gets its own verdict. One result covering all forty modules gets one verdict, so a problem in module 31 sinks the other 39. With sub-tasks, a comment on the failing one can start a follow-up run on that Task while the rest move on.
Then do the spend math. A maxed run writes about 1M output tokens: roughly $10 at the $10-per-million rate through November 30, about $20 from December 1. On a Tier 1 project, Google’s spend-based limit is $10 per rolling 10-minute window, so one maxed run spends a whole window’s limit at the current rate and twice that limit from December 1. Keep Max concurrency low on any Agent allowed runs that long.
Run your own numbers before the first big run, not after the queue forms. Review capacity math works through the same arithmetic at the team level, and human review is the bottleneck covers the statuses and gates that make the queue visible.
A checklist before your first million-token run
- [ ] Work is split into Tasks a reviewer can finish in one sitting, with sub-tasks and “blocked by” links.
- [ ] Each Task description says what done means and what is out of scope.
- [ ] The per-Task timeout fits the Task (long background requests take minutes), not the model’s output limit.
- [ ] A maxed run fits your API tier’s spend limit.
- [ ] The Agent’s max concurrency for assigned Tasks matches what reviewers can clear, not what the Computer can run.
- [ ] Every run returns a change summary, check output, what was verified, and known limits.
- [ ] Behavior-preserving work carries a differential check against the old code.
- [ ] Each Task has a named reviewer, and acceptance is that person’s status change, never a side effect of a merge.
None of this depends on Argon, which any paid Gemini API key can now call. Google’s sentence is the template: large output, then auditing, emulation testing, and review, then production. Whichever lab ships the next jump in output size, the plan lives on the Task, not in the model. Sharkly does not pick models: per the Agents documentation, an Agent follows its Runtime’s default model, changed through Custom arguments or the tool’s configuration. When a bigger model reaches a Runtime you run, that value changes and the Tasks, evidence, and review gate stay put. Context, progress, blockers, results, and human review stay visible from request to release.
If you’re already running several agents, Sharkly gives you one place to manage their tasks and results.
