One Million Tokens Out: What Gemini 4 Argon's Output Cap Changes for the People Who Have to Run It

Argon raises the single-response ceiling from 64K to 1M tokens. The number is a trajectory, not an answer. What it does to the clock, the bill, the retry and the review, with 24 sources.
Here is the whole argument up front. Gemini 4 Argon's one-million-token output limit is the first spec in a year that changes engineering rather than pricing, and almost nobody is treating it that way. It is not a longer answer. Google's own sentence says what it is: headroom for the model to think deeply and generate hundreds of thousands of tokens in a single trajectory, up from 64K on earlier Gemini models S1. A trajectory that long is a job, not a request. It can run for hours at the generation speeds practitioners have measured on this generation of models, it can cost $10 at introductory pricing and $20 after, it cannot be retried as a unit without paying for everything that came before the failure, and it cannot be reviewed by a human who reads tokens. Every one of those is a problem you already solve for batch jobs, and none of them is a problem a chat-shaped integration solves for you. The output cap is a new primitive. Treat it like one.
I started this as a benchmark post. Argon leads DeepSWE v1.1 at 77.9% and loses Terminal-Bench 4.0 to Opus 5.5 by nine points, and the pattern of where it wins and loses is interesting S1S2. Then I wrote down the output cap next to the other caps, 128K on Opus 5.5, Fable 5.1, Sonnet 5.5 and GPT-6.1 Sol, and 64K on Gemini 3.8 Flash S3S4S5, and realised the benchmark table was the less interesting half of the announcement. This is the other half, including the number I misread first.

FIG. 01 · Maximum output per response, September 2026 · Argon's cap against every model it was benchmarked against S1S3S4S5
What is the number, exactly?
The first thing I wrote down was "Argon can write a million tokens." That is not what Google wrote. Google's announcement says the output limit is being expanded to support longer, more complex use cases, and that when the model has the headroom to think deeply and generate hundreds of thousands of tokens in a single trajectory, it adds depth of reasoning to solve tough problems in one go S1. Three words in that sentence do the work: think, trajectory, hundreds.
Think, because the cap includes the model's reasoning. On every reasoning model in this comparison, thinking tokens count against the output limit and bill at the output rate: that is how the GPT-6.1 Sol model page describes its 128K cap, and how Anthropic bills thinking on Sonnet 5.5 and Opus 5.5 S4S6. Google's announcement says nothing about whether Argon's reasoning tokens bill at the output rate, which two day-one write-ups flagged as the open question S7. Until Google publishes the model page, the safe assumption is the industry one: the million is a thinking-plus-text budget, and most of it is thinking you never see.
Trajectory, because the examples Google gives are not documents. For libgav1, its open-source video decoder, Argon agents took an existing Rust port and replaced 32,000 lines of SIMD code by running many rounds of profile-guided experiments, studying the compiler's output and producing safe Rust the compiler would vectorise, ending at 2.7 times the Rust port's speed with identical video output S1. Many rounds of experiments is an agent loop. The output cap is what lets that loop live inside one response instead of being chopped into re-prompted turns S7S8.
Hundreds, because Google's own description of the realistic case is hundreds of thousands of tokens, not a million. The million is the ceiling. A Hacker News commenter made the same point from the other side: the practical change is that a run no longer errors at 64K S9.
So the number is a ceiling on a single trajectory of reasoning, tool use and text, and the realistic size of the thing it enables is a few hundred thousand tokens. Everything below follows from that reading, not from the headline.

FIG. 02 · What fills a long trajectory · thinking, tool calls and text against the old caps and Google's realistic range S1S4
How long does a million tokens take?
This is the question none of the launch coverage asked, and it is the one that decides whether a 1M-token response is a request or a job.
Models generate tokens one at a time, as the same Hacker News thread was quick to note, so a long trajectory is a long wait S9. Google has not published Argon's throughput, and Argon is not available to measure, so the honest move is to use the speeds this generation's models actually run at and see what a million tokens costs in wall-clock time.
Anthropic's SDK encodes an assumption. Its non-streaming timeout scales as sixty minutes multiplied by max_tokens over 128,000, which is to say the SDK budgets an hour for a full 128K response, or about 36 tokens per second S10. At that rate a million tokens is 7.8 hours. OpenRouter measures GPT-6.1 Sol at about 63 tokens per second, which makes a million tokens 4.4 hours S11. Simon Willison's Sonnet 5.5 run at xhigh produced its answer in 41 seconds for 5.74 cents of output, roughly 140 tokens per second, which makes a million tokens two hours S12. OpenAI's forthcoming Ultrafast tier claims 300 tokens per second, which would make it 55 minutes S13.

FIG. 03 · Wall-clock time for one million output tokens at speeds this generation actually runs at · Argon's own throughput is unpublished S10S11S12S13
Pick any bar. None of them fits in an HTTP request. Google's own background-execution page says standard HTTP requests typically close after 60 seconds S14. Anthropic's SDK refuses a non-streaming request whose max_tokens implies more than ten minutes, which works out to about 21,000 tokens, and its errors page tells you to use streaming or the Batches API for anything longer S10S15. OpenAI's background mode exists because, in its words, reasoning models can take several minutes to solve complex problems S16. All three vendors built machinery for requests that outlive a connection, and the machinery is different on each.
- Anthropic: stream it, or batch it. The SDK's rule is a ten-minute ceiling for non-streaming calls, scaled by
max_tokens; above that you stream and handle reconnects yourself, or you submit to the Batches API and collect later S10S15. There is no server-side resume cursor on a dropped stream. - OpenAI: background mode on Responses. Set
backgroundto true, poll the response by id, cancel it, or stream it with astarting_aftercursor so a dropped connection resumes where it left off. Background responses are stored for roughly ten minutes to enable polling, which makes the mode incompatible with zero data retention S16. - Google: background execution on Interactions. Set
backgroundto true, get an interaction id immediately, poll, stream, cancel, or reconnect to a stream from the last event id you processed. Google lists long reasoning, where thinking steps exceed HTTP connection limits, as a primary use S14. Gemini Enterprise adds a deferred tier that queues long agent workflows for off-peak capacity and targets completing 95% of them within 24 hours S17.
The design that fits a million-token trajectory is the third one, and specifically the resume-from-event-id part. A stream that cannot be resumed is a stream you re-run from zero when the network blinks at token 700,000. Google shipped the resumable stream with 3.5 Flash and the output cap with Argon, and the order makes sense: you need the first before the second is usable.

FIG. 04 · How each vendor handles a response that outlives the connection · only two of the three can resume a dropped stream server-side S10S14S15S16S17
What does a full response cost?
The second question the coverage mostly skipped. At $10 per million output tokens, a response that uses the whole cap costs $10 during the introductory period and $20 after it ends, on a date Google has not published S1. Two outlets did the multiplication S7S8; fewer put it next to the other models' caps, which is the comparison that matters for a router.

FIG. 05 · The most one response can cost, cap times list output price · Argon's ceiling is eight times Opus 5.5's and three times Astra's S1S3S4S5S18
| Model | Output cap | Output price per 1M | Cost of a full response |
|---|---|---|---|
| Gemini 3.8 Flash | 64K | $3.75 intro, $7.50 from Jan 1 S5 | $0.24, then $0.48 |
| Claude Sonnet 5.5 | 128K | $10 S3 | $1.28 |
| GPT-6.1 Sol | 128K | $10 S4 | $1.28 |
| Claude Opus 5.5 | 128K | $20 S18 | $2.56 |
| GPT-6 Astra | 128K | $50 S18 | $6.40 |
| Gemini 4 Argon | 1M | $10 intro, $20 standard S1 | $10, then $20 |
Three things about that table.
First, the per-token price is a distraction. Argon is half the price of Opus 5.5 per output token and can cost eight times as much per response, because the cap is eight times larger. "Half the price" was already a half-truth for Sonnet 5.5, where cheaper tokens turned into more tokens per task S19. Argon is the same lesson with the ceiling moved. A cost model that prices requests by tokens times rate needs a third term, the cap you set, because that is now the only thing between a $0.50 call and a $20 one.
Second, the variance is the cost. A $10 ceiling is fine. A P99 of $10 on an endpoint whose median is $0.40 is a budgeting problem, and the one-million cap turns every call where the model decides a problem is hard into a potential P99. One of the Japanese write-ups put it plainly: the practical gain is delegating a long migration in one call, and the price is that cost per call starts to fluctuate S20. Set max_output_tokens per task class, not per model.
Third, on this metric Argon still beats the model it is positioned against. One early estimate puts Argon at $1.99 per Artificial Analysis task at introductory pricing against $3.26 for GPT-6 Astra, rising to $3.98 at standard pricing S21. I could not open the underlying page and am treating that as secondhand. But the direction matches the list prices: Astra's $50 per million output buys a 128K cap that costs $6.40 to fill; Argon's $10 buys a cap that costs $10 to fill and that you can set lower.
What happens when it fails at token 700,000?
This is the engineering question, and it is the one the vendors' own machinery answers least well.
A chat-shaped integration treats a response as atomic: it succeeds or it fails, and you retry. A million-token response breaks that model twice. It breaks it on cost, because a failure at 70% of the way through has already billed 700,000 output tokens, and no vendor refunds a partial generation. And it breaks it on state, because the model's reasoning up to the failure is the valuable part, and on Anthropic and OpenAI that reasoning is bound to the conversation it was produced in, replayable only inside the same model's history S6S16.

FIG. 06 · The retry unit · one trajectory versus a checkpointed loop when the failure lands late S14S16
The two mitigations the vendors give you are resume and cancel. Google's background execution resumes a dropped stream from the last event id, and OpenAI's background mode resumes from a starting_after cursor; both let you cancel a run that has gone wrong rather than wait for it to finish spending S14S16. Anthropic's answer is streaming plus your own reconnect logic, or the Batches API, which trades the connection problem for a wait of up to 24 hours S15. None of the three resumes a trajectory after a server-side failure of the generation itself. The event log survives a dropped connection; it does not survive a dead run.
The mitigation you give yourself is a checkpoint, and Google's own examples show where to put it. The libgav1 rewrite ran many rounds of profile-guided experiments, each round being an edit, a compile, a benchmark and a read of the compiler's output S1. Each of those rounds is a tool call, and each tool call is a point where the state of the work exists outside the model: in the working tree, in the benchmark log, in the compiler output. If the trajectory dies at round 40, the state at round 39 is on disk. The trajectory was long; the unit of loss was one round. That is the design: let the model run a million tokens if it wants, but make sure every few thousand of them end in a side effect you can resume from, because the side effect is the checkpoint and the trajectory is not.
The same design answers the cancel question. A monitor that watches the stream can kill a run when the trajectory starts doing something it should not, and Google says it runs exactly that: misalignment mitigations that monitor Argon's chain of thought and actions and stop execution when necessary S1. You can only stop what you can see. If your integration waits for the whole response and reads it at the end, you have a million-token run with nobody watching it.
Who reviews a million tokens?
The last question is a human one, and Google answers it in the same paragraph it uses to announce the capability. The Rust migrations, which scale from tens of thousands of lines in re2 and libgav1 to more than 800,000 lines for the Fuchsia Zircon kernel, are undergoing rigorous automated and manual auditing, emulation testing and review before rolling out to production S1. The capability is the trajectory. The product is the audit.
That reframes what the output cap is for. A million tokens of reasoning is not something a reviewer reads. The 32,000 lines of SIMD code that Argon replaced were reviewed by running the decoder and checking the video output was identical and the speed was 2.7 times better S1. The check was a test, not a read. Every one of Google's internal examples has the same shape: a fleet-wide memory optimisation measured in tebibytes freed, a quantum subroutine measured against a published baseline, a kernel rewrite measured by emulation S1. The trajectory produced an artifact, and the artifact had a verifier.
This is the same argument as the last three posts in this series, from the other end. The Opus and Fable post said the escalation rung is useless without a verify function; the Sonnet post said the cheaper lane is only cheaper when the task has a check S18S19. The output cap makes the point unavoidable. A model that can run for hours and spend $20 on one response is only safe to run against a task whose result can be checked without reading the run. If you cannot name the test, you cannot name the task.
What are engineers saying after day one?
Argon is a day old and nobody outside the Fairwind cohort can call it, so the practitioner reports are reports about the announcement, not the model. I have weighted the ones that engage with the output cap rather than the benchmark table.
The Hacker News thread split the way Google's launches now split. One commenter read the phased release as Google not beating the allegation that it cannot ship a model; another quoted the price and said only "Wow" S9. On the cap itself, the thread's most upvoted technical point was deflationary: models generate one token at a time from everything before it, so a bigger output limit mostly means a run no longer errors at 64K, and the input limit has been a million on Gemini for a long time S9. That is correct and it is the right starting point. The interesting part is what you do once the run does not error.
The engineering outlets did the arithmetic the thread skipped. MarkTechPost's comparison table lists Argon at a million against 128K for Opus 5.5, Fable 5.1 and GPT-6 Astra, and prices a full response at $10 introductory and $20 standard S8. The DEV Community write-up gives a worked example, a million input tokens and 200,000 output tokens, at $4 on Argon against $8 on Opus 5.5 and $20 on Astra, which is the realistic shape Google describes rather than the ceiling S7. DataCamp was the first to flag that Google has not said whether reasoning tokens bill at the output rate, which, if the million is mostly thinking, is the single most important unpublished number S22.
The benchmark reads add one thing the cap cannot fix. Argon trails Opus 5.5 on Terminal-Bench 4.0, 57.4% against 66.4%, and MarkTechPost notes it also trails on FrontierSWE v2 and OSWorld S2S8. Those are the benchmarks closest to the kind of tool-heavy loop the output cap is built for. Where Argon leads is long context, 84.2% at 256K to 1M against 71.8% for Astra and 66.8% for Opus 5.5 S23, DeepSWE, the Vals Index, and the knowledge-work agents S1. Reading more and writing more are the same strength. Operating a terminal for a long time is a different one, and on day one the model with the biggest output cap is not the model that does that best.
Two caveats travel with everything in this section. All benchmark figures are vendor-reported and unverified by outside labs, as several outlets note S24. And Argon ships to the Fairwind cohort without cyber guardrails, which means the model the first testers are using is not the model developers will get S1.
How would I run a long trajectory?
No code in this post. Here is the operating checklist I would hand to a colleague before the first Argon call, and every line comes from a vendor document or from one of Google's own examples.
| Decision | What I would do | Why |
|---|---|---|
| Cap per task class | Set max_output_tokens per task class, not per model; keep the million for jobs with a verifier | The cap is the only thing between a $0.50 call and a $20 one S1 |
| Transport | Background execution with a stored interaction id, never a held connection | HTTP closes at about 60 seconds; the run can take hours S14 |
| Resume | Persist the last event id on every event; reconnect from it | A dropped stream resumes; a restarted one bills from zero S14 |
| Checkpoint | Make every few thousand tokens end in a side effect on disk: a commit, a test log, a benchmark | Google's rewrites recovered from rounds, not from trajectories S1 |
| Watch | Stream the thinking and actions to a monitor that can cancel | You can only stop what you can see S1S14 |
| Verify | Name the test before the run; reject tasks that have no test | The artifact has a verifier; the trajectory does not S1 |
| Budget | Alert on cost per call, not cost per token; track P99 per task class | Variance is the cost once the ceiling is $20 S20 |
| Thinking rate | Assume reasoning bills at the output rate until Google says otherwise | Unpublished; the industry default on every other reasoning model S4S22 |
| Older models | Keep 3.8 Flash at 64K for everyday work; its cap is a feature there | Google keeps 3.7 Flash alive for the same reason S5 |
One row in that table is the one I would argue about with myself. "Keep the million for jobs with a verifier" sounds like a restriction. It is the opposite. The verifier is what lets you stop supervising. A job with a test can run for four hours while you do something else; a job without one has to be read, and nobody reads a million tokens.
What does the side-by-side look like?
| Gemini 4 Argon | Claude Opus 5.5 | GPT-6.1 Sol | Gemini 3.8 Flash | |
|---|---|---|---|---|
| Announced | September 30, 2026 S1 | September 22, 2026 S18 | September 29, 2026 S4 | September 2, 2026 S5 |
| Available to developers | Not yet; Fairwind cohort first S1 | Yes | Yes | Yes |
| Max output per response | 1M S1 | 128K S18 | 128K S4 | 64K S5 |
| Output price per 1M | $10 intro, $20 standard S1 | $20 S18 | $10 S4 | $3.75 intro, $7.50 from Jan 1 S5 |
| Cost of a full response | $10, then $20 | $2.56 | $1.28 | $0.24, then $0.48 |
| Thinking counts against the cap | Not published S22 | Yes S6 | Yes S4 | Yes S5 |
| Long-request mechanism | Interactions background execution S14 | Streaming or Batches API S15 | Responses background mode S16 | Interactions background execution S14 |
| Resume a dropped stream | From last event id S14 | Client-side only S10 | From starting_after cursor S16 | From last event id S14 |
| Cancel a running response | Yes S14 | Close the stream | Yes S16 | Yes S14 |
| Terminal-Bench 4.0 | 57.4% S2 | 66.4% S18 | Not in Google's table | Not in Google's table |
| DeepSWE v1.1 | 77.9% S1 | 74.2% S2 | Not in Google's table | Not in Google's table |
| Long context, 256K to 1M | 84.2% S23 | 66.8% S23 | Not in Google's table | Not in Google's table |
When should you reach for the million?
A long trajectory is the right tool if:
- The task is a loop of experiments with a measurable result, the libgav1 shape: edit, compile, benchmark, read the output, repeat S1.
- The result can be verified without reading the run: a test suite, an emulator, a benchmark, an identical-output check S1.
- You run it as a background interaction with a persisted event id and a monitor that can cancel S14.
- The job's value clears $20 and a multi-hour wait with room to spare, so the P99 is a line item, not a surprise S1S20.
A 128K-class model is the right tool if:
- The work is tool-heavy terminal operation, where Opus 5.5 leads Argon by nine points on Terminal-Bench 4.0 today S2S18.
- You need the model now; Argon is not available to developers and Google gives no date S1.
- The task fits in 128K with a comfortable margin, which is most tasks; Sonnet 5.5 and GPT-6.1 Sol fill that cap for $1.28 S3S4.
Nobody should reach for the million if:
- The response will be read by a person. A million tokens is not a document; it is a log S1.
- The integration holds a connection open and reads the result at the end. The connection will not survive the run, and nobody will be watching it S14.
- There is no test. Google's own rewrites go through automated and manual auditing before production, and that audit is a verifier, not a reader S1.
- You price by tokens times rate with no cap per task class. The cap is now the budget S1.
What would I do differently next time?
Three things, in the order I would do them.
First, I would read the sentence around the number before the number. "One million output tokens" sent me to a spreadsheet; "think deeply and generate hundreds of thousands of tokens in a single trajectory" would have sent me to the background-execution docs, which is where this post ended up anyway S1S14.
Second, I would look up every vendor's long-request page before writing a word about caps. The output cap is useless without the machinery that lets a response outlive a connection, and the three vendors' machinery is different enough that the cap means different things on each. Anthropic's ten-minute rule, OpenAI's ten-minute storage window and Google's resume-from-event-id are three answers to the same question, and the question was the point S10S14S16.
Third, I would wait for the model page. The two numbers this post could not pin down, Argon's generation speed and whether its reasoning bills at the output rate, both live on a page Google has not published, and both change the arithmetic in FIG. 03 and FIG. 05. When the page lands I will update both figures and the table, and say so at the top.
FAQ
What is Gemini 4 Argon's output token limit?
One million tokens per response, up from 64K on earlier Gemini models. Google describes it as headroom to think deeply and generate hundreds of thousands of tokens in a single trajectory, so the realistic size of a long run is in the hundreds of thousands and the million is the ceiling.
Does the one-million cap include the model's thinking?
Google has not said. On every other reasoning model in the comparison, thinking tokens count against the output limit and bill at the output rate, so the safe assumption is that the million is a thinking-plus-text budget until Google publishes the model page.
How much does a full one-million-token response cost?
$10 at the introductory output price of $10 per million tokens, and $20 at the standard price of $20 per million, which applies after an introductory period whose end date Google has not published. A full 128K response on Opus 5.5 costs $2.56; on Sonnet 5.5 or GPT-6.1 Sol, $1.28.
How long would a million tokens take to generate?
Google has not published Argon's speed. At the throughputs this generation runs at, roughly 36 to 140 tokens per second measured on Anthropic and OpenAI models, a million tokens takes between two and eight hours; at OpenAI's claimed 300-token-per-second Ultrafast tier it would be under an hour.
Can I keep an HTTP connection open for that long?
No. Google's docs say standard HTTP requests typically close after about 60 seconds. Use the Interactions API's background execution: it returns an interaction id immediately, and you poll, stream, cancel or reconnect to the stream from the last event id you processed.
What is the equivalent on OpenAI and Anthropic?
OpenAI's Responses API has a background mode with polling, cancellation and a starting_after cursor for resuming a stream; it stores response data for about ten minutes. Anthropic's SDK refuses non-streaming requests expected to exceed ten minutes, roughly 21,000 output tokens, and recommends streaming or the Batches API for longer work; there is no server-side resume cursor.
What happens if a long response fails partway through?
You are billed for every token generated up to the failure, and no vendor resumes a generation after a server-side failure of the run itself. Resume cursors cover dropped connections, not dead runs. Design the trajectory so that every few thousand tokens end in a side effect on disk, a commit or a test log, and treat that as the checkpoint.
Is Argon better than Opus 5.5 for agentic coding?
Not on the benchmark closest to it. Google's own table has Argon at 57.4% on Terminal-Bench 4.0 against 66.4% for Opus 5.5, and it trails on FrontierSWE v2 and OSWorld too. It leads DeepSWE v1.1 at 77.9% against 74.2%, the Vals Index, and long-context tasks between 256K and 1M tokens.
When can developers use Gemini 4 Argon?
Google gives no date. It is rolling out first to vetted cyber defenders in the Fairwind Program, without cyber guardrails, and will reach paid API customers and Google AI Ultra subscribers after further safety work. Until then the newest Google model in production is Gemini 3.8 Flash, with a 64K output cap.
Should I raise my output cap to a million as soon as I can?
Only for tasks that have a verifier and a budget that clears $20 per call. Set max_output_tokens per task class, not per model, run long jobs as background interactions with a monitor that can cancel, and keep everyday work on a 64K or 128K cap, where the ceiling protects you.
Sources
- S1Koray Kavukcuoglu, "Gemini 4 Argon: our next era of frontier intelligence," Google, September 30, 2026, blog.google
- S2Fello AI, "Gemini 4 Argon Is Here: Benchmarks, Price, and Why You Cannot Use It Yet," October 1, 2026 (Terminal-Bench 4.0 and DeepSWE figures from Google's launch table), felloai.com
- S3Claude Platform Docs, "Claude Sonnet 5.5" model overview (1M context, 128K max output, $10 per million output), platform.claude.com
- S4OpenAI Developers, "GPT-6.1 Sol" model page (128,000 max output tokens, Responses API for tools), developers.openai.com
- S5Google AI for Developers, "What's new in Gemini 3.8 Flash" and "Gemini Developer API pricing" (64K output, $3.75 introductory, $7.50 from January 1, 2027), ai.google.dev
- S6Claude Platform Docs, "What's new in Claude Sonnet 5.5" (thinking blocks bound to model and conversation; thinking billed as output), platform.claude.com
- S7DEV Community, "Gemini 4 Argon: Price, Access and Benchmarks," September 30, 2026, dev.to
- S8MarkTechPost, "Google DeepMind Unveils Gemini 4 Argon with 1M Output Tokens for Coding, Knowledge Work and Cyber Defense," September 30, 2026, marktechpost.com
- S9Hacker News, discussion thread on the Gemini 4 Argon announcement, September 30 to October 1, 2026, news.ycombinator.com
- S10Anthropic, TypeScript SDK README, "Long Requests" and timeout formula (sixty minutes scaled by max_tokens over 128,000; ten-minute non-streaming limit), npmjs.com
- S11OpenRouter, "OpenAI: GPT-6.1 Sol" model page (measured throughput and latency), accessed October 1, 2026, openrouter.ai
- S12Simon Willison, "Claude Sonnet 5.5," September 28, 2026 (xhigh run: 41 seconds, 5.74 cents), simonwillison.net
- S13OpenAI, "Introducing GPT-6.1 Sol," September 29, 2026 (Ultrafast tier, up to 300 tokens per second), openai.com
- S14Google AI for Developers, "Background execution," Gemini API (Interactions API: background, poll, cancel, resume from last event id; HTTP requests typically close after 60 seconds), ai.google.dev
- S15Claude Platform Docs, "Errors," section "Long requests" (streaming or Message Batches API for requests over ten minutes), platform.claude.com
- S16OpenAI Developers, "Background mode" (Responses API: background, polling, cancel, streaming with starting_after; ten-minute storage, not ZDR compatible), developers.openai.com
- S17Google Cloud, Gemini Enterprise Agent Platform, "Autonomous agent scheduling" (deferred tier, 95% of tasks within 24 hours), docs.cloud.google.com
- S18Syed Moinuddin, "Not a Winner, a Routing Rule: What I Learned Researching Claude Opus 5.5 vs Fable 5.1," September 27, 2026 (Opus 5.5 and Astra prices, 128K caps, Terminal-Bench 66.4%), syedmoinuddin.com
- S19Syed Moinuddin, "Not a Ladder, a Fork: What I Learned Researching Claude Sonnet 5.5 vs Opus 5.5," September 29, 2026, syedmoinuddin.com
- S20DenDen, "Gemini 4 Argon Announced: 1 Million Token Output, Pricing, and Availability," note.com, October 1, 2026, note.com
- S21Fello AI, Artificial Analysis cost-per-task comparison quoted in the Argon write-up ($1.99 introductory, $3.98 standard, $3.26 for GPT-6 Astra), secondhand and unverified, felloai.com
- S22DataCamp, "Gemini 4 Argon: Features, Benchmarks, Pricing, and Access," September 30, 2026, datacamp.com
- S23OfficeChai, "Google Introduces Gemini 4 Argon, Beats GPT 6 Astra And Opus 5.5 On Many Benchmarks" (long-context row from Google's table), September 30, 2026, officechai.com
- S24Forkast, "Google's Gemini 4 Argon Closes the Pricing Triangle. The Benchmark Lead Is the Real Story," September 30, 2026, forkast.news
Written by
Syed Moinuddin
Full Stack Engineer.
Notes on AI tooling, agentic systems, and building things that survive contact with production.





