DEV Community: Hassann

Gemini 4 Argon Benchmarks: All 19 Rows, How Google Ran Them, and the 5 It Loses

Hassann — Fri, 02 Oct 2026 13:28:44 +0000

Gemini 4 Argon leads 13 of the 19 rows in Google’s launch table outright, ties one row (CWE-bench v1, with GPT-6 Astra), and trails on five: FrontierSWE v2, Terminal-bench 4.0, PostTrainBench, Terminal-Bench Science 0.1, and OSWorld-2.0. The access limitation matters: Argon is currently available only to Fairwind Program defenders, so developers outside Google’s partner list and a few benchmark organizations cannot rerun these numbers yet.

Try Apidog today

Below is the full table, including who measured each row, where Argon loses, methodology caveats, cyber scores, third-party scoreboards, and a practical way to prepare your own evaluation in Apidog before access opens. For the model overview, start with what Gemini 4 Argon is. For a buying comparison, see Argon vs GPT-6 Astra vs Claude Opus 5.5.

The full table, with who measured each row

These are Google-reported results from the launch post and the evals methodology PDF, which is headed “results as of October, 2026.”

Google computed 10 of the 19 Argon scores itself. The other nine come from public leaderboards. Rival scores come from leaderboards, Google runs, vendor system cards, or vendor blog posts, depending on the row. Harnesses are not uniform across every benchmark.

Bold indicates the row leader.

Benchmark	Gemini 4 Argon	GPT-6 Astra	Claude Fable 5.1	Claude Opus 5.5	Who measured it
Vals Index	68.9%	63.1%	65.8%	67.0%	Vals AI
AutomationBench	51.3%	41.4%	31.4%	42.5%	Zapier leaderboard (private set)
Vals Finance Agent v2	65.4%	53.5%	58.9%	58.6%	Vals AI
Harvey Legal Agent	19.6%	5.4%	6.7%	3.8%	Vals AI
DeepSWE v1.1	77.9%	74.1%	67.4%	74.2%	Argon self-computed; Astra leaderboard; Anthropic system cards
FrontierSWE v2	55.0%	65.5%	56.3%	62.3%	Proximal leaderboard
Vibe Code Bench	91.9%	89.6%	90.3%	90.3%	Vals AI
Terminal-bench 4.0	57.4%	58.2%	57.9%	66.4%	Argon self-computed; rivals leaderboard
PostTrainBench	45.3%	44.3%	40.2%	49.3%	Self-computed for all models
Terminal-Bench Science 0.1	57.6%	68.1%	52.6%	63.3%	Argon self-computed; rivals leaderboard
LABBench 2	88.8%	85.4%	68.6%	73.1%	Self-computed for all models
RiemannBench	76.0%	72.0%	65.6%	69.6%	Surge leaderboard
GraphWalks up to 128K	99.7%	98.7%	91.4%	90.6%	Self-computed for all models
GraphWalks 256K to 1M	84.2%	71.8%	65.0%	66.8%	Self-computed for all models
Agent’s Last Exam	39.5%	34.2%	n/r	38.2%	Argon self-computed; rivals leaderboard
OSWorld-2.0 (offline)	69.2%	72.6%	n/r	n/r	Argon self-computed; Astra from OpenAI’s blog post
Chartography	71.6%	71.0%	46.2%	66.3%	Surge leaderboard
LVBench	91.7%	87.5%	79.7%	83.7%	Self-computed for all models
CWE-bench v1	68.0%	68.0%	58.0%	67.0%	Public leaderboard

n/r means not reported.

Grok 4.7 is not in Google’s table, but it also scores 68% on the CWE-bench leaderboard. That makes CWE-bench a three-way tie.

Read the source distribution before using the headline count

The source mix is important when you use these results to select a model:

Nine rows come from public leaderboards for every model: Vals AI, Zapier, Proximal, Surge, and CWE-bench.
- Argon leads seven.
- Argon ties one.
Five rows were run by Google for all four models.
- Argon leads four.
Five rows combine a Google-run Argon score with rival scores from another source.
- Three of Argon’s five losses occur in these mixed-source rows.

This does not eliminate methodology concerns, but it is relevant context: if Google self-computing systematically favored Argon, the losses would be expected to cluster in Google-run rows rather than mixed rows.

Where Argon trails, and why it matters for agentic coding

Argon’s five losses are concentrated in benchmarks that matter for terminal-based and repository-scale agents:

FrontierSWE v2: 55.0% versus Astra’s 65.5%. Argon is last among the four models, behind Fable 5.1 at 56.3% and Opus 5.5 at 62.3%. This is a public leaderboard result.
Terminal-bench 4.0: 57.4% versus Opus 5.5’s 66.4%. Argon is last again, although Astra and Fable 5.1 are within one point.
PostTrainBench: 45.3% versus Opus 5.5’s 49.3%. Argon finishes second in a row Google ran for all models.
Terminal-Bench Science 0.1: 57.6% versus Astra’s 68.1%. Argon is third, ahead of Fable 5.1 only. Google ran Argon’s attempt with a 6x verifier timeout.
OSWorld-2.0 (offline subset): 69.2% versus Astra’s 72.6%. Anthropic reports only a combined online and offline score, so neither Claude model appears.

For agentic coding specifically, the results split two to two:

Benchmark type	Result
DeepSWE v1.1	Argon wins
Vibe Code Bench	Argon wins
FrontierSWE v2	Argon finishes last
Terminal-bench 4.0	Argon finishes last

The DeepSWE result mixes harnesses: Argon used a mini-swe agent harness, Astra’s score comes from the public leaderboard, and Claude scores come from system cards. Vibe Code Bench is cleaner because Vals AI scored all four models, but Argon’s winning margin is only 1.6 points.

If your application depends on terminal automation, long-running repository tasks, or shell-based debugging, prioritize FrontierSWE v2 and Terminal-bench 4.0 over the aggregate win count. Astra holds the FrontierSWE lead; see the GPT-6 Astra hands-on for current usage observations. For Anthropic’s results, see the Claude Fable 5.1 benchmarks breakdown.

Bloomberg reports that anonymous Google employees with access say Argon underwhelms on some coding and front-end design work relative to its benchmark scores. Google called that characterization inaccurate.

Methodology caveats that change how you read the table

Before treating a row as a production forecast, check the evaluation configuration.

Maximum effort settings: Argon ran “with the Gemini API with the highest thinking settings.” Google used the “maximum thinking/reasoning settings available” for Astra, Fable 5.1, and Opus 5.5. These results compare ceilings, not default latency, default quality, or cost.
LVBench input differences: Google ran LVBench for all four models without tools. Gemini sampled video at 1 FPS. Astra received 800 frames, Fable 5.1 received 300, and Opus 5.5 received 600 due to API limitations. The models did not receive identical inputs.
OSWorld best-of-three scoring: Argon’s score was “maxed over 3 runs with a single attempt per run.” This is the best run, not an average across runs.
Agent’s Last Exam execution window: Argon ran on the ALE-Claw harness with a five-hour window.
Safety filters remained enabled: Agent’s Last Exam and OSWorld used safety filters. Flagged responses returned as empty strings. This could reduce Argon’s result rather than inflate it.

The cyber rows from DeepMind’s cyber page

The DeepMind cyber page adds four scores beyond the launch table:

Cyber eval	Gemini 4 Argon	Comparison
Real-world vulnerability discovery	85.8%	Gemini 3.8 Flash Cyber: 71.0%
Wiz Penetration Test Benchmark	70.9%	Gemini 3.8 Flash Cyber: 58.2%
Gray Swan IPI attack success (`k=15`, lower is better)	0.7%	Lowest on the chart; Kimi K3 highest at 52.7%
CWE-bench v1	68%	Three-way tie with Grok 4.7 and GPT-6 Astra; Opus 5.5 at 67%

The vulnerability evaluation used an internal Antigravity harness that Google describes as “not cyber specialized,” with source access.

The Wiz test gives the model access only to the running website and its public behavior, without application source code.

Both headline comparisons are against Google’s prior cyber model rather than direct competitors. The Argon cyber defense explainer covers what these scores mean for APIs you operate.

Third-party scoreboards

Several organizations published scores within minutes of launch, which indicates pre-release access.

Artificial Analysis: Lists Gemini 4 Argon (High) at an Intelligence Index of 53, ranked #8 of 223. The ranking counts each reasoning setting separately. By distinct model, Argon ties Fable 5.1 and GPT-6 Astra, while trailing Opus 5.5 at 58 maximum and Sonnet 5.5 at 56 maximum. Artificial Analysis reports a 15% hallucination rate on AA-Omniscience, compared with Astra at maximum effort at 51%, with accuracy of 50% versus 63%. Running the index cost $1.99 per task, with approximately 62K output tokens per task versus approximately 27K for Astra at maximum settings. Artificial Analysis shows no speed or latency data.
Vals AI: Places Argon at 68.90% on the Vals Index, #1 of 41 and the first Gemini model to top the index, at $15.68 per test. Vals AI lists a 262K maximum output for the tested configuration, below Google’s stated 1M.
Arena: Ranks Argon #1 on Text at 1525, marked Preliminary with 4,942 votes, and #8 on WebDev.

Why outlets publish 12, 13, and 14 wins

Different headlines use different comparison rules. Here is the recount from Google’s 19 rows:

Counted against	Argon wins	Ties	Argon loses	Not reported
Best of all three rivals	13	1	5	0
GPT-6 Astra only	14	1	4	0
Claude Opus 5.5 only	14	0	4	1
Claude Fable 5.1 only	15	0	2	2

Use the count that matches your decision:

13 wins is correct when Argon must beat the entire field.
14 wins is correct in a head-to-head comparison with Astra or Opus 5.5.
12 wins does not match these full-table framings, so inspect which rows the source excluded or counted differently.

Also check the margins. Harvey Legal Agent is a wide gap at 19.6% versus 6.7%, while Chartography is separated by only 0.6 points.

How to run your own eval the day access opens

Public benchmarks measure someone else’s harness. Your evaluation should measure your prompts, tools, schemas, latency requirements, and cost limits.

Build the scenario now using a model you can call. When Argon becomes available, change one environment variable and rerun the same tests.

1. Select production-like test cases

Create prompts that map to the work you actually need:

A repository bug fix with expected tests or a patch.
A terminal task requiring command sequencing.
A long-document question with a verifiable answer.
A structured API response that must match a JSON schema.
A tool-calling workflow with error handling.

Use real sanitized incidents when possible. Include both successful and failure cases.

2. Create environment variables in Apidog

In Apidog, create an environment with:

GEMINI_API_KEY=<your-key>
GEMINI_MODEL=gemini-3.8-flash

Google has not published Argon’s model ID, so GEMINI_MODEL should be the only value you need to change later.

3. Parameterize each request

Save each prompt as a request and reference the model variable rather than hardcoding the model ID.

{
  "model": "{{GEMINI_MODEL}}",
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "text": "Fix the failing test. Return the patch and a short explanation."
        }
      ]
    }
  ]
}

Group related requests into a scenario, such as:

agentic-coding/
  repository-fix
  terminal-debugging
  code-review
  long-context-question

4. Add assertions for quality and cost controls

Do not evaluate only HTTP status. Assert the properties your integration requires:

Response status is successful.
Required JSON fields exist.
The output includes expected terms, files, commands, or citations.
The response is valid JSON when your application expects JSON.
Token usage remains below your cost ceiling.
Tool calls, if used, match expected names and arguments.

For example, track usageMetadata and cap thought-token usage:

pm.test("returns a successful response", () => {
  pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.expect(body.usageMetadata).to.have.property("thoughtsTokenCount");
pm.expect(body.usageMetadata.thoughtsTokenCount).to.be.below(50000);

pm.expect(body).to.have.property("candidates");

Size the thoughtsTokenCount ceiling to your own budget and latency target rather than treating maximum reasoning as the default.

5. Capture a baseline before Argon is public

Run the scenario with Gemini 3.8 Flash and save the report.

Record at least:

Metric	Why it matters
Pass rate	Measures task success against your assertions
Output validity	Detects schema and parsing failures
Token usage	Tracks model cost behavior
Latency	Shows whether a higher-quality result is usable in your workflow
Failure examples	Helps diagnose regressions after a model swap

When Argon’s model ID is released, update:

GEMINI_MODEL=<Argon model ID>

Then rerun the exact same scenario and compare reports.

Google says that “all new models” will launch on the Interactions API, so save an Interactions API version of each request as well. For expected price and limit differences, see Argon vs Gemini 3.8 Flash.

FAQ

Are Gemini 4 Argon’s benchmarks independently verified?

Partly. Nine of the 19 rows come from public leaderboards for every model, and Artificial Analysis, Vals AI, and Arena posted their own results. The remaining rows are Google-run for Argon.

What is Gemini 4 Argon’s DeepSWE score?

Argon scores 77.9% on DeepSWE v1.1, ahead of Opus 5.5 at 74.2% and Astra at 74.1%. Argon used a mini-swe agent harness, while rival scores come from a leaderboard and system cards.

Does Argon beat GPT-6 Astra on benchmarks?

Head to head in Google’s table, Argon wins 14 rows, ties one, and loses four. On Artificial Analysis, they tie at 53.

Can I rerun these benchmarks myself?

Not yet. Argon is limited to Fairwind partners, and Google has not provided a public release date. The Argon release date tracker follows the rollout.

Next step

Build the scenario now, run it on Gemini 3.8 Flash, and keep the report. When Argon becomes available, swap the model variable and you will have comparable numbers from your own workload within minutes.

Download Apidog to set up the evaluation.

Gemini 4 Argon vs Gemini 3.8 Flash: Should You Wait for Argon or Ship on Flash Now?

Hassann — Fri, 02 Oct 2026 13:26:54 +0000

Gemini 3.8 Flash is available today: a stable model with a free tier, priced at $0.75 input and $3.75 output per 1M tokens through 2026-12-31, then $1.50 and $7.50, with a 64K output cap. Gemini 4 Argon is not generally available. Google’s launch post lists Argon at $2 input and $10 output during an intro period of unstated length, then $4 and $20. Google states a 1M-token output limit, but availability is currently limited to Fairwind Program defenders. If you need to ship this quarter, build on Flash and keep Argon behind a configuration switch.

Try Apidog today

This guide compares the models’ published specs, shared benchmark rows, cyber scores, and the cost of an identical call. It also shows how to make the eventual model switch a single environment-variable change. For background, see what Gemini 4 Argon is and what Gemini 3.8 Flash is.

Side by side: what you can call today

	Gemini 3.8 Flash	Gemini 4 Argon
Availability	Stable on the Gemini API, AI Studio, Antigravity, and Gemini Enterprise	A subset of Fairwind Program partners, as a managed model on Gemini Enterprise
Model ID	`gemini-3.8-flash`	Not published
Price per 1M tokens (input / output)	$0.75 / $3.75 through 2026-12-31, then $1.50 / $7.50	$2 / $10 intro pricing, then $4 / $20
Cached input per 1M	$0.075, then $0.15	$0.10 intro, then $0.20
Output limit	65,536 tokens	1M tokens, according to Google
Input window	1,048,576 tokens	Not published
Thinking levels	`low`, `medium` (default), `high`; `minimal` returns HTTP 400	Not documented
Free API tier	Yes, rate-limited	None announced
Consumer access	Gemini app on AI Pro and Ultra; AI Mode in Search	Not yet; AI Ultra subscribers are in the first wave, with no date announced

A few details need qualification:

Google has not published Argon’s input window, although its long-context evaluation used prompts up to 1M tokens.
Google states a 1M-token Argon output limit. Third-party evaluator Vals AI lists a 262K maximum output for the configuration it tested.
Argon evaluations used “the highest thinking settings,” which suggests a high setting exists, but Google has not documented the level names or default.
Flash thinking levels are documented in Google’s thinking documentation and in this Gemini 3.8 Flash thinking-levels guide.

Flash’s free tier is rate-limited, and Google says free-tier data is “used to improve our products.” Google has not announced a free way to use Argon. See the Argon free-access explainer for currently available alternatives.

Shared benchmark rows

Google’s launch tables share two benchmark rows. These are Google-reported results, and Argon’s methodology attributes both rows to Vals AI.

Benchmark	Gemini 3.8 Flash	Gemini 4 Argon
Vals Finance Agent v2	61.4%	65.4%
Harvey Legal Agent Benchmark	10.0%	19.6%

Treat these results as directional, not as a controlled head-to-head test: Google published the tables a month apart and compared them against different model sets.

Still, the published gap is notable:

Finance: Argon leads by 4.0 percentage points.
Legal: Argon scores 19.6% versus Flash’s 10.0%, nearly doubling the result.

Other rows do not have a direct Flash counterpart in the launch-post text. For example, Flash reported HLE-Verified while Argon did not, and Flash’s DeepSWE score appeared only in model-card images. On Arena’s Text leaderboard, a third-party ranking, Argon (High) is #1 on preliminary votes while Gemini 3.8 Flash (High) is #11.

For the full table and measurement sources, see this Argon benchmarks breakdown.

Cyber: Argon vs. 3.8 Flash Cyber

The DeepMind cyber page compares Argon with Gemini 3.8 Flash Cyber, a Fairwind-gated cyber-focused Flash variant.

Cyber evaluation	Gemini 4 Argon	Gemini 3.8 Flash Cyber
Real-world vulnerability discovery	85.8%	71.0%
Wiz Penetration Test Benchmark	70.9%	58.2%

Both models are gated:

Gemini 3.8 Flash Cyber is generally available behind an allowlist on Gemini Enterprise Agent Platform.
Gemini 4 Argon is Fairwind-only.

If you are not a Fairwind partner, these scores do not change the model you can use today. The generally available Gemini 3.8 Flash model is the practical implementation choice.

Cost of the same call on both

Use the same workload to compare pricing:

Input: 100,000 tokens
Output: 8,000 tokens
Assumption: For current Gemini models, including Flash, thinking tokens are billed as output tokens. Google has not documented Argon’s thinking-token billing, so the Argon calculation assumes it follows current Gemini billing.

Model and period	Input cost	Output cost	Total per call
Gemini 3.8 Flash, intro	`0.1M × $0.75 = $0.075`	`0.008M × $3.75 = $0.030`	$0.105
Gemini 3.8 Flash, from 2027-01-01	`0.1M × $1.50 = $0.150`	`0.008M × $7.50 = $0.060`	$0.210
Gemini 4 Argon, intro	`0.1M × $2 = $0.200`	`0.008M × $10 = $0.080`	$0.280
Gemini 4 Argon, standard	`0.1M × $4 = $0.400`	`0.008M × $20 = $0.160`	$0.560

Argon’s per-token rates are 8 / 3, or about 2.67× Flash pricing, during both intro and standard pricing periods.

At 1,000 calls per day using this workload:

Gemini 3.8 Flash intro pricing: 1,000 × $0.105 = $105/day
Gemini 4 Argon intro pricing: 1,000 × $0.280 = $280/day

Three implementation details can change the real ratio:

Token counts will differ.

The same prompt can produce different answer lengths and thinking-token counts. Argon’s published evaluations used its highest thinking settings, while Google warns that higher Flash effort levels can consume more tokens.
Long outputs may require request splitting.

A 200,000-token answer exceeds Flash’s 65,536-token limit, so Flash would require multiple calls. Under Argon’s stated limit, it fits in one response.

   Argon, 200K output tokens:
   0.2M × $10 = $2.00 at intro pricing
   0.2M × $20 = $4.00 at standard pricing

   Argon, 1M output tokens:
   1M × $10 = $10.00 at intro pricing
   1M × $20 = $20.00 at standard pricing

Only Flash has a published intro-pricing end date. Flash intro pricing ends on 2026-12-31. Google has not stated when Argon intro pricing ends.

Flash also supports Batch at a 50% discount: $0.375 input and $1.875 output per 1M tokens through December 31, according to the Gemini API pricing page. Google has not published Batch pricing for Argon.

For more detail, see the Argon pricing guide and Gemini 3.8 Flash pricing guide.

Decision rule: ship on Flash or plan for Argon?

Ship on Gemini 3.8 Flash now when

You are cost-bound. Flash costs 3/8 of Argon per token, and Batch can halve Flash costs again.
You run high-volume workloads. Classification, extraction, routing, and chat costs compound quickly at $10 per 1M output tokens.
You need a model today. Flash has a stable model ID, free-tier prototyping access, and a published price schedule.
Your responses fit within 65,536 tokens. Most API workloads do.

Plan for Gemini 4 Argon when

Your workflows are long-horizon. Google describes Argon as built for deep reasoning across complex, long-running workflows.
You need outputs beyond 64K tokens. Large migrations, full-module rewrites, and long reports are the clearest use cases for the stated 1M-token output limit.
You build legal or finance agents. These are the two benchmark rows Google published for both models, and Argon leads on both.
You are a Fairwind-eligible defender. Argon is the model currently led by that program.

The practical approach is not to choose permanently. Route normal production traffic to Flash, then test and route only the hard tail to Argon when it becomes available.

One saved request, two models

Keep the model ID in an environment variable. Run production-like requests against Flash now, then update the variable when Google publishes Argon’s model ID.

Do not guess an Argon model ID.

MODEL="${GEMINI_MODEL:-gemini-3.8-flash}"

curl -s -X POST \
  "https://generativelanguage.googleapis.com/v1beta/models/${MODEL}:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [
      {
        "parts": [
          {
            "text": "Summarize this contract clause in 3 bullets."
          }
        ]
      }
    ],
    "generationConfig": {
      "thinkingConfig": {
        "thinkingLevel": "medium"
      },
      "maxOutputTokens": 8192
    }
  }'

Set the environment values:

export GEMINI_API_KEY="your-api-key"
export GEMINI_MODEL="gemini-3.8-flash"

When Argon receives a published model ID, the intended switch is:

export GEMINI_MODEL="published-argon-model-id"

Add cost and response checks

Every generateContent response includes usageMetadata. Use it to enforce a cost ceiling and compare model behavior.

In Apidog:

Create an environment with GEMINI_API_KEY and GEMINI_MODEL.
Save the request above.
Add assertions for:
- HTTP status 200
- The response fields your application consumes
- A maximum usageMetadata.thoughtsTokenCount based on your token budget
Keep maxOutputTokens set so an unexpectedly long response cannot exceed your output budget.
Add the request to a test scenario and run it against Flash.
Save the report as a baseline for the Argon comparison.

For example, set an explicit output cap per request:

{
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "medium"
    },
    "maxOutputTokens": 8192
  }
}

Prepare for the Interactions API

There are two launch-day caveats:

Google says “all new models” will launch on the Interactions API, but has not confirmed whether Argon supports generateContent.
Argon’s thinking-level names are not documented, so Flash’s medium setting may not transfer directly.

Keep an Interactions API version of your request beside the generateContent version:

POST https://generativelanguage.googleapis.com/v1beta/interactions

Use generation_config.thinking_level for the Interactions API request.

When Argon is available:

Update only GEMINI_MODEL.
Run the same prompt suite.
Compare output quality, latency, and usageMetadata.
Calculate cost from actual input, output, and thinking-token usage.
Route only workloads where Argon’s result justifies its higher cost.

FAQ

Is Gemini 4 Argon better than Gemini 3.8 Flash?

On the two benchmark rows shared by both launch tables, yes:

Vals Finance Agent v2: 65.4% vs. 61.4%
Harvey Legal Agent Benchmark: 19.6% vs. 10.0%

However, Argon costs about 2.67× more per token and is not generally callable yet.

Should I wait for Gemini 4 Argon?

Not if you need to ship. Google has not provided a release date, only “as soon as possible,” starting with paid API customers and AI Ultra subscribers.

Gemini 3.8 Flash or Argon for a new project?

Start with Gemini 3.8 Flash and place the model ID in an environment variable. Move requests requiring long outputs or stronger legal and finance performance to Argon only after testing it against your own prompts.

Is there a free way to use Argon?

No. Google has not announced a free tier. See the Argon free-access explainer for free Gemini models available today.

Does Argon replace Gemini 3.8 Flash?

Google has not said so. Google calls Argon its new frontier model, while Reuters reports it is larger than the previous Pro line. It appears to be a different tier from Flash.

Next step

Set up one saved request today, run it on Gemini 3.8 Flash, and store the output and usage report. When Argon ships, you can evaluate its quality and cost against your real traffic within minutes.

Download Apidog to build and save the comparison.

Gemini 4 Argon vs GPT-6 Astra vs Claude Opus 5.5

Hassann — Fri, 02 Oct 2026 13:24:39 +0000

Gemini 4 Argon leads Google’s benchmark table on 13 of 19 rows against GPT-6 Astra, Claude Opus 5.5, and Claude Fable 5.1. But availability matters more than any benchmark: you can buy Astra and Opus 5.5 today, while Argon is available only to Fairwind Program defenders. Its introductory price is $2/$10 per million input/output tokens, increasing to $4/$20 afterward—the same list price as Opus 5.5.

Try Apidog today

This comparison breaks down pricing and limits, groups Google’s benchmark results by winner, highlights evaluation caveats, and provides a practical routing guide. It also shows how to compare the available models with your own prompts in Apidog. If you are new to Argon, start with what is Gemini 4 Argon. For availability details, see the Argon release date guide.

Price and limits side by side

Google’s comparison includes Claude Fable 5.1, so it belongs in the table. Prices below are per 1M tokens and come from Google’s launch post, OpenAI’s GPT-6 Astra model page, and Anthropic’s pricing page.

	Gemini 4 Argon	GPT-6 Astra	Claude Opus 5.5	Claude Fable 5.1
Can you call it today?	No, Fairwind only	Yes	Yes	Yes
API model ID	Not published	`gpt-6-astra`	`claude-opus-5-5`	`claude-fable-5-1`
Input	$2 intro, then $4	$10	$4	$10
Cached input	$0.10 intro, then $0.20	$1	$0.20	$0.25
Output	$10 intro, then $20	$50	$20	$50
Max output	1M (Google’s stated limit)	128K	128K (300K on Batch, beta)	128K
Context window	Not published	1,050,000 (922K max input)	1M	1M
Long-prompt surcharge	Not stated	Over 272K input: 2x input and cache, 1.5x output, on the full request	None	None

Three implementation implications stand out:

Argon and Opus 5.5 have the same standard rates. Argon’s cost advantage over Opus lasts only during Google’s introductory period, which has no published end date.
Astra and Fable 5.1 cost more per token. Their listed input and output rates are 2.5x Argon’s standard rates and 5x Argon’s introductory rates.
Treat Argon’s 1M output limit carefully. Google states a 1M-token output limit, but Vals AI lists a 262K maximum output for the Argon configuration it tested.

For per-request calculations, see Gemini 4 Argon pricing.

Where each model leads in Google’s table

Google published this table, so interpret it accordingly. Argon’s scores are Google-reported, using a mix of self-computed results and leaderboard results. Competitor scores are mostly vendor-reported figures or public leaderboard results, often at maximum reasoning settings. Different harnesses mean small score gaps may not be meaningful.

Who leads	Benchmark	Argon	Astra	Fable 5.1	Opus 5.5
Argon: knowledge work	Vals Index	68.9%	63.1%	65.8%	67.0%
Argon: knowledge work	AutomationBench	51.3%	41.4%	31.4%	42.5%
Argon: knowledge work	Harvey’s Legal Agent Benchmark	19.6%	5.4%	6.7%	3.8%
Argon: coding	DeepSWE v1.1	77.9%	74.1%	67.4%	74.2%
Argon: long context	GraphWalks 256K to 1M (F1)	84.2%	71.8%	65.0%	66.8%
Argon: multimodal	LVBench	91.7%	87.5%	79.7%	83.7%
Argon: multimodal	Chartography	71.6%	71.0%	46.2%	66.3%
Astra	FrontierSWE v2	55.0%	65.5%	56.3%	62.3%
Astra	Terminal-Bench Science 0.1	57.6%	68.1%	52.6%	63.3%
Astra	OSWorld-2.0 (offline, partial)	69.2%	72.6%	not reported	not reported
Opus 5.5	Terminal-bench 4.0	57.4%	58.2%	57.9%	66.4%
Opus 5.5	PostTrainBench	45.3%	44.3%	40.2%	49.3%
Tie	CWE-bench v1	68.0%	68.0%	58.0%	67.0%

Argon’s other outright wins are Vals Finance Agent v2, Vibe Code Bench, LABBench 2, RiemannBench, GraphWalks up to 128K, and Agent’s Last Exam.

Fable 5.1 does not lead a row in Google’s table. On CWE-bench v1, DeepMind’s cyber leaderboard shows a three-way 68% tie between Argon, Astra, and Grok 4.7, with Opus 5.5 at 67%.

For Argon versus Fable 5.1, Argon scores higher on 15 of the 17 rows where both report a result. Fable exceeds Argon only on:

FrontierSWE v2: 56.3% vs. 55.0%
Terminal-bench 4.0: 57.9% vs. 57.4%

See Claude Fable 5.1 benchmarks for Anthropic’s reported numbers and Gemini 4 Argon benchmarks for the full 19-row table.

Three caveats before you trust the gaps

1. Competitor scores are not Google reruns

Google’s methodology says non-Gemini results are “sourced from providers’ self reported numbers unless otherwise mentioned.” Several rows also come from public leaderboards operated by Vals AI, Proximal, and Surge.

Use these numbers for model selection hypotheses, not as final production evidence.

2. Benchmark harnesses differ

On DeepSWE v1.1, Google calculated Argon’s 77.9% using a mini-swe-agent harness. Astra’s number comes from a public leaderboard, while Anthropic’s scores come from system cards.

On LVBench, Gemini sampled video at one frame per second. Astra received 800 frames, Opus 5.5 received 600, and Fable 5.1 received 300, reportedly because of API limits.

Do not treat these as strictly equivalent runs.

3. A model can score differently across charts

Opus 5.5’s Terminal-bench 4.0 score changes between charts based on the harness and effort setting. Anthropic reports its 66.4% result at xhigh effort.

When creating an internal evaluation spreadsheet, keep the following fields alongside each score:

model
model_version
reasoning_or_effort_setting
benchmark_version
agent_harness
tool_configuration
date_tested
source

Never combine benchmark results from different harnesses into a single ranking without labeling the differences.

What third-party evaluators say

Independent leaderboards narrow the gap.

Artificial Analysis lists Argon at #8 out of 223 entries, although that ranking counts each reasoning setting separately. Grouped by distinct model, Argon scores 53, tying GPT-6 Astra and Claude Fable 5.1. It trails Claude Opus 5.5 at 58 at maximum settings and Claude Sonnet 5.5 at 56.

Artificial Analysis also lists Argon’s hallucination rate on AA-Omniscience at 15%, compared with 51% for Astra at its maximum setting.

On Arena, Argon ranks first in Text at 1525, marked Preliminary with 4,942 votes. Opus 5.5 ranks fourth.

Vals AI ranks Argon first among 41 models on the Vals Index, making it the first Gemini model to top that ranking.

There are also reports of internal skepticism. Bloomberg reported that some Google employees with access found Argon less impressive on certain coding and front-end design tasks than its benchmark results suggest. Google called that characterization inaccurate.

Which model should you route to?

There is no universal best frontier model. Route requests by workload, quality requirements, latency, output limits, and cost.

Task	Route today	When Argon ships
Legal, finance, and office automation agents	Opus 5.5 (67.0% Vals Index)	Test Argon: it leads all four knowledge-work rows
Terminal-heavy coding agents	Opus 5.5 (66.4% Terminal-bench 4.0)	Opus 5.5 still leads
Agentic software engineering	Astra (65.5% FrontierSWE v2) or Opus 5.5	Argon leads DeepSWE but trails FrontierSWE; test both
Computer use and GUI agents	Astra (72.6% OSWorld-2.0)	Astra leads OSWorld; Argon leads Agent’s Last Exam
Reasoning over 256K-token prompts	Opus 5.5 (no surcharge) or Astra (surcharge over 272K)	Argon (84.2% GraphWalks 256K to 1M)
Video and chart understanding	Astra (87.5% LVBench)	Argon (91.7%), with the frame-count caveat
Science and ML engineering	Astra (Terminal-Bench Science), Opus 5.5 (PostTrainBench)	Argon leads LABBench 2 and RiemannBench; test it
Single responses over 128K tokens	Opus 5.5 on Batch (300K, beta)	Argon, up to Google’s stated 1M
High-volume, cost-sensitive work	Opus 5.5 ($4/$20)	Argon at $2/$10 while the intro lasts

If price matters more than peak benchmark results, compare OpenAI’s lower-cost line with Opus using GPT-6 Sol vs Claude Opus 5.5.

Compare the models on your own prompts

Vendor benchmarks cannot tell you how models handle your repository, documents, tools, response formats, or failure modes. Build a small repeatable evaluation instead.

You can set this up today in Apidog.

Step 1: Create three requests

Create one project with three requests:

GPT-6 Astra
Claude Opus 5.5
Gemini with a configurable model ID

For the Gemini request, use an environment variable:

{
  "model": "{{GEMINI_MODEL}}",
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "text": "{{PROMPT}}"
        }
      ]
    }
  ]
}

Set GEMINI_MODEL to gemini-3.8-flash until Google publishes Argon’s API model ID.

Use the GPT-6 Astra API guide and what is Claude Opus 5.5 for the vendor-specific request formats.

Step 2: Store credentials and shared inputs as variables

Create environment variables for each vendor key:

OPENAI_API_KEY
ANTHROPIC_API_KEY
GOOGLE_API_KEY
GEMINI_MODEL
PROMPT

Put the test prompt in PROMPT so every request receives exactly the same input.

For multi-case testing, add a dataset with fields such as:

{
  "case_id": "bugfix-001",
  "prompt": "Fix the failing test without changing the public API.",
  "max_output_tokens": 4000,
  "max_cost_usd": 0.25
}

Step 3: Add assertions

At minimum, validate:

HTTP status is 200
The response contains non-empty output
Output tokens remain below your configured ceiling
Estimated cost stays within budget
Required structured fields are present, if using JSON output

For example, your assertions should enforce the equivalent of:

assert(response.status === 200);
assert(answer.length > 0);
assert(outputTokens <= maxOutputTokens);
assert(estimatedCostUsd <= maxCostUsd);

Step 4: Track cost per request

The basic cost formula is:

cost =
  (input_tokens / 1_000_000 × input_rate) +
  (output_tokens / 1_000_000 × output_rate)

For a request with 20,000 input tokens and 4,000 output tokens:

Astra:
20,000 × $10 / 1M + 4,000 × $50 / 1M
= $0.20 + $0.20
= $0.40

Opus 5.5:
20,000 × $4 / 1M + 4,000 × $20 / 1M
= $0.08 + $0.08
= $0.16

Argon at intro rates:
20,000 × $2 / 1M + 4,000 × $10 / 1M
= $0.04 + $0.04
= $0.08

Argon at standard rates:
20,000 × $4 / 1M + 4,000 × $20 / 1M
= $0.08 + $0.08
= $0.16

Per-token pricing is not the same as per-task cost. Artificial Analysis measured Argon at roughly 62K output tokens per task versus about 27K for Astra at maximum effort. Measure actual token use for your own tasks.

Step 5: Run one scenario and compare results

Run all three requests as one test scenario. Compare:

Task completion rate
Output validity
Tool-call correctness
Latency
Input and output token usage
Estimated request cost
Human review score for a sample of outputs

When Argon becomes generally available, update only this variable:

GEMINI_MODEL=<published-argon-model-id>

Then rerun the same scenario. You will have a same-prompt comparison against Astra and Opus 5.5 without rebuilding your test setup.

FAQ

Is Gemini 4 Argon better than GPT-6 Astra?

They tie at 53 on Artificial Analysis. In Google’s table, Argon scores higher on most rows, but Astra wins FrontierSWE v2, Terminal-Bench Science 0.1, and OSWorld-2.0. Astra is also available today.

Gemini 4 Argon vs Claude Opus 5.5: which is better?

Google’s table favors Argon on most rows. Opus 5.5 wins Terminal-bench 4.0 and PostTrainBench, and it leads Artificial Analysis 58 to 53. At Argon’s standard rates, the two models cost the same.

Is Gemini 4 Argon cheaper than Claude Opus 5.5?

During the introductory period, Argon is half the price: $2/$10 versus $4/$20 per million input/output tokens. After the introductory period, their list prices are identical. Google has not announced when the introductory pricing ends.

Which model has the largest output limit?

Argon has Google’s stated 1M-token output limit, although Vals AI lists 262K for the configuration it tested. The other models cap synchronous output at 128K. See the 1M output tokens guide for client-side implications.

Can I use Gemini 4 Argon today?

Only through Google’s Fairwind Program, which is available to a set of vetted cyber defense partners. Paid API customers and Google AI Ultra subscribers are expected later, but no date has been published.

Pick by workload, then test

Argon looks strongest in Google’s results for knowledge work, long context, and multimodal tasks. Astra leads on FrontierSWE, Terminal-Bench Science, and OSWorld. Opus 5.5 leads on terminal work and ML engineering while matching Argon’s eventual standard price.

Build production workflows on the models you can call now. Keep the Gemini model ID in an environment variable, record task-level quality and cost, and rerun the same scenario when Argon opens access.

To build the three-request comparison in one project, download Apidog.

Gemini 4 Argon Pricing: $2/$10 Intro, $4/$20 After, and What a 1M-Token Answer Costs

Hassann — Fri, 02 Oct 2026 09:55:44 +0000

Gemini 4 Argon costs $2 per 1M input tokens and $10 per 1M output tokens during an introductory period, then $4 and $20. Cached input is 95% off the input price: $0.10 per 1M tokens at the intro rate and $0.20 afterward. Google has not said how long the intro period lasts, and you cannot buy Argon yet: it is announced but not generally available, and is currently rolling out only to Fairwind Program cyber defenders.

Try Apidog today

This post turns the rate card into implementation-ready budget numbers: comparisons with current models, four pricing scenarios, third-party per-task costs, and cost controls you can configure now. For the model overview, start with what Gemini 4 Argon is; for availability, see is Gemini 4 Argon free. You can build cost assertions in Apidog against a model you can call today, then swap the model name when Argon becomes available.

The price sheet

Google published these prices in the Gemini 4 Argon launch post. Footnote 1 specifies the post-intro rate: “After the introductory period expires, the price of $4 per 1M input tokens and $20 per 1M output tokens will apply.”

Gemini 4 Argon, per 1M tokens	Intro	Standard (after intro)
Input	$2.00	$4.00
Cached input (95% off input)	$0.10	$0.20
Output	$10.00	$20.00
Max output per response (Google)	1M tokens	1M tokens
Cost of one full 1M-token output	$10.00	$20.00

The cached-input rates are derived from Google’s 95% discount rule:

intro cached input    = $2 × 0.05 = $0.10 per 1M tokens
standard cached input = $4 × 0.05 = $0.20 per 1M tokens

Google has not published an input context window or a model ID. It says the output limit is 1M tokens, “up from the previous 64K tokens.” At least one third-party evaluator, Vals AI, lists a 262K max output for the configuration it tested.

Argon vs. current frontier and Gemini models

All prices are per 1M tokens.

Model	Input	Cached input	Output	Max output
Gemini 4 Argon (intro)	$2	$0.10	$10	1M
Gemini 4 Argon (standard)	$4	$0.20	$20	1M
GPT-6 Astra	$10	$1	$50	128,000
Claude Opus 5.5	$4	$0.20	$20	128K (300K on Batch, beta)
Claude Sonnet 5.5	$2	$0.20	$10	128K (300K on Batch, beta)
GPT-6.1 Sol	$2	$0.10	$10	128,000
Claude Fable 5.1	$10	$0.25	$50	128K
gemini-3.1-pro-preview (prompt <=200K / >200K)	$2 / $4	$0.20 / $0.40	$12 / $18	65,536
gemini-3.8-flash (intro / from 2027-01-01)	$0.75 / $1.50	$0.075 / $0.15	$3.75 / $7.50	65,536

Competitor prices come from vendor documentation: OpenAI’s GPT-6 Astra page, Anthropic’s pricing page, and Google’s Gemini API pricing page.

Key comparisons:

Standard Argon matches Claude Opus 5.5. Both are $4 input, $20 output, and $0.20 cached input.
Intro Argon matches Claude Sonnet 5.5 and GPT-6.1 Sol at $2 input and $10 output. Its $0.10 cached-input rate also matches GPT-6.1 Sol.
GPT-6 Astra and Claude Fable 5.1 cost 5x intro Argon and 2.5x standard Argon on a per-token basis. See Claude Fable 5.1 pricing.
Argon’s intro output price ($10) is below gemini-3.1-pro-preview’s ($12), Google’s previous top Pro model.
Long prompts can change the calculation. OpenAI bills prompts over 272K input tokens at 2x input and cache prices and 1.5x output price for the full request. Gemini 3.1 Pro costs more above 200K input tokens; Anthropic does not use that tier. Google has not said whether Argon will have a long-prompt tier.

For capability comparisons alongside price, see Gemini 4 Argon vs GPT-6 Astra vs Claude Opus 5.5.

Treat thinking tokens as output cost

On current Gemini models, thinking tokens are billed as output. Google’s thinking documentation states that “response pricing is the sum of output tokens and thinking tokens.”

Google has not documented Argon-specific billing behavior, but budget as though the same rule applies. Google ran Argon evaluations with its highest thinking settings, so the $10 per 1M output-token intro price should be treated as the cost of both visible answer tokens and reasoning tokens.

Use this cost model:

cost =
  (uncached_input_tokens / 1,000,000 × input_rate)
  + (cached_input_tokens / 1,000,000 × cached_input_rate)
  + ((output_tokens + thinking_tokens) / 1,000,000 × output_rate)

Four worked scenarios

Every example below uses:

tokens / 1,000,000 × per-1M rate

Scenarios 1–3 assume no caching.

1. Typical API call: 20K input, 5K output

Intro pricing

input  = 20,000 / 1M × $2  = $0.04
output = 5,000 / 1M × $10  = $0.05
total  = $0.09

Standard pricing

input  = 20,000 / 1M × $4  = $0.08
output = 5,000 / 1M × $20 = $0.10
total  = $0.18

At 1,000 calls per day:

Pricing period	Daily cost
Intro	$90
Standard	$180

For the same 20K-input, 5K-output call:

Claude Opus 5.5: $0.18
GPT-6 Astra: $0.45 ($0.20 input + $0.25 output)
gemini-3.1-pro-preview: $0.10 ($0.04 input + $0.06 output)
gemini-3.8-flash at its intro rate: about $0.034 ($0.015 input + $0.019 output)

2. Long agent turn: 200K input, 50K output

Intro pricing

input  = 200,000 / 1M × $2  = $0.40
output = 50,000 / 1M × $10  = $0.50
total  = $0.90

Standard pricing

input  = 200,000 / 1M × $4  = $0.80
output = 50,000 / 1M × $20 = $1.00
total  = $1.80

For comparison:

GPT-6 Astra: $4.50 ($2.00 input + $2.50 output)
gemini-3.1-pro-preview: $1.00 ($0.40 input + $0.60 output)

The 200K input size is Gemini 3.1 Pro’s pricing threshold. Prompts beyond that threshold use $4 input and $18 output pricing. If Argon introduces a similar tier, longer agent turns will cost more than the flat-rate examples above.

3. Maximum-size response: 1M output tokens

Output alone costs:

1,000,000 / 1M × $10 = $10.00 intro
1,000,000 / 1M × $20 = $20.00 standard

Add a 100K-token prompt:

Pricing period	Output	Input	Total
Intro	$10.00	$0.20	$10.20
Standard	$20.00	$0.40	$20.40

No other model in the comparison table produces 1M tokens in one synchronous response. Competitors cap output at 128K, and the previous Gemini Pro model caps output at 65,536 tokens.

At Vals AI’s listed 262K max output, a full response would cost approximately:

262,000 / 1M × $10 = $2.62 intro
262,000 / 1M × $20 = $5.24 standard

For engineering considerations such as streaming, timeouts, and gateway limits, see Gemini 4 Argon’s 1M output tokens.

4. Cached 500K-token prompt reused 10 times

Assume you send the same 500K-token codebase or contract set 10 times and receive 5K output tokens per call. The first call pays the full input price; the next nine calls use cached input.

10 calls: 500K prompt, 5K output each	Intro	Standard
Input without caching (10 × 500K)	$10.00	$20.00
Input with caching (1 full + 9 cached)	$1.00 + 9 × $0.05 = $1.45	$2.00 + 9 × $0.10 = $2.90
Output (10 × 5K)	$0.50	$1.00
Total with caching	$1.95	$3.90
Total without caching	$10.50	$21.00

Caching cuts input cost by 85.5% in this example.

However, account for two unknowns:

Google has not said whether Argon charges cache-storage fees. Gemini 3.1 Pro charges $4.50 per 1M tokens per hour, which would add $2.25 to hold 500K tokens for one hour.
A 500K-token prompt is above Gemini 3.1 Pro’s 200K threshold. Argon may introduce a similar tier.

Argon’s standard cached-input rate matches Claude Opus 5.5’s $0.20 rate, so the break-even approach in Claude Opus 5.5 prompt caching cost math also applies here.

Per-token price is not per-task cost

Do not budget from rate cards alone. Measure how many tokens your workload actually uses.

Artificial Analysis lists $1.99 per task to run its Intelligence Index on Gemini 4 Argon (High) at intro prices. The Decoder puts the same run at $3.98 at standard prices. Artificial Analysis scores Argon at 53, the same as GPT-6 Astra (max), which it lists at $3.26 per task.

The important variable is output volume:

Artificial Analysis counts roughly 62K output tokens per Argon task at High.
It counts roughly 27K output tokens per GPT-6 Astra task at its maximum setting.
That is about 2.3x more output tokens for Argon.

At intro pricing:

Argon output cost = 62,000 / 1M × $10 = $0.62
Astra output cost = 27,000 / 1M × $50 = $1.35

At standard Argon prices, The Decoder’s full-task estimate for Argon ($3.98) exceeds Artificial Analysis’s listed $3.26 per task for GPT-6 Astra (max), despite Argon’s standard per-token rates being 60% lower than Astra’s.

Vals AI shows the same pattern. It lists $15.68 per test for Argon on the Vals Index, using the $4/$20 standard rate, compared with:

Claude Opus 5.5: $32.14 per test
Claude Sonnet 5.5: $21.34 per test
GPT-6.1 Sol: $3.24 per test

Sonnet 5.5 and GPT-6.1 Sol share Argon’s intro price on paper, but their per-test costs differ by more than 6x.

Use your own production token counts to budget per-task cost.

Cost controls to implement before Argon ships

1. Cap output tokens

On generateContent, set generationConfig.maxOutputTokens to limit output cost.

{
  "generationConfig": {
    "maxOutputTokens": 8192
  }
}

Google says new models launch on the Interactions API, so configure the equivalent cap there once Argon-specific documentation is available.

A 1M-token output limit is also a maximum output charge of:

$10 per request at intro pricing
$20 per request at standard pricing

Set a lower limit for normal production paths. Reserve large outputs for endpoints that explicitly require them.

2. Cache stable prompt content

Cache content that repeats across requests:

System instructions
Tool schemas
API specifications
Reference documents
Codebase context
Contract sets

Avoid caching user-specific or frequently changing content. The 95% cached-input discount is most useful when a large, stable prompt is reused across multiple calls.

3. Select thinking levels intentionally

Google has not published Argon’s thinking levels. Current defaults include:

gemini-3.1-pro-preview: high
gemini-3.8-flash: medium

When Argon’s settings are documented, benchmark lower thinking levels against your task-quality requirements. Since thinking tokens are expected to be billed as output, reducing unnecessary reasoning can reduce cost.

4. Add usage and cost assertions

Every generateContent response ends with usageMetadata. Save the model name in a GEMINI_MODEL environment variable, then calculate cost from the returned token counts.

In Apidog, you can:

Save a Gemini request in a collection.
Use {{GEMINI_MODEL}} in the request URL or body.
Run the request against gemini-3.8-flash today.
Add a post-response script that reads usageMetadata.
Fail the request when calculated cost exceeds your per-call budget.
Replace only GEMINI_MODEL when Argon’s model ID ships.

Use this calculation:

cost = uncached_input / 1,000,000 × input_rate
     + cached_input   / 1,000,000 × cached_rate
     + (output + thinking) / 1,000,000 × output_rate

What Google has not priced yet

Before committing a production budget, track these unresolved items:

The intro period length and the date that $4/$20 pricing starts
Whether prompts above 200K tokens have a higher price tier
Batch or Flex pricing
Cache-storage fees
Rate limits
Whether a free tier exists

For reference, Gemini 3.1 Pro has Batch and Flex pricing at $1/$2 input and $6/$9 output.

FAQ

How much does Gemini 4 Argon cost per million tokens?

$2 input and $10 output during the intro period, then $4 input and $20 output. Cached input is 95% off: $0.10 during intro pricing and $0.20 afterward.

How long does the intro price last?

Google has not said. The launch post gives no duration or end date.

Are thinking tokens billed as output?

For current Gemini models, yes. Google has not documented Argon’s rules specifically.

How much does a 1M-token output response cost?

$10 at intro pricing and $20 at standard pricing, before input-token charges.

Is Argon cheaper than Claude Opus 5.5 or GPT-6 Astra?

Per token, standard Argon matches Claude Opus 5.5 and is 60% cheaper than GPT-6 Astra. Per task, the result depends on token volume: Artificial Analysis measured Argon using about 2.3x Astra’s output tokens. For a cheaper Gemini model available today, see Gemini 3.8 Flash pricing.

Can I pay for Argon today?

No. It is rolling out only to Fairwind Program partners. Paid API customers and Google AI Ultra subscribers are next, but Google has not provided a date.

Budget it now, measure it later

Use your current traffic data to estimate an Argon range:

intro estimate    = input_tokens × $2/1M + output_tokens × $10/1M
standard estimate = input_tokens × $4/1M + output_tokens × $20/1M

Then implement measurement now:

Download Apidog.
Save a request using gemini-3.8-flash.
Store the model name in GEMINI_MODEL.
Add a cost assertion based on usageMetadata.
Set an output cap and per-request cost ceiling.
When Google publishes Argon’s model ID, update one variable and rerun the suite.

Gemini 4 Argon's 1M Output Tokens: What a Million-Token Response Does to Your API Stack

Hassann — Fri, 02 Oct 2026 09:54:56 +0000

Gemini 4 Argon’s headline number—1M tokens—is its output limit, not its context window. Google says a single Argon response can run to 1 million tokens, roughly 16× the previous 64K cap, but it has not published Argon’s input window. There is also nothing to call yet: Argon is currently available only to Fairwind Program defenders, with paid API customers next when Google opens access. See the release date and access guide.

Try Apidog today

A response this large breaks common API assumptions: requests do not finish in seconds, response bodies do not safely fit in memory, and request cost is no longer small or predictable. This guide shows how to plan for cost, streaming, timeouts, output caps, storage, and testing in Apidog before access arrives. For the model overview, see what Gemini 4 Argon is. For request shapes, see the Gemini 4 Argon API guide.

1M output tokens is not a 1M context window

Do not treat Argon’s 1M figure as a context-window specification. Google’s launch post says it expanded “the model’s output token limit to an industry-leading 1M tokens.”

That 64K comparison matches the 65,536-token output cap of Gemini 3.1 Pro Preview, Google’s previous top Pro model.

Argon’s input window is a separate, unpublished value. Google’s long-context evaluation, described in its evals methodology, used prompts between 256K and 1M tokens. That is a benchmark range, not an API specification.

There is also an output caveat: Vals AI lists a 262K maximum output for the Argon configuration it tested. Google states a 1M-token model limit, while at least one third-party evaluator observed a lower cap on the endpoint it used.

Model	Max output per response	Input or context window
Gemini 4 Argon	1M (Google’s stated limit)	Not published
Gemini 3.1 Pro Preview	65,536	1,048,576
Gemini 3.8 Flash	65,536	1,048,576
GPT-6 Astra	128,000	1,050,000 (922K max input)
Claude Opus 5.5	128K (300K on Batch with a beta header)	1M

Every competitor in this table caps synchronous output at 128K, making Argon’s stated 1M limit about 8× larger. Google’s stated reason is reasoning depth: the model can “generate hundreds of thousands of tokens in a single trajectory” to solve hard problems in one pass.

For other long-running API patterns, see Claude Opus 5.5’s 18-hour tasks and the GPT-6 Astra API guide.

Calculate the worst-case cost first

At Argon’s stated rates, output costs:

Intro period: $10 per 1M output tokens
Standard pricing: $20 per 1M output tokens

A full-length response therefore costs:

Intro: 1,000,000 × $10 / 1,000,000 = $10.00
Standard: 1,000,000 × $20 / 1,000,000 = $20.00

Input is additional. For example, a 200,000-token prompt adds:

Intro: 200,000 × $2 / 1,000,000 = $0.40
Standard: $0.80

That makes a maxed-out call:

$10.40 at intro rates
$20.80 at standard rates

A nightly job that runs 100 such requests would cost $1,040 at intro pricing.

Thinking usage can make this less obvious. On current Gemini models, thinking tokens bill as output. Google has not stated whether Argon follows the same rule or whether thinking counts toward its 1M ceiling. Either way, a short visible answer can still incur substantial output usage.

For additional scenarios, including cached input at 95% off, see the Gemini 4 Argon pricing guide.

Stream every long response

A non-streaming request returns nothing until the entire response is complete. For outputs that may reach hundreds of thousands of tokens, that creates a long silent connection. Any client, proxy, gateway, load balancer, or serverless timeout can terminate it before the first byte arrives.

Use server-sent events (SSE) instead.

For generateContent, use:

:streamGenerateContent?alt=sse

Read each event as it arrives and write each text chunk directly to storage. Do not accumulate the full response body in memory.

This example runs against Gemini 3.8 Flash today. Keep the model name in an environment variable because Google has not published Argon’s model ID. See the Gemini 3.8 Flash API guide for setup details.

import json
import os
import requests

MODEL = os.environ.get("GEMINI_MODEL", "gemini-3.8-flash")
URL = (
    "https://generativelanguage.googleapis.com/v1beta/models/"
    f"{MODEL}:streamGenerateContent?alt=sse"
)

body = {
    "contents": [
        {
            "parts": [
                {
                    "text": "Write a test plan for every endpoint in a payments API."
                }
            ]
        }
    ],
    "generationConfig": {
        "maxOutputTokens": 60000
    },
}

usage = None

with requests.post(
    URL,
    json=body,
    stream=True,
    timeout=(10, 120),
    headers={"x-goog-api-key": os.environ["GEMINI_API_KEY"]},
) as response, open("response.txt", "a", encoding="utf-8") as output:
    response.raise_for_status()

    for line in response.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data:"):
            continue

        event = json.loads(line[5:])

        for candidate in event.get("candidates", []):
            for part in candidate.get("content", {}).get("parts", []):
                output.write(part.get("text", ""))

        output.flush()
        usage = event.get("usageMetadata", usage)

print(usage)

timeout=(10, 120) configures:

A 10-second connection timeout
A 120-second read timeout

In requests, the read timeout is the maximum gap between received bytes, not the total request duration. A stream can continue indefinitely if it keeps sending data within that interval.

The example writes each chunk to disk immediately. On Gemini 3.8 Flash, every event includes running usageMetadata, so the final event contains the token counts to record for cost tracking.

Check timeouts at every hop

Your HTTP client is only one part of the request path. A long stream can also cross a reverse proxy, API gateway, load balancer, and serverless runtime.

Hop	What to check	Symptom when misconfigured
HTTP client	Read or idle timeout, plus any total-request timeout	Exceptions mid-stream only on long responses
Reverse proxy	Read timeout and response buffering for `text/event-stream`	Events arrive in bursts, or the stream cuts off
API gateway	Maximum request duration	Requests fail at the same elapsed time every run
Load balancer	Idle timeout	Drops during long pauses before the first event
Serverless function	Maximum execution time	The function exits while the model is still generating

A fixed cutoff is the key signal. If long requests always fail at the same elapsed time, a hop in the path has a hard duration limit. Streaming alone cannot solve that; move the work off the live request path.

Move the longest jobs to background execution

For very long tasks, do not hold an HTTP request open.

Google’s Interactions API supports background execution with:

background=true

Background execution depends on stored interactions. The documentation states that store=false is incompatible with background execution, so leave storage enabled for these requests.

For retrieving a completed background interaction, follow Google’s documented workflow rather than guessing polling endpoints. Since Google says new models launch on the Interactions API, plan for Argon’s longest jobs to run there.

Set output caps intentionally

The 1M limit is a ceiling, not a target.

For generateContent, use generationConfig.maxOutputTokens to cap each response:

{
  "generationConfig": {
    "maxOutputTokens": 60000
  }
}

On Gemini 3.8 Flash, thinking counts against that cap. In one test, a cap of 2,000 produced:

1,340 thought tokens
656 visible tokens

For the Interactions API, verify the output-cap field in Google’s current documentation before relying on it.

Choose a cap based on the maximum cost you accept per request:

Output cap	Worst-case standard output cost ($20/1M)	Intro output cost ($10/1M)
64,000	$1.28	$0.64
128,000	$2.56	$1.28
500,000	$10.00	$5.00
1,000,000	$20.00	$10.00

Treat a capped response as potentially incomplete. Inspect the final event’s finishReason:

MAX_TOKENS

If the response ended with MAX_TOKENS, either continue in a follow-up turn or increase the cap for that specific job.

Store and parse huge outputs without buffering

A million tokens can produce megabytes of text. Use a streaming storage path from the start.

Write chunks as they arrive to a file or multipart object upload.
Keep partial files when a connection drops. A blind retry can regenerate and rebill the same output.
Request JSON Lines when you need structured output, so each line can be parsed independently.
Log usageMetadata and byte counts rather than full response bodies.
Verify database column limits and queue message-size limits before sending an 800K-token response through them.

Test the pipeline in Apidog before access opens

You can validate the entire workflow against a stand-in model. Download Apidog and run these three checks.

1. Inspect the SSE stream

Send the streaming request to Gemini 3.8 Flash with GEMINI_API_KEY and GEMINI_MODEL configured as environment variables.

Apidog parses text/event-stream responses and displays each event in the Timeline view as it arrives. Use this to inspect:

Chunk sizes
Gaps between events
Final usageMetadata
Whether a proxy buffers the response

2. Stream a much longer fake response

Gemini 3.8 Flash currently caps output at 65,536 tokens. To test parsing, buffering, and timeout behavior beyond that limit, run a local mock that emits Gemini-shaped SSE events:

# long_stream_mock.py: Gemini-shaped SSE for parser and timeout tests (fake data)
import json
import time
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

EVENTS = 20000
DELAY = 0.005
CHUNK = "lorem ipsum " * 40


class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        self.rfile.read(int(self.headers.get("Content-Length", 0)))

        self.send_response(200)
        self.send_header("Content-Type", "text/event-stream")
        self.end_headers()

        for i in range(EVENTS):
            event = {
                "candidates": [
                    {
                        "content": {
                            "parts": [
                                {
                                    "text": CHUNK
                                }
                            ]
                        }
                    }
                ]
            }

            if i == EVENTS - 1:
                event["usageMetadata"] = {
                    "promptTokenCount": 1200,
                    "candidatesTokenCount": 950000,
                    "thoughtsTokenCount": 40000,
                    "totalTokenCount": 991200,
                }

            self.wfile.write(
                f"data: {json.dumps(event)}\n\n".encode()
            )
            self.wfile.flush()
            time.sleep(DELAY)


ThreadingHTTPServer(("127.0.0.1", 8787), Handler).serve_forever()

Set a mock environment base URL to:

http://127.0.0.1:8787

Then send the same streaming request through it.

This mock runs for about two minutes—128 seconds in the original test—and emits 9.6 million characters of text. It is large enough to expose:

A parser that buffers the entire body
A proxy that holds SSE events
A timeout configured too aggressively
Storage code that accumulates output in memory

3. Assert token and cost limits

For a non-streaming generateContent request, assert that:

candidatesTokenCount + thoughtsTokenCount <= configured output cap

Also compute the request cost and assert that it remains below your per-request ceiling at Argon pricing.

The Argon API guide includes a ready-made cost script.

FAQ

Is 1M Gemini 4 Argon’s context window?

No. It is the stated output limit per response, up from 64K. Google has not published Argon’s input window.

How much does a 1M-token Argon response cost?

Output costs $10 at intro rates and $20 at standard rates, plus input costs. See Gemini 4 Argon pricing for more scenarios.

Can I generate a 1M-token response today?

Not unless your organization is in the Fairwind cohort with Argon access. Gemini 3.8 Flash and 3.1 Pro Preview cap output at 65,536 tokens, while Vals AI lists 262K maximum output for the Argon configuration it tested.

Do I have to stream long Argon responses?

Google has not published Argon-specific streaming guidance. However, a non-streaming request that runs for minutes is exposed to every idle timeout in your stack. Stream the response or use background execution through the Interactions API.

How does Argon compare with GPT-6 Astra and Claude Opus 5.5?

Both cap synchronous output at 128K. Anthropic allows 300K on Batch with a beta header. Argon’s stated 1M output limit is about 8× higher.

Your next step

Add streaming and an explicit output cap to your Gemini client now, using Gemini 3.8 Flash. Run the client against the long mock stream until no component in your stack cuts the response off.

When Argon’s model ID becomes available, update GEMINI_MODEL and rerun the same tests in Apidog.

Gemini 4 Argon API: What's Confirmed, What It Will Cost, and How to Get Your Code Ready

Hassann — Fri, 02 Oct 2026 09:54:14 +0000

There is no public Gemini 4 Argon API yet, and Google has not published a model ID. Google announced Argon on September 30, 2026, and it is currently available only to Fairwind Program defenders: a set of Fairwind partners using it as a managed model in Gemini Enterprise. Artificial Analysis lists Google AI Studio as Argon’s API provider, but provides no speed or latency data. That suggests allowlisted pre-release access rather than an endpoint you can sign up for. When the wider rollout begins, Google says it will start “with paid API customers and Google AI Ultra subscribers,” so a paid Gemini API key puts you first in line.

Try Apidog today

That gap between announcement and access is useful preparation time. This guide separates confirmed Argon API details from unknowns, then shows how to build against Gemini 3.8 Flash today so moving to Argon is a one-variable change. You will:

Send Interactions API and generateContent requests.
Detect availability with models.list.
Mock responses in Apidog.
Add a per-request cost ceiling using Argon pricing.

For background, start with what Gemini 4 Argon is. For rollout timing, see the Gemini 4 Argon release date guide.

What’s confirmed about the Gemini 4 Argon API, and what isn’t

Google’s launch post confirms prices and an output limit. Most integration details are still unpublished.

Item	Status	Detail
Input price	Confirmed	$2 per 1M tokens during the intro period; $4 after
Output price	Confirmed	$10 per 1M tokens during the intro period; $20 after
Cached input	Confirmed	95% off input: $0.10 intro, $0.20 standard
Output limit	Confirmed	1M tokens, up from 64K
API surface	Signaled	Google docs say all new models launch on the Interactions API
Model ID	Not published	Absent from the models page, pricing page, and changelog
Input context window	Not published	Google’s long-context eval used prompts up to 1M tokens, but that is not a specification
Thinking levels	Not published	Evals used the “highest thinking settings”; names and defaults are unknown
Rate limits	Not published	No tiers announced
Batch support	Not published	No batch or Flex pricing announced
Long-prompt tier	Not published	Gemini 3.1 Pro charges more above 200K tokens; Argon’s rule is unknown
Intro period length	Not published	No end date for the $2/$10 pricing

Two details affect implementation:

The API surface expectation comes from the Interactions API docs, which state that new models “will launch on the Interactions API.” Expect Argon there first, but do not assume generateContent support until Google confirms it.
Google states a 1M-token output limit, but Vals AI lists a 262K maximum output for the configuration it tested. Check the API response on launch day instead of assuming every endpoint exposes the full million-token limit.

The 1M output tokens guide covers the impact on streaming, timeouts, and storage.

At introductory rates, a request with a 20,000-token prompt and 5,000 output tokens costs:

20,000 × $2 / 1M = $0.04 input
 5,000 × $10 / 1M = $0.05 output
--------------------------------
Total                 = $0.09

At standard $4/$20 rates, that same request costs $0.18. Argon’s introductory output price ($10 per 1M tokens) is below Gemini 3.1 Pro Preview’s $12, while its standard output price matches Claude Opus 5.5. For more scenarios, including cached input and a maximum-size output, see the Gemini 4 Argon pricing breakdown.

Don’t hard-code a model ID you found online

Search results may show Argon-like model IDs from benchmark sites, aggregators, or open-source pull requests. Treat them as placeholders.

Google has not confirmed a public model ID. A guessed ID can cause:

A production 404 on deployment day.
A silent fallback if your SDK or wrapper catches errors broadly.
Incorrect assumptions about supported methods or token limits.

Keep the model name in configuration:

export GEMINI_MODEL=gemini-3.8-flash

Every example below reads GEMINI_MODEL and defaults to gemini-3.8-flash, a stable model available today. Once Google publishes Argon’s real ID, update the environment variable rather than modifying application code.

Get your code ready on Gemini 3.8 Flash

Gemini 3.8 Flash (gemini-3.8-flash) uses the endpoints, headers, and response shapes Argon is expected to use. Its pricing is $0.75 input and $3.75 output per 1M tokens through December 31, 2026.

Store your API key in GEMINI_API_KEY; never commit it to source control. See the Gemini 3.8 Flash API guide for setup details.

Step 1: Send an Interactions API request

The Interactions API has been generally available since June 2026 and is Google’s primary API surface for new models.

Keep both the model and thinking level configurable because Argon’s thinking-level names are not published.

MODEL="${GEMINI_MODEL:-gemini-3.8-flash}"
THINKING="${GEMINI_THINKING:-medium}"

curl -s -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"model\": \"${MODEL}\",
    \"input\": \"List the retry rules a REST client should follow for HTTP 429.\",
    \"generation_config\": {\"thinking_level\": \"${THINKING}\"}
  }"

Use the Python SDK with google-genai 2.3.0 or later:

# pip install "google-genai>=2.3.0"
import os
from google import genai

MODEL = os.environ.get("GEMINI_MODEL", "gemini-3.8-flash")
THINKING = os.environ.get("GEMINI_THINKING", "medium")

client = genai.Client()  # Reads GEMINI_API_KEY from the environment

interaction = client.interactions.create(
    model=MODEL,
    input="List the retry rules a REST client should follow for HTTP 429.",
    generation_config={"thinking_level": THINKING},
)

print(interaction.output_text)

For Gemini 3.8 Flash, valid thinking levels are:

low
medium — default
high

Using minimal returns HTTP 400. See the thinking levels guide for trade-offs.

For multi-turn interactions, pass the prior response ID as previous_interaction_id. To opt out of server-side storage, send store: false.

Step 2: Keep the `generateContent` path working

Existing applications may use the legacy generateContent endpoint, which Google says remains fully supported.

curl -s "https://generativelanguage.googleapis.com/v1beta/models/${MODEL}:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"contents\": [{
      \"parts\": [{
        \"text\": \"List the retry rules a REST client should follow for HTTP 429.\"
      }]
    }],
    \"generationConfig\": {
      \"thinkingConfig\": {
        \"thinkingLevel\": \"${THINKING}\"
      }
    }
  }"

The thinking configuration differs between APIs:

API	Thinking field
Interactions	`generation_config.thinking_level`
`generateContent`	`generationConfig.thinkingConfig.thinkingLevel`

If your client supports both paths, route new models through Interactions by default and retain generateContent as a fallback. Apply the same care to tool definitions; see Gemini 3.8 Flash function calling.

Step 3: Schedule a go-live check with `models.list`

Do not manually refresh changelogs. Poll the API your production application will use.

The models endpoint returns available models, token limits, and supported methods:

import os
import sys
import requests

resp = requests.get(
    "https://generativelanguage.googleapis.com/v1beta/models",
    params={"pageSize": 1000},
    headers={"x-goog-api-key": os.environ["GEMINI_API_KEY"]},
    timeout=30,
)

resp.raise_for_status()

hits = [
    model
    for model in resp.json().get("models", [])
    if "argon" in model["name"].lower()
]

for model in hits:
    print(
        model["name"],
        "in:", model.get("inputTokenLimit"),
        "out:", model.get("outputTokenLimit"),
        model.get("supportedGenerationMethods"),
    )

sys.exit(1 if hits else 0)  # A failed run becomes the alert.

Run this hourly through cron or a CI schedule using the same API key as your production app.

When this call was run on October 1, 2026 with a paid-project key, it returned 61 models, no nextPageToken, and no model name containing argon.

When the script finds Argon, inspect:

The real model ID.
Whether outputTokenLimit is the full 1M tokens.
Which generation methods are supported.

Step 4: Mock the response before you have access

You can build Argon client logic before Argon access is available.

Save the Step 2 generateContent request in Apidog.
Create GEMINI_API_KEY and GEMINI_MODEL environment variables.
Send the request once against Gemini 3.8 Flash.
Save the actual response as an endpoint response example.
Set the project mock behavior to Response example first:
- Project Settings
- Feature Settings
- Mock Settings

Apidog’s default Smart Mock generates values from the schema. Using Response example first makes the mock URL return your saved Gemini response instead. Your frontend, queue workers, and parsers can then run against the mock without consuming tokens.

This is a current Gemini response schema mock, not an Argon-specific schema. Google has not published an Argon schema. It is still a practical target because Argon is expected to use the same API surface.

To simulate a large Argon response, edit the example’s usageMetadata values and verify that billing, alerting, queueing, and storage logic behave correctly.

Step 5: Assert on `usageMetadata` and enforce a cost ceiling

Every generateContent response includes usageMetadata. Add an Apidog post-processor that prices each response at Argon’s standard rates.

// Apidog post-processor: price this response at Gemini 4 Argon's standard rates
const u = pm.response.json().usageMetadata;

const IN = 4 / 1e6;   // USD per input token after the intro period
const OUT = 20 / 1e6; // USD per output token

// Thinking bills as output on current Gemini models.
const out =
  (u.candidatesTokenCount || 0) +
  (u.thoughtsTokenCount || 0);

const cost = u.promptTokenCount * IN + out * OUT;

pm.test("usageMetadata is present", () => {
  pm.expect(u).to.be.an("object");
});

pm.test("cost under $0.10 at Argon rates", () => {
  pm.expect(cost).to.be.below(0.10);
});

Choose the ceiling per request. A $0.10 limit is reasonable for the short prompt used in this example.

Google has not stated how Argon bills thinking tokens. This script assumes the current Gemini billing behavior, where thinking tokens are priced as output. Keep the same saved request and run it against Gemini 3.8 Flash now, then Argon later. The token and cost differences become your regression comparison.

FAQ

Is the Gemini 4 Argon API available?

Not publicly. Argon is currently rolling out only to Fairwind Program partners through Gemini Enterprise. Paid API customers and Google AI Ultra subscribers are next, but Google has not provided a date.

What is the Gemini 4 Argon model ID?

Google has not published one. Third-party strings are placeholders, so keep the model name in an environment variable and monitor models.list.

How much will the Gemini 4 Argon API cost?

It costs $2 input and $10 output per 1M tokens during an introductory period of unknown length, then $4 input and $20 output per 1M tokens. Cached input is discounted by 95%. See Gemini 4 Argon pricing.

Will Argon work with generateContent?

Google has not said. Its documentation says new models launch on the Interactions API, so build for Interactions first and treat generateContent as a fallback.

Does Google AI Ultra give me API access?

No. AI Ultra is a consumer subscription, not an API key. Google says API access begins with paid API customers.

Your next step

Set GEMINI_MODEL in every environment, schedule the models.list check, and save both Interactions and generateContent requests with the cost assertion attached.

Download Apidog to keep requests, mocks, and tests in one workspace. When Google publishes Argon’s model ID, update one environment variable.

What Is Gemini 4 Argon?

Hassann — Fri, 02 Oct 2026 09:53:05 +0000

Gemini 4 Argon is Google’s new frontier model, announced on September 30, 2026. It is currently available only to Fairwind Program defenders: a vetted group of cyber defense partners. Introductory pricing is $2 per million input tokens and $10 per million output tokens, increasing to $4 and $20 respectively after the introductory period. Argon raises the output limit to 1M tokens per response. There is no public API, published model ID, or release date yet.

Try Apidog today

This guide covers what Google has and has not confirmed, where Argon fits in the Gemini lineup, expected access, pricing, benchmarks, and what you can build now. Choosing a model today? Read our Gemini 4 Argon vs GPT-6 Astra vs Claude Opus 5.5 comparison. If you test model APIs in Apidog, the implementation section shows how to make Argon a one-variable model switch.

What Google has confirmed vs. what it has not

Early coverage often mixes Google statements with third-party estimates. The table below separates confirmed information from unknowns using Google’s launch post and evals methodology.

Item	Status	What we know
Announcement	Confirmed	September 30, 2026, by Koray Kavukcuoglu of Google DeepMind
Access today	Confirmed	A set of Fairwind Program partners
Next in line	Confirmed, undated	Paid API customers and Google AI Ultra subscribers
Price	Confirmed	$2/$10 intro, then $4/$20 per 1M tokens; cached input is 95% off
Output limit	Confirmed	1M tokens, up from 64K
Benchmarks	Confirmed, Google-reported	A 19-row table plus a methodology PDF
Model ID	Not published	Strings online are third-party placeholders
Input context window	Not published	Google's long-context eval used prompts up to 1M tokens
Knowledge cutoff	Not published	Nothing from Google
Intro period length	Not published	No date for the switch to $4/$20
Rate limits, free tier	Not published	Nothing from Google
Release date	Not published	“As soon as possible”

If a site lists an Argon context window, model string, or speed figure, treat it as unconfirmed until Google publishes it in official documentation.

What Gemini 4 Argon is and where it sits

Argon is the only Gemini 4 model announced so far and Google’s new top-tier Gemini model. Google calls it “our new frontier model,” built “to sustain deep reasoning across complex, long-horizon workflows.” It claims frontier performance in software engineering, enterprise knowledge work such as legal and finance, and cybersecurity defense.

A Google spokesperson told Reuters that Argon is larger than the company’s previous “Pro” models.

Until now, the top Gemini API model was gemini-3.1-pro-preview, which remains in Preview:

Input: 1,048,576 tokens
Output: 65,536 tokens
Pricing: $2 input / $12 output per million tokens for prompts up to 200K

Argon’s introductory output price of $10 per million tokens undercuts that output rate. Google has not said whether Argon will have a separate long-prompt tier like 3.1 Pro or whether more Gemini 4 models will follow.

Google says it already uses Argon internally for coding, research, and writing. It reports that Argon agents freed more than 300 TiB of fleet memory and are migrating C and C++ code to Rust, including up to 800K+ lines for the Fuchsia Zircon kernel. Those rewrites remain under audit before production use.

Who can use Gemini 4 Argon today, and who is next

Today: a subset of Fairwind partners.

Fairwind is Google’s limited-access cyber defense program with more than 650 partners. However, only “a set of Fairwind Program partners” can currently access Argon, either directly or through CodeMender, Google’s code security agent.

Direct access is provided as a managed model on Gemini Enterprise with zero data retention. Partners must commit to:

Phishing-resistant MFA
Access restricted to internal security, incident-response, or penetration-testing teams
Per-employee usage tracking

Governments, critical infrastructure operators, and core technology platforms can apply through the Fairwind Program page.

Next: paid API customers and Google AI Ultra subscribers.

Google says it will gather feedback from early testers while iterating on guardrails. It is also participating in the U.S. government’s voluntary pre-release access process. The rollout section is titled “Rolling out soon,” but Google provides no date.

Track updates in our Gemini 4 Argon release date and access guide.

Not yet: everyone else.

As of October 1, Argon does not appear on the Gemini API models page, pricing page, Gemini app, Antigravity, or OpenRouter.

Google AI Ultra, starting at $99.99 per month in the US, is a consumer subscription rather than an API key. Google has not specified which Ultra tier will receive Argon first. There is no free access path today; see Is Gemini 4 Argon free? for available alternatives.

Gemini 4 Argon pricing

Token type	Intro price, per 1M	Price after intro, per 1M
Input	$2.00	$4.00
Cached input, 95% off	$0.10	$0.20
Output	$10.00	$20.00
One full 1M-token response, output only	$10.00	$20.00

Google has not announced how long the introductory period will last.

At standard rates, Argon costs the same as Claude Opus 5.5. At introductory rates, it matches GPT-6.1 Sol and Claude Sonnet 5.5. Cached-input prices are calculated from Google’s stated 95% discount.

For scenario-based estimates, see Gemini 4 Argon pricing.

The 1M output limit

Google says it is “significantly expanding the model’s output token limit to an industry-leading 1M tokens, up from the previous 64K tokens.”

For developers, this means a single response can theoretically contain hundreds of thousands of generated tokens. Google’s argument is that this lets the model work through complex problems in one trajectory.

For comparison:

Model	Maximum synchronous output
Gemini 4 Argon	1M tokens
GPT-6 Astra	128K tokens
Claude Opus 5.5	128K tokens
Claude Fable 5.1	128K tokens

Two implementation caveats matter:

This is an output limit, not a published context-window specification. Google has not published Argon’s input window.
Use the limit reported by your endpoint. Vals AI, for example, lists a 262K maximum output for the configuration it tested.

When Argon becomes available, set explicit client-side timeout and output-cost limits rather than assuming every request can safely generate 1M tokens. See the guide to Argon’s 1M output tokens for timeout, streaming, and cost-cap guidance.

Gemini 4 Argon benchmarks: the headline

All benchmark figures below come from Google’s table. Argon’s scores are Google-reported, with some self-computed and others sourced from leaderboards such as Vals AI. Competitor scores are primarily vendor-reported or public-leaderboard results, and benchmark harnesses differ.

By our recount, Argon leads 13 of 19 rows outright, ties one, and trails on five.

Benchmark	Gemini 4 Argon	GPT-6 Astra	Claude Fable 5.1	Claude Opus 5.5
Vals Index	68.9%	63.1%	65.8%	67.0%
DeepSWE v1.1	77.9%	74.1%	67.4%	74.2%
GraphWalks 256K to 1M, F1	84.2%	71.8%	65.0%	66.8%
FrontierSWE v2	55.0%	65.5%	56.3%	62.3%
Terminal-bench 4.0	57.4%	58.2%	57.9%	66.4%
PostTrainBench	45.3%	44.3%	40.2%	49.3%

The rows Argon loses include:

FrontierSWE v2
Terminal-Bench Science 0.1
OSWorld-2.0
Terminal-bench 4.0
PostTrainBench

Third-party evaluations place Argon at the frontier but do not show a clear overall lead. Artificial Analysis scores Argon at 53 on its Intelligence Index, tied with GPT-6 Astra and Claude Fable 5.1, behind Claude Opus 5.5 at 58 and Claude Sonnet 5.5 at 56 using maximum settings. Vals ranks Argon first among 41 models on the Vals Index.

For the full benchmark table and methodology notes, see Gemini 4 Argon benchmarks.

Cyber defense in one paragraph

Google says Argon can “autonomously find, validate, and patch critical software vulnerabilities.” For trusted defenders and internal teams, Google says it will release Argon without cyber guardrails so they can use its cybersecurity defense capabilities.

On DeepMind’s cyber page, Argon scores:

85.8% on real-world vulnerability discovery, compared with 71.0% for Gemini 3.8 Flash Cyber
68% on CWE-bench v1, tied with Grok 4.7 and GPT-6 Astra
0.7% Gray Swan indirect prompt-injection attack success rate at k=15, the lowest score on that chart

For API implications, read what Argon’s cyber release means for the APIs you run and the overview of Gemini 3.8 Flash Cyber.

What to do now as a developer

Do not block your implementation on Argon. Build with a model you can call today, and isolate the model name in one environment variable.

Use gemini-3.8-flash as the current stand-in:

Stable model
1,048,576 input tokens
65,536 output tokens
Free tier
$0.75 input / $3.75 output per million tokens through December 31, 2026

Google’s Interactions API documentation says that all new models, multimodal capabilities, tools, and agentic features will launch on the Interactions API. Build against that API now, then replace the model variable when Google publishes Argon’s model ID.

MODEL="${GEMINI_MODEL:-gemini-3.8-flash}"

curl -s "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$MODEL"'",
    "input": "List the breaking changes in this OpenAPI diff.",
    "generation_config": {"thinking_level": "medium"}
  }'

Make the model switch testable

In Apidog, save this call as a reusable request and define these environment variables:

GEMINI_API_KEY=your_api_key
GEMINI_MODEL=gemini-3.8-flash

Then add response assertions for usage fields:

usage.total_output_tokens
usage.total_thought_tokens

Thinking tokens bill as output tokens, so use both fields when enforcing a token budget. Keep the Gemini 3.8 Flash response as a baseline. Once Argon appears in the official models list:

Change GEMINI_MODEL.
Re-run the same request.
Compare latency, output quality, and token usage.
Keep the token assertion enabled to catch unexpectedly large responses.

For request shapes, see the Gemini 4 Argon API guide. To decide whether waiting is worthwhile, read Argon vs. Gemini 3.8 Flash.

FAQ

Can I use Gemini 4 Argon in the Gemini API?

Not yet. Only a set of Fairwind partners have access, and the public models list does not include it.

What is the Gemini 4 Argon model ID?

Google has not published one. Strings currently in circulation, including evaluator slugs, are third-party placeholders. Do not hard-code them.

When is the Gemini 4 Argon release for developers?

Google has not provided a date. Paid API customers and Google AI Ultra subscribers are expected to come first, “as soon as possible.”

Is Gemini 4 Argon better than GPT-6 Astra and Claude Opus 5.5?

It leads most rows in Google’s table, but it ties GPT-6 Astra on Artificial Analysis and trails Claude Opus 5.5 there. For more detail, see what is Claude Opus 5.5 and the GPT-6 Astra API guide.

Does Gemini 4 Argon have a 1M context window?

Google has not said. The published 1M figure is an output limit. Google’s long-context evaluation used prompts up to 1M tokens, but that is not a published context-window specification.

Get ready before Argon opens

Argon is announced, priced, and benchmarked, but you cannot call it through the public API yet.

Build with Gemini 3.8 Flash using the Gemini 3.8 Flash API guide, keep the model ID in one environment variable, and add a token-usage assertion to every request.

To prepare your request collection, environment variables, and baseline responses for the future model swap, download Apidog and configure it now.

Codex after DevDay 2026: cloud tasks, a voice CLI, /agents, Code Review, and Security Cloud

Hassann — Fri, 02 Oct 2026 09:47:33 +0000

At OpenAI DevDay 2026 on September 29, Codex received four updates: Codex cloud with reusable environments (Plus, Pro, Business, Healthcare, Edu, Enterprise); a refreshed Codex CLI with voice, an /agents view, prompt editing, resume, and worktrees (all plans); Code Review in the ChatGPT desktop app for GitHub PRs and GitLab MRs with automatic cloud reviews (all plans); and Codex Security Cloud for scheduled repository scans and fix preparation (Pro, Business, Enterprise, Edu). The same day, Codex CLI 0.159.1 made GPT-6.1 Sol the default model.

Try Apidog today

This guide covers what each change does, which commands you’ll use, and where the gaps are. For the rest of the event, see the DevDay 2026 hub for API developers. One gap matters for API teams: Codex writes and reviews code, but its reviews do not call your running API. That is where contract tests in Apidog fit in—the last section shows the CI wiring.

What changed in Codex at DevDay 2026

Update	What it does	Where you use it	Plans	Status
Codex cloud environments	Prepare a setup once and reuse it in isolated workspaces	Web, desktop app, `codex cloud`	Plus, Pro, Business, Healthcare, Edu, Enterprise	Available
Refreshed Codex CLI	Voice, `/agents` view, prompt edit, resume, worktrees	Terminal	All plans	Available
Code Review	PR and MR review pane, automatic cloud reviews	ChatGPT desktop app, GitHub, GitLab	All plans	GitHub GA; GitLab MRs in preview
Codex Security Cloud	Scheduled scans, deduplicated findings, fix preparation	Codex cloud, via a plugin	Pro, Business, Enterprise, Edu	Research preview
GPT-6.1 Sol as default	Default in the CLI’s bundled model catalog	CLI, also selectable in Codex and ChatGPT Work	Plus, Pro, Business, Enterprise, Edu; admin-enabled on Enterprise and Edu	Available

Sources: OpenAI’s DevDay 2026 recap, the Codex what’s new page, and the Codex documentation linked below.

Codex cloud: reusable environments

Codex cloud runs coding tasks in the cloud so work can continue while your computer is asleep. The DevDay change is the environment model. According to the cloud environments documentation, an environment is a reusable setup containing repositories, dependencies, tools, and access settings. Each task gets its own isolated workspace created from the published environment version.

Create a reusable environment

Start a new Codex task.
Choose Work in > Cloud.
Select Create environment.
Choose the GitHub repositories to check out.
Let Codex inspect the repositories, install dependencies, and test the workflow.
Provide details Codex cannot infer.
Review the generated setup report.
Select Publish.

Codex records the setup in two fields:

An install script for dependencies and project setup.
A start skill that starts services and verifies they are ready.

Configure network access safely

Three configuration details matter for API work:

Repository refresh runs in the background and retains dependency caches, so new tasks do not repeat installation.
Internet access is configured per environment: use a package-manager preset, custom domains, or unrestricted access.
Network secrets keep credentials outside the sandbox. Programs receive a placeholder, while a proxy substitutes the real value only for approved HTTPS destinations.

If a cloud task must call a staging API, add the staging host to the allowed domains and save its token as a network secret—not as a plain environment variable.

From a terminal, use codex cloud to hand work to Codex cloud and list recent cloud chats.

The refreshed Codex CLI

Install the CLI with the script from the Codex CLI documentation:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

The Codex changelog also lists npm releases:

npm install -g @openai/codex

CLI version 0.159.1, released September 29, added GPT-6.1 Sol as the default model in the bundled catalog. The same changelog entry also covers the Amazon Bedrock Mantle and Runtime catalogs.

The CLI documentation uses gpt-6.1-sol medium in its sample session. According to the Codex models page, Free and Go are not included at launch, while Enterprise and Edu require an administrator to enable the model.

To change models:

/model

Or start a session with:

codex --model gpt-6-sol

For more context, see What is GPT-6.1 Sol?, including the change from GPT-6 Sol and the missing none effort.

CLI feature-to-command map

Feature	How to use it	Source
Voice	Voice conversations have been on by default since 0.156.0. Press `F8` to toggle and use `/voice settings` to select a voice.	Changelog
`/agents` view	View your agents, filter tasks by status, and start worktree sessions.	Recap, changelog
Prompt edit	Edit an earlier prompt to revert the thread to that point.	Changelog
Resume	Run `codex resume` to return to a saved chat.	CLI docs
Worktrees	Use `/worktree` to run a chat in a new Git worktree. Use `/fork` to copy a chat into a new chat or worktree.	Slash command reference
Model	Use `/model` to select a model and reasoning effort.	CLI docs
Local review	Use `/review` to check uncommitted changes, a commit, or a base branch.	CLI docs

Worktree support has been enabled by default since 0.156.0. This makes parallel agents practical because each agent gets its own checkout instead of editing the same files.

Run /review before committing. It reports prioritized findings without modifying your working tree.

Code Review: desktop app, GitHub, and GitLab

Code Review is a plugin in the ChatGPT desktop app. The Code Review documentation says it displays a pull request’s description, changed files, comments, and checks so you can investigate issues before approving.

GitHub review is generally available. GitLab merge request support is in preview.

Enable automatic cloud reviews

Automatic cloud reviews require:

The ChatGPT Codex connector.
Repository permissions.
A connected GitHub repository.

Review comments appear both on GitHub and in the Code Review pane. Cloud review does not require you to create or manage a cloud environment.

According to the GitHub integration guide, you can manually trigger a review by commenting:

@codex review

On GitHub, Codex flags only P0 and P1 issues.

Add repository-specific review rules

Place a ## Code Review Rules section in AGENTS.md. Put the file closest to the code it governs so the rules apply at the right scope.

Keep deterministic checks in CI. Review rules do not replace tests, branch protections, or required approvals.

For a deeper workflow walkthrough, see Codex for code review.

Codex Security Cloud

Codex Security Cloud scans connected GitHub repositories in Codex cloud. OpenAI’s recap describes scheduled scans, deduplicated findings, and cloud-based fix preparation. It also includes Daybreak Blue models without a separate application. See the Daybreak Blue vs Red explainer for details on those tiers.

Codex Security Cloud is in research preview for Pro, Business, Enterprise, and Edu.

Set up a repository scan

Follow the Security Cloud setup guide:

Install the Codex Security Cloud plugin from the ChatGPT plugin marketplace.
Select Connect GitHub and grant access to the repositories you want to scan.
Choose a repository and cloud environment.
Set the target to Repository.
Start a scan.
For ongoing coverage, select Commit changes.
Adjust the environment, days of history, or pause state under Monitoring settings.
For a finding, select Fix with Codex to draft a patch.
Select Create draft pull request to open the change for review.

For per-PR coverage, GitHub also supports:

@codex security review

This is a deeper, security-specific review currently in research preview.

Where Apidog fits: Codex reviews code, but your API still needs a test

Code Review reads diffs, descriptions, comments, and checks. It does not send requests to your running service.

A pull request can rename a JSON field or change a status code, look correct in review, and still break every API client. That is a contract problem, so it needs a test that calls the API.

Use Codex and Apidog together:

Keep your OpenAPI specification and test scenarios in Apidog.
Assert status codes and validate responses against endpoint schemas.
Run scenarios in CI through the Apidog CLI on every pull request.
Review failing contract checks alongside Codex comments in the PR.

See API contract testing for the broader approach.

Start with endpoints your clients depend on most. Assert:

Expected status codes
Required response fields
Field types
Schema compatibility

For example, if a Codex-generated pull request changes user_id to userId, the schema check fails. The CLI exits non-zero, the pull request check turns red, and reviewers see the break before they need to spot the rename in a long diff.

This split aligns with OpenAI’s guidance: use review rules for consequential, repository-specific behavior, and use CI for deterministic checks.

Run Apidog contract tests in GitHub Actions

name: api-contract-tests

on: pull_request

jobs:
  apidog:
    runs-on: ubuntu-latest
    steps:
      - run: npm install -g apidog-cli
      - run: apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
          SCENARIO_ID: ${{ vars.APIDOG_SCENARIO_ID }}
          ENV_ID: ${{ vars.APIDOG_ENV_ID }}

Codex can run the same command locally before opening a pull request, allowing it to see contract-test failures while it still has task context.

See Using the Apidog CLI in Codex for the local setup, or building a software factory with Codex for the full task-to-tested-PR loop.

FAQ

What did Codex get at DevDay 2026?

Reusable cloud environments, a refreshed CLI with voice, /agents, prompt edit, resume, and worktrees; Code Review in the desktop app with automatic cloud reviews; and Codex Security Cloud in research preview.

What is the default model in the Codex CLI now?

GPT-6.1 Sol, since CLI 0.159.1 on September 29. Use /model to switch models or change reasoning effort.

Can I use Codex cloud on the Free plan?

No. Codex cloud is available on Plus, Pro, Business, Healthcare, Edu, and Enterprise. The CLI and Code Review are available on all plans. See the free Codex guide for no-cost routes.

Does Codex Code Review test my API?

No. It reads the pull request diff, description, comments, and checks. Add API contract tests in CI so a check fails when behavior changes.

Who can use Codex Security Cloud?

Pro, Business, Enterprise, and Edu users can access it in research preview. Install it as a plugin and connect GitHub.

Next step

Update the CLI, run /model to confirm you are using gpt-6.1-sol, and try /review on your next branch.

Then download Apidog, turn one critical endpoint into a test scenario, and add the GitHub Actions job above. Every Codex-written pull request can then be checked against both the diff and the running API.

Sign in with ChatGPT for developers: the OAuth flow, plan usage, and what it means for your API bill

Hassann — Fri, 02 Oct 2026 09:47:06 +0000

Sign in with ChatGPT is OpenAI’s OAuth 2.0 and OpenID Connect login for ChatGPT users globally. Your app receives a stable account ID plus the user’s name, email address, and profile picture when available. Since DevDay on September 29, 2026, Plus and Pro users can also authorize participating apps to run eligible AI requests against their ChatGPT plan instead of your API key, subject to a weekly per-app cap they configure. Your app never receives their conversations, memories, or an API key.

Try Apidog today

This guide shows how to implement the flow, decide when to use plan usage versus your API key, handle failure states, and test the integration in Apidog. For the rest of the event, see the DevDay 2026 roundup. If identity and authorization are unclear, start with OAuth vs OpenID.

Sign in with ChatGPT at a glance

Item	What OpenAI documents
Identity scopes	`openid profile email`
Plan usage scopes (open-source flow)	`offline_access resource.invoke chatgpt.tokens.use.direct`, with `resource=https://api.openai.com/v1`
Your app receives	An ID token; with plan usage, an access token and a refresh token
Plan usage eligibility	Plus and Pro, in participating apps
Where usage counts	The plan’s ChatGPT Work and Codex usage
Per-app control	Weekly cap as a share of overall weekly usage; credits after the cap are off by default
Plan usage tokens	Access token: 1 hour; refresh token: 30 days and replaced on each refresh
Developer access	Commercial apps: limited trial via an interest form. Open-source apps: self-serve

Sources: the Sign in with ChatGPT docs, token reference, and OpenAI’s help article on using your ChatGPT plan in other apps.

What your app receives—and what it does not

Start with identity-only sign-in. Request these scopes:

openid profile email

The website guide documents the resulting claims:

profile can include the user’s name and profile picture.
email can include the email address and email-verification claims.
Identity scopes do not grant access to ChatGPT conversations or OpenAI API resources.

Use the verified OIDC subject as the primary account key:

issuer + client_id + sub

Do not identify or automatically link users by email alone. OpenAI warns that a matching email address is not proof of account ownership. If an existing account has the same email, require the user to explicitly confirm the link.

Plan usage is a separate authorization grant. When a user approves the additional scopes, the token response can include:

An access token for eligible Responses API calls
A refresh token for continued access

For identity-only sign-in, do not require an access_token. The required artifact is the id_token.

Implement the OAuth flow

The website integration uses Authorization Code with PKCE plus OpenID Connect. See the Authorization Code grant with PKCE overview.

Load OpenAI endpoints from:

https://auth.openai.com/.well-known/openid-configuration

The production values documented by OpenAI are:

Issuer:                 https://auth.openai.com
Authorization endpoint: https://auth.openai.com/api/accounts/authorize
Token endpoint:         https://auth.openai.com/api/accounts/oauth/token
JWKS URI:               https://auth.openai.com/.well-known/jwks.json

1. Generate request-bound security values

Before redirecting the user, generate:

A random state value
A PKCE code_verifier
An S256 code_challenge
A random OIDC nonce

Store state, nonce, and the verifier server-side, associated with the pending browser session.

2. Redirect to authorization

Build an authorization request using:

Your client ID
The exact registered redirect URI
Your requested scopes
state
nonce
code_challenge
code_challenge_method=S256

For identity only, request:

openid profile email

For eligible plan usage flows, request the documented additional scopes:

offline_access resource.invoke chatgpt.tokens.use.direct

Also include:

resource=https://api.openai.com/v1

3. Validate the callback

After consent, OpenAI redirects to your callback with an authorization code.

Your backend must:

Validate the returned state.
Exchange the authorization code at the token endpoint.
Validate the ID token signature using OpenAI’s JWKS.
Validate iss, aud, exp, and nonce.
Find, create, or explicitly link the local user account.
Create your own application session.

Public clients do not send a client secret. A confidential client using client_secret_basic sends its secret only through the HTTP Basic authentication header.

Open-source and locally hosted clients

Open-source tools use a different registration path. The open-source sign-in guide starts with:

client_id=dynamic_agent_client

Include:

agent_name_hint: your application name
ext_agent_host_id: a persistent identifier for each host

The callback returns an issued client ID such as oaiapp_.... Save and reuse it. The redirect URI is a 127.0.0.1 loopback URI, and this flow does not use a client secret.

Explain plan usage to users

Your product UI and support documentation should set expectations before a user enables plan usage.

Eligible requests count against the user’s plan. They consume ChatGPT Work and Codex usage from a Plus or Pro subscription.
Each app has a weekly cap. Users configure it as a percentage of total weekly usage. The documentation’s settings example ranges from 10% to 100%.
The cap is not reserved capacity. Usage in ChatGPT or other connected apps can exhaust the plan before your app reaches its configured cap.
Credits are opt-in. Continuing on credits after limits are reached is disabled by default and requires the app cap to be set to 100%.
Plus has a shared five-hour limit. According to the accounts and sessions documentation, it applies across every app using the plan. It does not apply to Pro.
Disconnecting stops future usage. It does not reverse already consumed usage. OpenAI does not notify your application directly; detect the disconnect when a request or refresh fails.

Users manage these settings in ChatGPT under Usage:

chatgpt.com/settings/usage

Follow OpenAI’s UI guidelines and provide a Manage usage link.

Get a client ID

OpenAI’s DevDay recap names 16 plan-usage partners, including Cognition’s Devin, Notion, Vercel, T3, OpenClaw, and Dactyl. The New Stack also lists Amp, Warp, Kilo Code, and OpenCode, with Lovable marked as coming soon. If you run OpenClaw, it appears in both lists.

As The New Stack reported, Sam Altman summarized the value on stage: “now you don’t have to cover their token costs to get them going.”

Choose the onboarding route that matches your product:

Commercial or hosted apps: Sign-in is a limited trial. Request a client ID through OpenAI’s interest form, whether you need identity only or plan usage.
Open-source and locally hosted tools: Plan usage is available to open-source partners through the self-serve flow.

Decide when to use plan usage versus your API key

Plan usage shifts eligible model costs from your API account to the user’s ChatGPT subscription. It can reduce variable model costs, but it also means your app must operate within the user’s eligibility and plan limits.

	Your API key	User’s ChatGPT plan
Who pays	You, per token	User’s plan; credits only if they opt in
Who can use it	Every user	Plus and Pro users who grant `chatgpt.tokens.use.direct`
Limits	Your rate-limit tier	Weekly plan usage, per-app cap, Plus five-hour window
Request shape	Full Responses API	`store: false` and `stream: true` required; no `temperature`, `max_output_tokens`, file search, or Code Interpreter
Typical failure	429 when you exceed your tier	429 `subscription_sharing_usage_limit_exceeded`, including in a mid-stream `response.failed` event
Fallback	Your choice	None automatically; OpenAI does not switch billing
What to show	Your pricing and usage	“Using ChatGPT plan,” a Manage usage link, and supported product plans

The preview limitations page documents the restrictions. Features requiring stored conversation state or hosted tools do not run on a user’s plan today.

A practical default is a hybrid model:

Use plan usage for interactive requests from eligible Plus and Pro users.
Use your API key for users without plan usage.
Keep background jobs, CI, and scheduled agents on your API key.
When the plan cap is reached, pause plan-backed requests.
Show Manage usage and offer your own credits or billing path as a secondary option.

For broader architecture decisions, see API key vs OAuth and OAuth for AI agents.

Test the sign-in flow and failure paths in Apidog

Apidog does not sign users in with ChatGPT. Use it to exercise your OAuth configuration, token exchange requests, and application error handling.

Download Apidog and create a dedicated environment for this integration.

1. Store OAuth configuration as environment variables

Add these variables:

SIWC_CLIENT_ID
SIWC_REDIRECT_URI
SIWC_CLIENT_SECRET
ACCESS_TOKEN

Mark SIWC_CLIENT_SECRET as sensitive for confidential clients. Reference variables in requests rather than hardcoding them:

{{SIWC_CLIENT_ID}}
{{SIWC_REDIRECT_URI}}
{{ACCESS_TOKEN}}

This prevents secrets from being stored in saved requests or shared collections.

2. Run the Authorization Code with PKCE flow

In the Auth tab:

Select OAuth 2.0.
Select Authorization Code with PKCE.
Enter the authorization and token endpoints.
Set the scope to openid profile email.
Use a callback URL registered for your OpenAI client.
Complete the browser consent flow.

The Apidog OAuth 2.0 guide covers the field-by-field setup.

3. Validate the token response

Save the token exchange as its own POST request to the token endpoint. Include the authorization code, PKCE verifier, redirect URI, and client ID.

Add a post-processing script to validate the response structure:

const body = pm.response.json();

pm.test("token exchange returned an ID token", () => {
  pm.expect(pm.response.code).to.eql(200);
  pm.expect(body.id_token).to.be.a("string");
});

const decode = require("atob");
const part = body.id_token
  .split(".")[1]
  .replace(/-/g, "+")
  .replace(/_/g, "/");

const claims = JSON.parse(
  decode(part + "=".repeat((4 - (part.length % 4)) % 4))
);

pm.test("ID token claims match this client", () => {
  pm.expect(claims.iss).to.eql("https://auth.openai.com");
  pm.expect(claims.aud).to.include(pm.environment.get("SIWC_CLIENT_ID"));
  pm.expect(claims.sub).to.be.a("string").and.not.empty;
  pm.expect(claims.exp * 1000).to.be.above(Date.now());
});

Use this only for response-level testing. Your backend must still verify the JWT signature and nonce.

Log name, email, and picture rather than asserting that they always exist, because OpenAI returns them when available.

For plan usage, also verify that the response scope contains:

chatgpt.tokens.use.direct

4. Mock failure paths

Do not rely on a real Plus account as your only test fixture. Create Apidog mock responses for the cases your application must handle.

Scenario	Mock response	Expected application behavior
Plan usage declined	Token response where `scope` does not include `chatgpt.tokens.use.direct`	Keep the user signed in; offer plan usage setup or another billing path
Cap reached	429 with `error.code` set to `subscription_sharing_usage_limit_exceeded`	Pause plan-backed requests and show Manage usage
Stream fails after starting	`response.failed` event with `subscription_sharing_usage_limit_exceeded`	Mark the request as failed; do not treat stream start as success
User is not eligible	403 `subscription_sharing_user_not_eligible`	Do not retry or loop through OAuth
User disconnected	Refresh returns `invalid_grant`, or request returns 401 `subscription_sharing_invalid_user`	Clear stored tokens and request sign-in again

Chain these cases into a scenario and run it in CI with the Apidog CLI. OpenAI’s errors and recovery page lists the full error set.

5. Verify a live streaming request

With a real plan token, call the Responses API using the access token:

curl --no-buffer https://api.openai.com/v1/responses \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "input": [{"role": "user", "content": "Say exactly: Hello, world!"}],
    "store": false,
    "stream": true
  }'

In Apidog, set the request authorization to:

Bearer {{ACCESS_TOKEN}}

Treat response.completed as the only success signal. A stream that starts successfully can still end with response.failed.

FAQ

Can Free users sign in with ChatGPT?

Yes. Sign in with ChatGPT is available to ChatGPT users globally. Using a ChatGPT plan inside another app requires Plus or Pro.

Does my app receive the user’s OpenAI API key?

No. Your app receives an ID token and, when plan usage is approved, an OAuth access token for eligible Responses API requests.

What happens when the user hits their cap?

Requests fail with subscription_sharing_usage_limit_exceeded. This can be an HTTP 429 or a response.failed event after streaming starts. Pause plan-backed requests and link the user to Manage usage.

Can a Plus user run GPT-6.1 Sol through a partner app?

The documentation example uses gpt-6.1-sol with a plan token. List the account’s available models with that token before offering a model in your UI. See is GPT-6.1 Sol free for more context.

Next step

If you run a commercial app, join the waitlist and implement cap-reached and disconnect handling with mocks while you wait. Treat plan usage as an optional billing path beside your own API billing, not an automatic replacement.

Save your token assertions and failure scenarios in Apidog. When your client ID arrives, the real token should be the only new variable.

MCP Events explained: build and test a webhook-emitting MCP server ChatGPT can subscribe to

Hassann — Fri, 02 Oct 2026 09:45:48 +0000

MCP Events let an MCP server push updates to ChatGPT as soon as they occur, eliminating agent-side polling. Since OpenAI DevDay on September 29, 2026, ChatGPT supports the proposed MCP Events specification at protocol version 2026-07-28 (MCP 2.0) on all plans. To support it, implement events/list, events/subscribe, and events/unsubscribe; advertise events in server/discover; verify callback endpoints; and sign every webhook delivery with Standard Webhooks HMAC. ChatGPT accepts webhook delivery only.

Try Apidog today

This guide shows the request shapes, server-side validation rules, and an end-to-end test workflow. If you need MCP fundamentals first, read what MCP is. You can send JSON-RPC requests and mock callback endpoints in Apidog.

MCP Events at a glance

Item	What ChatGPT expects
Protocol	MCP 2.0, version `2026-07-28`
Capability	`"events": {}` in `server/discover` capabilities
Methods	`events/list`, `events/subscribe`, `events/unsubscribe` on the same authenticated endpoint as tools
Delivery	Webhook only: no polling, streaming, `gap`, or `terminated` notifications
Signing	Standard Webhooks HMAC-SHA256
Headers	`webhook-id`, `webhook-timestamp`, `webhook-signature`, `X-MCP-Subscription-Id`
Secret	`whsec_` plus base64 that decodes to 24–64 bytes, supplied by ChatGPT
Payload limit	256 KiB (262,144 bytes), one event per request
Subscription ID	Deterministic from principal, callback URL, event name, and arguments
Callbacks	HTTPS, challenge-verified, no private addresses, no redirects

Sources: OpenAI’s MCP Events guide and the draft MCP Events design sketch.

Why use events instead of polling?

Without events, an agent repeatedly calls a tool and diffs results. That wastes requests when nothing changed and introduces delay when something does change.

With MCP Events, your server sends a notification when it detects a matching change. The implementation trade-offs are the same as traditional webhooks vs. polling, but applied to MCP.

Typical use cases include:

Watch a project board for new tasks, then have ChatGPT read linked documents and draft a plan.
Turn channel bug reports into draft pull requests using message.created filtered by channel_id.
Apply document review comments using comment.created filtered by document_id.

The extension comes from MCP’s Triggers and Events Working Group (repository) and remains experimental. Pin your implementation to 2026-07-28. For the broader launch, see the DevDay 2026 hub.

1. Advertise and define events

First, add events to your server/discover response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {},
      "events": {}
    }
  }
}

Next, implement events/list. Each event definition should include:

name
description
delivery: ["webhook"]
inputSchema for subscription arguments, such as document_id
payloadSchema for the data field sent in each delivery

Implementation rules:

Use stable, descriptive event names.
Validate filters against inputSchema.
Apply filters on the server, not in the client.
Return only events the authenticated account is authorized to access.

2. Implement `events/subscribe`

When a user asks ChatGPT to monitor something, ChatGPT calls events/subscribe:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "events/subscribe",
  "params": {
    "name": "comment.created",
    "arguments": {
      "document_id": "doc_123"
    },
    "delivery": {
      "mode": "webhook",
      "url": "https://receiver.example.com/mcp-events/callback_123",
      "secret": "whsec_<base64-encoded-signing-key>"
    },
    "cursor": null
  }
}

Before creating or refreshing a subscription:

Authorize the user for the event and requested arguments.
Validate the event name and arguments against the event definition.
Require a whsec_ secret whose decoded value is 24–64 bytes.
Require an HTTPS callback URL.
Reject private, local, and non-public callback addresses.
Verify the callback endpoint before sending application data.
Store the subscription owner, filters, URL, secret, and expiration.

Return a subscription record:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "id": "sub_123",
    "refreshBefore": "2026-10-02T12:00:00Z",
    "cursor": null,
    "truncated": false
  }
}

Make subscriptions deterministic and idempotent

Use these rules to avoid duplicate subscriptions:

Deterministic IDs: Derive id from the authenticated principal, callback URL, event name, and canonicalized arguments. The design sketch suggests a truncated SHA-256 hash.
Idempotent upserts: A repeated subscribe request with the same identity should update the existing record. Canonicalize JSON arguments before comparing them so key ordering does not create duplicates.
Refresh support: ChatGPT calls events/subscribe again before refreshBefore, using the same identity and the last saved cursor. Return a new expiry time.
Secret rotation: If a refresh includes a new secret, replace the stored secret and sign with both keys during a short transition period.
Replay support: Return cursor: null for event types your server cannot replay.

3. Verify the callback before delivering data

Before sending application events, POST a signed verification request with a fresh, single-use, short-lived challenge:

{
  "type": "verification",
  "challenge": "a-single-use-random-value"
}

Use a unique webhook-id, such as msg_verification_123, and include the same signing headers used for event delivery.

ChatGPT replies with:

{
  "challenge": "a-single-use-random-value"
}

Only activate the subscription after a successful 2xx response and a constant-time challenge comparison.

If verification fails, return JSON-RPC error -32015 (CallbackEndpointError) with a reason such as:

{
  "reason": "challenge_failed"
}

or:

{
  "reason": "timeout"
}

Cache successful verification per principal and callback URL for a bounded period so normal subscription refreshes do not trigger unnecessary challenges.

Harden outbound webhook requests

The callback verification exists because the subscriber provides the signing secret. Without verification, an attacker could point your server at a victim URL and cause unwanted traffic.

Apply these controls to verification and normal deliveries:

Require HTTPS.
Resolve and validate the target at connection time.
Block loopback, private, local, and other non-public IP ranges.
Do not follow redirects.
Use explicit development-only allowlists for local testing.

4. Deliver and sign events

When a matching change occurs, POST one event object to the callback URL:

{
  "eventId": "evt_456",
  "name": "comment.created",
  "timestamp": "2026-10-01T12:05:00Z",
  "data": {
    "document_id": "doc_123",
    "comment_id": "comment_456",
    "text": "Can we add the rollout dates to this section?",
    "url": "https://docs.example.com/doc_123#comment_456"
  },
  "cursor": null
}

Send these headers:

Content-Type: application/json
webhook-id: evt_456
webhook-timestamp: <unix-seconds>
webhook-signature: v1,<base64-signature>
X-MCP-Subscription-Id: sub_123

Serialize the JSON body once and sign those exact bytes. Do not parse, mutate, and reserialize the payload between signing and sending.

Delivery rules:

Send one event per request.
Keep each payload below 256 KiB.
For large records, send a summary and expose a read tool for full content.
Treat user-authored text as data, never as model instructions.
Retry transient failures with capped exponential backoff.
Keep the same event ID across retries, but generate fresh signing headers for each attempt.
Do not retry 410 Gone or 413 Payload Too Large.
Design write tools to be idempotent because events can arrive out of order.

For retry design guidance, see reliable webhook design.

5. Verify Standard Webhooks signatures

Per the Standard Webhooks specification, sign this exact content:

${webhook-id}.${webhook-timestamp}.${body}

Use these rules:

Strip whsec_ from the secret.
Base64-decode the remaining value to get the HMAC key.
Sign with HMAC-SHA256.
Send one or more space-separated signatures in webhook-signature.
Each signature uses the format v1,<base64>.

The MCP draft requires receivers to:

Reject timestamps older than five minutes.
Deduplicate deliveries by webhook-id.

ChatGPT verifies deliveries on its side, but running a strict local receiver is useful when testing your sender.

// receiver.mjs: strict Standard Webhooks receiver for local tests (Node 18+)
import { createServer } from "node:http";
import { createHmac, timingSafeEqual } from "node:crypto";

const SECRET = process.env.WEBHOOK_SECRET; // whsec_...
const MAX_BYTES = 256 * 1024;
const TOLERANCE_S = 5 * 60;
const seen = new Set();

export function verify(raw, h, secret, now = Math.floor(Date.now() / 1000)) {
  const id = h["webhook-id"];
  const ts = h["webhook-timestamp"];
  const sigs = h["webhook-signature"];

  if (!id || !ts || !sigs) return false;

  const t = Number(ts);
  if (!Number.isInteger(t) || Math.abs(now - t) > TOLERANCE_S) {
    return false;
  }

  const key = Buffer.from(secret.replace(/^whsec_/, ""), "base64");
  const expected = createHmac("sha256", key)
    .update(`${id}.${ts}.`)
    .update(raw)
    .digest();

  return sigs.split(" ").some((signature) => {
    const [version, b64] = signature.split(",");
    const received = Buffer.from(b64 ?? "", "base64");

    return (
      version === "v1" &&
      received.length === expected.length &&
      timingSafeEqual(received, expected)
    );
  });
}

if (SECRET) {
  createServer((req, res) => {
    const chunks = [];
    let size = 0;

    req.on("data", (chunk) => {
      size += chunk.length;
      if (size <= MAX_BYTES) chunks.push(chunk);
    });

    req.on("end", () => {
      if (size > MAX_BYTES) {
        return res.writeHead(413).end();
      }

      const raw = Buffer.concat(chunks);

      if (!verify(raw, req.headers, SECRET)) {
        return res.writeHead(401).end();
      }

      let body;
      try {
        body = JSON.parse(raw);
      } catch {
        return res.writeHead(400).end();
      }

      if (body.type === "verification") {
        res.writeHead(200, { "Content-Type": "application/json" });
        return res.end(JSON.stringify({ challenge: body.challenge }));
      }

      const id = req.headers["webhook-id"];

      if (!seen.has(id)) {
        seen.add(id);
        console.log(
          req.headers["x-mcp-subscription-id"],
          body.name,
          id
        );
      }

      res.writeHead(200).end();
    });
  }).listen(8787);
}

Run the receiver:

WEBHOOK_SECRET=whsec_... node receiver.mjs

This receiver:

Returns 413 for payloads larger than 256 KiB.
Returns 401 for invalid or stale signatures.
Echoes verification challenges.
Logs each webhook-id once.

The verify() implementation was checked against the Standard Webhooks JavaScript library signing test vector. For more background, see webhook signature verification.

Your server should reject localhost by default because it is a private target. For development, either configure an explicit allowlist or expose the receiver through a tunnel.

6. Test the full subscription lifecycle

Use Apidog to test the failure modes documented by OpenAI.

Create an environment with:

MCP_URL
MCP_TOKEN
CALLBACK_URL
WEBHOOK_SECRET

Send each JSON-RPC request as a POST to {{MCP_URL}} with:

Authorization: Bearer {{MCP_TOKEN}}
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: <method-name>

These headers follow the Streamable HTTP binding.

Every request body also needs params._meta containing:

io.modelcontextprotocol/protocolVersion
io.modelcontextprotocol/clientCapabilities

OpenAI’s examples omit _meta, but missing metadata also returns -32602. Include it so validation tests fail for the intended reason.

Test checklist

Discovery
- Call server/discover.
- Assert $.result.capabilities.events exists.
- Assert $.result.supportedVersions contains 2026-07-28.
- Call events/list.
- Assert every event includes webhook in delivery.
Idempotent subscription
- Subscribe using {{CALLBACK_URL}} and {{WEBHOOK_SECRET}}.
- Extract $.result.id into SUB_ID.
- Send the identical request again.
- Send it again with reordered arguments keys.
- Assert the returned ID equals {{SUB_ID}} every time.
Validation
- Send a secret that decodes to fewer than 24 bytes.
- Send an http:// callback URL.
- Send a private-IP callback URL.
- Assert each invalid request returns -32602 (InvalidParams).
Verification challenge
- Create an Apidog mock endpoint that responds with:
```
 { "challenge": "wrong" }
```

Subscribe using the cloud mock URL.
Assert error code -32015.
Assert $.error.data.reason is challenge_failed.
Point CALLBACK_URL to the local receiver and confirm the subscription succeeds.

Oversize payload
- Trigger an event larger than 262,144 bytes.
- Your sender should reject it before delivery.
- If it reaches the receiver, expect 413.
- Confirm the sender logs only one attempt and does not retry.
Replay and tampering
- Copy a signed outbound delivery into a new Apidog request.
- Resend it immediately: expect 200 and no duplicate receiver log entry.
- Change one body byte: expect 401.
- Resend the original after five minutes: expect 401.

Save these requests as a scenario and run them in CI with the Apidog CLI. For additional coverage, see the MCP server testing playbook and how to test webhooks.

FAQ

What are MCP Events?

An experimental MCP extension that lets a server push event notifications to a client instead of requiring polling. ChatGPT supports webhook mode at 2026-07-28.

Does ChatGPT support polling or streaming for MCP Events?

No. ChatGPT supports webhook delivery and callback verification only. Polling, streaming, and gap and terminated notifications are not supported.

Which ChatGPT plans get MCP Events?

OpenAI’s DevDay recap says the feature is available on all plans.

Who creates the signing secret?

The subscriber. ChatGPT sends a whsec_ secret in delivery.secret; your server validates, stores, and signs with that secret. Your server does not generate its own replacement secret.

How is this different from the Agents API?

MCP Events push data from your server into ChatGPT. The OpenAI Agents API runs agents you build and reports their progress through streaming or webhooks.

Next step

Start with one server, one event, and one filter:

Add "events": {} to server/discover.
Implement one events/list definition.
Add events/subscribe with validation and callback verification.
Sign a single event delivery.
Run the six tests against a local receiver before connecting ChatGPT.

Download Apidog to save the checks as a scenario and run them on every commit.

OpenAI Agents API vs Responses API vs Agents SDK vs AgentKit: which one to build on

Hassann — Fri, 02 Oct 2026 09:44:39 +0000

These four names operate at different layers. The key decision is simple: who runs the agent loop? The Responses API is a model endpoint, so your application runs the loop. The Agents SDK is a TypeScript and Python library whose runner executes the loop inside your application. The Agents API, in public beta since September 10, 2026, runs OpenAI’s Codex harness for you and manages the session and, optionally, the sandbox. AgentKit is the October 2025 bundle of Agent Builder, ChatKit, Connector Registry, and Evals; Agent Builder is scheduled to shut down on November 30, 2026.

Try Apidog today

DevDay on September 29 added computer use to the Agents API, making the naming distinction more important. See the DevDay 2026 roundup. This guide compares the loop, compute, state, pricing, and maturity of each option, then shows how to migrate from a hand-rolled Responses loop. For sessions and approvals, read the OpenAI Agents API guide. You can test each HTTP surface in Apidog.

OpenAI agent options side by side

	Agents API	Responses API	Agents SDK	AgentKit
What it is	Managed agent runtime on the Codex harness	Model endpoint: `POST /v1/responses`	TypeScript and Python library	Bundle: Agent Builder, ChatKit, Connector Registry, Evals
Who runs the loop	OpenAI	Your code	SDK runner in your app	Agent Builder workflows, exported to SDK code or embedded with ChatKit
Where compute runs	OpenAI-hosted sandbox, your sandbox, or none	Your environment, plus hosted tools	Your runtime and sandbox providers	Not applicable
Where state lives	OpenAI session: config, turns, items	Your history, `previous_response_id`, or Conversations API	Your storage, SDK sessions, or Responses state	Published, versioned workflows
What you pay	Tokens, tools, and hosted containers; no extra fee	Tokens and tools	Tokens and tools, plus your hosting	Underlying API usage; no separate subscription
Integration effort (per OpenAI)	Low	High	Medium	Not rated
Status	Public beta: `OpenAI-Beta: agents=v1`	Recommended for new projects	Current	Agent Builder and Evals shut down Nov. 30, 2026; ChatKit stays
Data controls	US data residency only; not ZDR-eligible; state kept until deleted	ZDR-eligible with limitations; regional endpoints	Depends on the APIs it calls	Not applicable

Sources: OpenAI’s agent runtime comparison, Agents API overview, and deprecations page.

Who runs the loop

This is the decision that drives most of the other tradeoffs.

Responses API: your code runs the loop

Hosted tools such as web search, file search, code interpreter, and remote MCP can perform multiple internal calls in one request. Your custom functions are different: the model returns a function_call item, your application executes it, and then you submit a function_call_output with the same call_id.

Your application controls:

When the loop stops
How conversation history is stored
Whether responses are persisted (store: false disables default storage)
When long contexts are compacted with context_management and compact_threshold
How function calls are retried, approved, audited, or rejected

Use the Responses API guide and function calling guide when implementing this loop.

Agents SDK: the SDK runner runs the loop in your process

The SDK runner handles the agent loop and handoffs, but your server still owns:

Deployment
Tool implementations
State storage
Human approval flows
Authentication and audit logs

With Sandbox Agents, the harness can stay in your infrastructure while commands run in a Unix-local, Docker, or hosted-provider workspace. This keeps approval and access-control decisions outside the sandbox.

Agents API: OpenAI runs the loop

The managed harness handles sessions, orchestration, context compaction, and recovery. It also adds subagents, tool search, and programmatic tool calling.

Remote MCP servers are called directly by OpenAI. Your application still handles custom function tools: when a session includes a function_call in required_actions, submit an agent.session.input.tool_result event containing the turn_id and call_id.

Compare the same task

# Responses API: one model call; your code owns the loop
curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-sol",
    "reasoning": {"effort": "low"},
    "tools": [{"type": "web_search"}],
    "input": "Summarize the breaking changes in the latest Node.js release."
  }'

# Agents API: a durable session; OpenAI owns the loop
curl https://api.openai.com/v1/agents/sessions \
  -H "OpenAI-Beta: agents=v1" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": {
      "model": "gpt-6-astra",
      "tools": [{"type": "web_search"}]
    },
    "environment": {"type": "none"},
    "input": "Summarize the breaking changes in the latest Node.js release."
  }'

The Agents API documentation uses gpt-6-astra in its examples. It does not state whether other models are accepted, so verify compatibility before replacing it with gpt-6.1-sol.

Compute, state, and cost

Compute

The Agents API can provision and manage a sandbox for the full session. Set environment.type to one of:

openai_hosted
self_hosted
none

With the Agents SDK, you select and pay for the sandbox provider. With Responses, code runs in your environment except for OpenAI-hosted tools.

State

An Agents API session stores configuration, turns, and items on OpenAI’s side. Send a follow-up as an event on the same session ID.

With Responses, chain turns with previous_response_id or use the Conversations API. With the SDK, state lives in your storage, SDK sessions, or Responses state.

Cost

Token pricing is identical across these options because they call the same models.

The Agents API has no additional platform fee, but hosted containers cost from $0.03 for 1 GB to $0.48 for 16 GB per 20-minute session. The SDK adds the cost of your own hosting. AgentKit has no separate subscription, according to the AgentKit explainer.

Data controls

The Agents API supports US data residency only and does not support Zero Data Retention, including when you use a self-hosted sandbox.

OpenAI’s data controls page lists /v1/agents as not ZDR-eligible, with state retained until deletion. In comparison, /v1/responses is ZDR-eligible with limitations and is available through regional endpoints such as eu.api.openai.com.

If ZDR or EU residency is required, the Agents API is not currently an option.

AgentKit in late 2026: what remains

AgentKit launched on October 6, 2025 with four components:

Agent Builder: Deprecation was announced June 3, 2026. Shutdown is scheduled for November 30, 2026. OpenAI’s migration guide exports workflows as Agents SDK code or recreates them as ChatGPT Workspace Agents for Business, Enterprise, or Edu.
Evals: Existing evals become read-only on October 31, 2026. The dashboard and API are scheduled to shut down on November 30.
ChatKit: Remains available for embedded chat.
Connector Registry: The administration panel for connectors and MCP servers across OpenAI products.

For a durable, code-first AgentKit path, use the Agents SDK. See the AgentKit guide.

Which option should you build on?

Choose	Use it when
Agents API	Tasks run for minutes, need files, commands, or a browser, and you do not want to operate the loop, sandboxes, or session storage. US residency and a beta header are acceptable.
Responses API	You make single calls, need complete control over each turn, require ZDR or non-US residency, or already have a working loop.
Agents SDK	Typed application code must own tools, storage, approvals, and handoffs, and the loop must run in your infrastructure.
ChatKit	You need an embedded chat UI in your product.
Agent Builder	Do not start new work here. Export existing workflows before November 30, 2026.

On AWS, Bedrock Managed Agents, powered by OpenAI, brings the Agents API’s core capabilities to run natively in AWS.

For MCP integration in either code-first option, see MCP servers with OpenAI agents.

Move from a Responses loop to the Agents API

If you already run a Responses-based tool loop and want OpenAI to operate it, migrate in these steps.

Map your existing components.

Move instructions, model selection, and tools into agent. Map your container configuration to environment. Replace your conversation store with a session ID.
Move remote MCP servers into agent.tools.

Store server tokens in a vault attached through vault_ids; do not include secrets in prompts.
Rewrite custom function handling.

Replace the function_call_output loop with a handler for:
- agent.session.requires_action when streaming
- agent.session.action_required when using webhooks

Return results with agent.session.input.tool_result.

Subagents cannot call function tools, so keep function-tool execution on the main agent.

Remove application-side compaction logic.

The managed harness compacts context automatically.
Handle turn events.

Stream or receive webhooks for:
- agent.session.turn.completed
- agent.session.turn.failed
- agent.session.turn.cancelled

Do not treat an idle session as a successful turn.

Validate platform constraints first. Confirm that US-only residency, no ZDR support, and the required beta header work for your application.

Keep both implementations in one Apidog project

Before switching production traffic, test the old and new paths side by side.

Create a Responses folder and an Agents API folder in one Apidog project.
Add a shared environment containing:
- {{OPENAI_API_KEY}}
- A model variable
Send identical prompts through both implementations.
Assert status codes and required output fields.
Open the Agents API stream as an SSE request to inspect turn events.
Save the requests as a test scenario.
Run the scenario in CI with the Apidog CLI.

This makes beta-level API changes visible as failed checks instead of production surprises. For assertion ideas, read the production AI agent reliability guide.

Download Apidog to set up the project.

FAQ

Is the Agents API replacing the Responses API?

No deprecation has been announced. OpenAI lists the Agents API, Agents SDK, and Responses API as current options for different requirements.

Is OpenAI AgentKit deprecated?

Partly. Agent Builder and Evals are scheduled to shut down on November 30, 2026. ChatKit remains available.

Does the Agents SDK use the Agents API?

No. The SDK runs in your application. The Agents API runs a managed harness in OpenAI’s service.

What happened to the Assistants API?

OpenAI’s deprecations page sets its removal for August 26, 2026 and directs developers to the Responses and Conversations APIs.

Which option is cheapest?

Token prices are the same. The main difference is hosted-container pricing for the Agents API versus the infrastructure costs you operate with the SDK or Responses API.

Pick one path this week

Choose based on who should operate the loop, then validate the choice with real requests before building the application.

If you are starting fresh, create one Agents API session and compare its output with your existing Responses setup in Apidog.

How to use the OpenAI Agents API ?

Hassann — Fri, 02 Oct 2026 09:44:23 +0000

The OpenAI Agents API runs OpenAI’s open-source Codex harness for you. Send POST https://api.openai.com/v1/agents/sessions with the OpenAI-Beta: agents=v1 header, an agent definition, and a task. OpenAI runs the model and tool loop, persists the session, and can provision a sandbox. There is no Agents API fee: you pay for tokens, tools, and hosted container time ($0.03 to $0.48 per 20-minute session for 1 GB to 16 GB sandbox sizes). It entered public beta on September 10, 2026, and OpenAI added computer use at DevDay on September 29.

Try Apidog today

This guide covers a first REST session, progress events, MCP tools, subagents, and the computer-use approval flow. For a comparison with OpenAI’s other agent surfaces, read Agents API vs Responses API vs Agents SDK. For the rest of the event, see the DevDay 2026 roundup. Every call is plain HTTP, so you can send it from Apidog before writing application code.

OpenAI Agents API at a glance

Item	Value
Status	Public beta since Sep 10, 2026; computer use added Sep 29
Create a session	`POST /v1/agents/sessions`
Beta header	`OpenAI-Beta: agents=v1` (the OpenAI SDKs add it)
Key permissions	`api.agents.read`, `api.agents.write`, `api.responses.write`
Pricing	No Agents API fee; model tokens at API rates, tools at standard rates (web search $10 per 1K calls)
Hosted containers	`$0.03` (`small`, 1 GB), `$0.12` (`medium`, 4 GB), `$0.48` (`large`, 16 GB) per 20-minute session
Environments	`none`, `openai_hosted`, `self_hosted`
Model in the docs’ examples	`gpt-6-astra`
Data controls	US data residency only; no Zero Data Retention (ZDR)
Max request size	4 MiB

Sources: Introducing the Agents API, the Agents API overview, and the pricing page.

The four concepts

The API is built around four pieces:

Agent: The model, instructions, tools, and MCP servers. Pass it inline, or save and reuse its agent_id.
Environment: An optional sandbox or computer where the agent reads files and runs commands.
Session: A durable instance of an agent that persists configuration, conversation, and saved work.
Events and items: Events report live progress; items are saved messages and tool calls.

A message sent to an idle session starts a new turn. A message sent during a turn steers it. The harness—the hosted Codex instance that runs the model and tool loop, according to the architecture guide—also handles context compaction.

Pick an environment

Use environment.type to decide where commands run:

none: No compute. Remote MCP servers and function tools still work, but built-in Bash, apply-patch, workspace files, and executor MCPs do not.
openai_hosted: OpenAI manages a Linux sandbox with Python and Node.js in /workspace. Set container_size to small (1 GB), medium (default, 4 GB), or large (16 GB). Configure network.access as enabled, disabled, or restricted with allowed_domains. Files in /workspace/outputs become artifacts when a turn completes. An idle sandbox without keep-alives can be deleted after an hour.
self_hosted: Your infrastructure. Run codex exec-server on a laptop, container, or remote sandbox. It connects outbound using a separate environment key.

The launch post lists sandbox partners Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel. The self-hosted environment guide also adds AWS Lambda MicroVMs.

Your first session over REST

Export a key with the required permissions as OPENAI_API_KEY, then create a streaming session with a small container:

curl --no-buffer https://api.openai.com/v1/agents/sessions \
  -H "OpenAI-Beta: agents=v1" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": {
      "model": "gpt-6-astra",
      "instructions": "Write clean code, run it, and report the actual output."
    },
    "environment": {
      "type": "openai_hosted",
      "container_size": "small"
    },
    "input": "Create tree.py, a script that prints a tree of the files in the current directory. Run it and show the output.",
    "stream": true
  }'

With stream: true, the response is the first turn’s event stream. Save the session ID from that stream, then use the same session resource for the rest of the lifecycle:

Action	Request
Follow up or steer	`POST /v1/agents/sessions/{id}/events` with an `agent.session.input.message` event
Cancel the active turn	Same endpoint with event type `agent.session.input.cancel`
Read saved work	`GET /v1/agents/sessions/{id}/items?order=asc&limit=100`
Clean up	`DELETE /v1/agents/sessions/{id}`

The JavaScript SDK uses the same shape. This example adds web search, subagents, and a vault:

import OpenAI from "openai";

const client = new OpenAI();

const session = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [{ type: "web_search" }],
    multi_agent: {
      enabled: true,
      max_concurrent_subagents: 3,
    },
  },
  vault_ids: [process.env.VAULT_ID],
  environment: { type: "openai_hosted" },
  input: "Summarize breaking changes in the latest release notes.",
});

console.log(session.id);

Follow progress: stream or webhooks

Stream events

Open GET /v1/agents/sessions/{id}/events?stream=true with Accept: text/event-stream before sending input so you do not miss early events.

Watch for:

agent.session.turn.output_text.delta and agent.session.turn.output_text.done for text output.
agent.session.turn.completed, agent.session.turn.failed, or agent.session.turn.cancelled for the final turn outcome.
agent.session.requires_action when the agent needs a function result, environment connection, or computer-use approval.

Avoid these common mistakes:

agent.session.idle does not mean the turn succeeded.
A completed turn can still contain failed tool calls.
Closing an SSE stream does not stop the running task.
Streams do not replay missed events. After a disconnect, open a new stream and retrieve the session and its items.

Use webhooks for long-running work

Subscribe to:

agent.session.created
agent.session.action_required
agent.session.in_progress
agent.session.idle
agent.session.failed

The event names differ slightly:

Stream: requires_action
Webhook: action_required

Webhook payloads omit call details. In your webhook handler, retrieve the session and inspect required_actions. Verify every signature using a webhook signature verification flow. For the architecture behind this pattern, see long-running API operations.

MCP tools, tool search, programmatic tool calling, and subagents

Add an MCP server

Add an MCP server to agent.tools:

{
  "type": "mcp",
  "server_label": "openai_docs",
  "transport": {
    "type": "http",
    "server_url": "https://developers.openai.com/mcp"
  },
  "required": true
}

By default, OpenAI creates the connection with connection_origin: "service", so the server must be reachable from OpenAI.

Use these alternatives when needed:

Set connection_origin: "environment" for a private-network server.
Use stdio to start a server inside the sandbox.
Pass transport.authorization for credentials scoped to one session.
Attach a vault credential (static_bearer or mcp_oauth) through vault_ids.

Use tool search for large tool sets

MCP tools are discovered automatically when the model supports tool search.

For many function tools, add:

{ "type": "tool_search" }

Then mark functions that should load only when needed:

{
  "defer_loading": true
}

Programmatic tool calling

Programmatic tool calling is enabled by default. The agent gets an exec tool that runs JavaScript in an isolated V8 runtime. It can loop over tool calls and trim large results before adding them to model context.

Disable it when you need every tool call handled directly:

{
  "type": "programmatic_tool_calling",
  "enabled": false
}

Enable subagents

Enable subagents with a concurrency limit:

{
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3
  }
}

The default limit is 6. Subagents share the environment filesystem and inherit MCP tools and web search, but they cannot use function tools. A turn’s subagent_id is null for the main agent.

Computer use: the DevDay addition

Computer use gives the agent a hosted browser. Add the tool and enable a desktop in a hosted environment:

{
  "agent": {
    "model": "gpt-6-astra",
    "tools": [
      {
        "type": "computer_use",
        "include_screenshots": true
      }
    ]
  },
  "environment": {
    "type": "openai_hosted",
    "desktop": {
      "enabled": true
    },
    "network": {
      "access": "enabled"
    }
  }
}

The browser requires user approval before visiting every new website origin, including public sites.

When you receive agent.session.requires_action:

Retrieve the session.
Find computer_use_approval_request entries.
Inspect the nested request.type.
Send the appropriate result through the events endpoint.

There are two request types:

browser_origin_access: Show origin and reason, then submit approve, deny, or cancel.
browser_authentication: Show the sign-in fields, optional login options, and credential_origin. Submit action: "submit" with user-provided values, or action: "cancel".

Submit an origin approval result like this:

curl "https://api.openai.com/v1/agents/sessions/$SESSION_ID/events" \
  -H "OpenAI-Beta: agents=v1" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "events": [
      {
        "type": "agent.session.input.computer_use_approval_request_result",
        "request_id": "REQUEST_ID",
        "response": {
          "type": "browser_origin_access",
          "decision": "approve"
        }
      }
    ]
  }'

Browser work is stored as computer_use_call items. Each item can include id, turn_id, title, status, and output. When include_screenshots is enabled and a screenshot is available, output carries a base64 JPEG.

Do not write screenshots to logs. They can expose account data.

The computer use guide highlights these implementation constraints:

Origin approval is not action confirmation. Approving a site does not make the agent ask before each purchase or delete. If you need that control, restrict the browser to resources that cannot take those actions or use a browser runtime you control.
Sign-in covers email, passwords, and verification codes. Passkeys and QR-code sign-in are not supported.
Only the main agent can request authentication. Subagents cannot.
Disable automatic retries on credential submissions. Use maxRetries: 0 in the SDK or --retry 0 with curl.
A 202 means accepted, not successful. Navigation or sign-in may still fail. Authentication requests expire after five minutes.
Origin approval does not override network policy. Add the site and its redirect domains to network allow rules too.

The recap says computer use ships “through the API and in Codex and ChatGPT Work on Pro 500 and Enterprise.” For UI-driven testing with the same model, see GPT-6 Astra computer use for API testing.

Give the agent your API, not your UI

A browser is a fallback for software without an API. If you own the system, wrap it in an MCP server instead:

Expose typed tools.
Avoid origin approval prompts.
Return structured, checkable results.

Computer use vs structured APIs covers the trade-off. The Apidog MCP Server can feed your API specification to the coding assistant that writes the wrapper.

Test the Agents API in Apidog before writing code

The API is in beta, so validate every request shape manually in Apidog first:

Create an Apidog environment with OPENAI_API_KEY, VAULT_ID, and SESSION_ID.
Send Bearer {{OPENAI_API_KEY}} and OpenAI-Beta: agents=v1 on every request.
Send the create-session request without stream. Assert a 2xx status and a non-empty id, then extract id into SESSION_ID.
Open the event stream as an SSE request. Send input from a second request and verify that events arrive.
Save approval and cancellation payloads as reusable requests for each required_actions case.
Chain requests into a test scenario and run it in CI with the Apidog CLI.

The AI agent API testing guide includes assertion patterns for non-deterministic output. Download Apidog to follow along.

FAQ

Is the OpenAI Agents API free?

There is no platform fee, but you pay for model tokens, tool calls, and hosted container time.

Which models work with the Agents API?

The docs’ examples, including every computer-use example, use gpt-6-astra. The pages do not list other supported models, so test yours first.

Does the Agents API support Zero Data Retention?

No. It supports US data residency only and is not ZDR-eligible, even with a self-hosted sandbox.

How is it different from the Agents SDK or the Responses API?

The SDK runs the loop inside your application. The Responses API is the model call that you build a loop around. See the full comparison.

Start with one read-only session

Begin with a read-only session. Add one MCP server, then add computer use behind an approval handler that denies by default.

When ChatGPT should react to events from your own server instead, MCP Events is the matching piece.