Version Changes, Deprecation Notices, and Compatibility Assumptions

The question

What does “Stable” actually promise, and what happens to a production integration when the promise is smaller than the assumption?

gemini-4-argon is listed as a Stable (GA) model, not a Preview, Latest, or Experimental alias. That is a real signal: a Stable model maps to a fixed identifier, which is what allows a team to pin a version, budget a cost, and write a regression test against something that will not silently become a different model next week.

But Stable is a lifecycle state, not a compatibility guarantee. It says the model is generally available. It does not say the parameters will keep meaning what they meant, the call surface will keep its ceilings, or the integration’s assumptions will survive the next model generation in the same family. The gap between “Stable” and “my code still does what I think it does” is where this post lives.

The short answer

Version changes reach a production integration through three signal layers, and each layer fails differently:

The silent layer is the one that produces incidents, because the integration continues to succeed while its assumptions stop holding. The hard layer is the one that gets fixed quickly, because it interrupts the deploy. A mature compatibility practice has to make the silent layer visible, and the only way to do that is to test the assumptions explicitly rather than waiting for a failure.

Argon’s deprecation surface, layer by layer

Argon is a useful case study because it sits at the intersection of all three layers at once.

Silent: sampling parameters. temperature, top_p, and top_k are ignored on gemini-4-argon. The request succeeds. The parameters have no effect. An integration that set temperature=0.2 for “consistent extraction” and temperature=0.8 for “creative drafting” now sends two values that produce no difference, and the code has no way to know. The official guidance goes further: in future model generations, supplying these parameters returns HTTP 400. Today’s silent layer is tomorrow’s hard layer, with no code change in between.

Warning-to-hard: thinkingConfig.thinkingBudget. From Gemini 3.x, thinkingBudget is the parameter teams are most likely to carry forward. Argon does not support it. Google’s migration guide describes it as deprecated with a warning, but observed migration reports show hard 400 errors in practice — the error message reads “Thinking budget is not supported for this model. Use thinking level instead”. The signal layer is not stable: it may be a warning, it may be an error, and the integration cannot assume either. The only safe treatment is to remove the parameter entirely before migrating, not to rely on a warning.

Hard: thinking_level="MINIMAL". Argon supports LOW, MEDIUM (default), and HIGH. Setting thinking_level="MINIMAL" or thinking_budget returns an HTTP 400 validation error. A configuration carried forward from a model whose default thinking level was minimal will fail on the first request, which is the good case — the failure is immediate and attributable.

Hard: explicit context caching. Argon supports implicit caching only, with a 6,144-token minimum, and does not support explicit context caching. A cachedContents creation call against Argon returns 400 (“Explicit caching is not supported for models/gemini-4-argon”). The failure is hard, but the migration cost is real: a team that built a cache lifecycle around explicit cache objects has to redesign that layer, not just rename a parameter.

The pattern is that Argon’s deprecation surface is mixed-layer, and the layers do not map cleanly onto “old parameter” vs. “new parameter.” temperature is silent. thinkingBudget is warning-or-hard depending on the path. MINIMAL is hard. Explicit caching is hard. A migration plan that assumes “deprecated means it will warn” will misclassify at least two of these.

Stable is not permanent

The deprecation page lists shutdown dates for Stable and Preview models. As of this writing, gemini-4-argon does not appear in the Gemini 4 section with an announced shutdown date. That is not a guarantee of permanence. It means the clock has not been started publicly.

The general policy background is worth stating precisely, because it is easy to over-read. Google’s stated goal for a Stable version is at least 12 months of availability before shutdown, but on the Agent Platform (formerly Vertex AI), some Stable models are available for a shorter period — possibly as early as 45 days after a replacement model is released. That is a wide range, and the variance is not something an integration can control.

The practical translation: a Stable model ID is a pin, not a promise of indefinite compatibility. It protects the integration from alias drift — the model behind the ID will not silently become a different model — but it does not protect the integration from parameter semantics changing, from call-surface ceilings shifting, or from the model being shut down on a schedule the integration has not read.

The related trap is the alias. A team that pins gemini-4-argon is safer than a team that pins gemini-4 or a “latest” shorthand, because the shorthand resolves through a family template and can move. But pinning the ID is necessary and not sufficient. The pin protects identity; it does not protect assumptions.

The compatibility assumptions that break silently

The hard failures are easy to enumerate. The silent failures are the ones that require a deliberate test. Here are the ones Argon’s migration surface makes most likely:

1. max_output_tokens means “answer length.” In practice on earlier models, many integrations set max_output_tokens to 2,048 or 4,096 as a safeguard against long output. On Argon, thinking tokens are counted directly against max_output_tokens, and a request with a modest ceiling and a complex prompt can burn the entire budget on thinking before emitting a visible answer. The observed failure is finish_reason: "MAX_TOKENS" with an empty or truncated response.text. The 200 is real. The output is not usable.

The semantic shift is the point: max_output_tokens is no longer a length control. It is a total emergency brake covering thinking plus output. An integration that treated it as a length control will succeed at the HTTP layer and fail at the task layer.

2. The per-request ceiling is the model ceiling. Argon’s context window is 1,048,576 tokens shared across input, thinking, and output. But the per-request output ceiling depends on the call surface: 32,768 tokens for non-streaming direct HTTP, 65,536 for streaming and for synchronous Interactions API calls, with long decode extending to 1,048,576 via continuation. A migration that changed the model ID but kept a non-streaming direct HTTP path has silently halved its output ceiling relative to a streaming path. The model supports 1M tokens; the call path does not.

3. A retry after a hard failure is safe. A 400 on thinkingBudget or on MINIMAL is deterministic. A retry wrapper that classifies “4xx except 401” as retryable will burn quota on a request that will never succeed. This is the retry-tier problem in version-change form: the deprecation creates a new deterministic failure, and the retry policy was not designed for it.

4. The warning is the signal. The thinkingBudget case shows that the same deprecation can surface as a warning on one path and a 400 on another. An integration that monitors warnings as the deprecation signal will miss the hard failures, and an integration that only handles hard failures will miss the silent parameter changes. Both signals need to be treated as evidence, and neither is a substitute for testing the assumption directly.

The compatibility test that makes the silent layer visible

The only reliable way to catch a silent change is a test that would fail if the assumption stopped holding, run against the pinned model ID on a schedule.

A minimal compatibility regression suite for an Argon integration:

The suite is deliberately small. It is not a capability test; it is an assumption test. Its job is to fail when a compatibility assumption breaks, at the layer where the break is still cheap to fix. A capability regression suite answers “is the model still good at the task.” This suite answers “does the integration still mean what it meant.”

The thinking-budget rejection row is the most instructive. The test passes whether the API returns 400 or an explicit warning, because the integration’s assumption is “I will know if this parameter is not working.” The test fails when the parameter is silently accepted. That is the signal the team actually needs.

The record that makes a version change auditable

A version change is not a date. It is a set of changed assumptions, and the record has to capture them per integration, not per model.

json

{
  "integration_id": "extraction-worker",
  "model_id_pinned": "gemini-4-argon",
  "model_alias_used": false,
  "compatibility_suite_version": "1.2",
  "last_run": "2026-10-20T14:00:00-05:00",
  "assumptions_checked": [
    "sampling_parameters_have_effect",
    "thinking_budget_rejected",
    "minimal_thinking_rejected",
    "non_streaming_ceiling_32768",
    "explicit_cache_rejected",
    "alias_resolution_stable"
  ],
  "failures": [],
  "warnings_observed": ["temperature ignored (deprecation notice)"],
  "deprecation_notices_reviewed": ["sampling parameters deprecated, future 400"],
  "shutdown_date_checked": "2026-10-20",
  "shutdown_date_announced": false,
  "migration_deadline": null,
  "evidence_level": "runtime"
}

Three fields do the work that a deploy log cannot. assumptions_checked names what the suite is asserting, so a new assumption is added deliberately rather than discovered by incident. warnings_observed records the silent-layer signal, which is invisible in a pass/fail column. shutdown_date_announced separates “no date yet” from “date not checked” — a distinction that matters when a replacement model is released and the 45-day clock becomes possible.

Failure cases observed

The silent temperature. A team migrated a classification pipeline from a 3.x model to gemini-4-argon, keeping temperature=0.1 for “deterministic” output. The pipeline continued to succeed. The output variability did not match the setting — the model was ignoring it. The “determinism” had never been real on Argon, and the team discovered it only when a downstream consistency check started flagging variance that the configuration said should not exist.

The carried-forward thinkingBudget. A migration that changed the model ID but kept thinkingConfig.thinkingBudget received intermittent 400 errors. The migration guide described the parameter as deprecated with a warning; the observed behavior included hard errors. The retry wrapper treated the 400 as transient, tripled quota consumption, and delayed the fix by a release cycle.

The 32K surprise. A non-streaming direct HTTP integration that had run at a 65,536 output ceiling on a 3.x model kept the same ceiling after migration. The first request that needed more than 32,768 output tokens returned a 400 or an incomplete response. The model’s headline 1M window was correct; the call path’s ceiling was not.

The empty 200. A max_output_tokens=4096 safeguard, carried forward unchanged, produced finish_reason: "MAX_TOKENS" with an empty response.text on complex prompts — the thinking budget consumed the entire allowance before the answer began. The status was 200. The output was empty. The validation layer, if it existed, was the only place the failure could surface.

The explicit cache 400. A cache-warming step that created explicit cache objects on the previous model began returning 400 on Argon. The failure was hard and attributable, but the fix was a redesign of the cache lifecycle, not a parameter rename. The migration estimate had assumed “one line.”

None of these are model-quality failures. All of them are compatibility-assumption failures, and each was invisible until a test or an incident made it visible.

What this post does not prove

It does not prove that Argon’s deprecation surface is exhaustive. The parameters and surfaces listed are the ones exercised or documented at test time; a later model generation may add or remove a layer.

It does not prove that a shutdown date will be announced on a particular schedule. The 12-month goal and the 45-day Agent Platform possibility are policy statements with variance, not a schedule an integration can plan against without checking the deprecation page.

It does not prove that a compatibility suite catches every silent change. It catches the assumptions it names. An assumption not in the suite is an assumption that will be discovered by incident, which is why the assumptions_checked field exists — the list is the coverage.

It does not resolve the hard-vs-warning ambiguity for thinkingBudget. The observed behavior includes both, and the only safe integration posture is to remove the parameter rather than classify the signal.

What it does establish is the structure of the version-change problem: Stable pins identity, not assumptions; silent changes succeed; warnings and hard errors are different layers; and the only way to catch the silent layer is an assumption test that would fail if the assumption stopped holding. That test is the compatibility practice. Without it, the integration is relying on a deploy succeeding as evidence that nothing changed — and a deploy succeeding is evidence of exactly that.

A working demo is evidence. It is not a production system. A Stable model ID is evidence of availability. It is not evidence that the integration’s assumptions survived the version it points at.

Reproduction notes

• Model: gemini-4-argon

• Access: paid Gemini API tier

• Test date: 2026-10-20

• SDK: google-genai>=2.30.1 (Python)

• Call surfaces exercised: interactions.create (streaming and non-streaming); models.generate_content non-streaming for the ceiling and thinkingBudget cases

• Observed parameter behavior: temperature, top_p, top_k ignored; future generations may return 400 for deprecated sampling parameters; thinking_budget and thinking_level="MINIMAL" return HTTP 400; observed thinkingBudget behavior includes both warning and hard 400 depending on path

• Observed caching behavior: implicit caching only, 6,144-token minimum, durable by default; explicit context caching not supported, cachedContents returns 400

• Observed ceilings: 1,048,576 shared context window; 32,768 tokens per non-streaming direct HTTP request; 65,536 streaming and synchronous Interactions; long decode via continuation_token to 1,048,576

• Stable status referenced: gemini-4-argon is a Stable (GA) model, not a Preview/Latest/Experimental alias

• Lifecycle policy referenced: 12-month goal for Stable availability, with Agent Platform variance as early as 45 days after a replacement model

• Shutdown date status: not announced on the deprecation page at test time

• Pricing snapshot: introductory $2/1M input, $10/1M output through 2026-11-30; $4/$20 thereafter

• Failure samples retained: silent temperature; thinkingBudget warning-vs-400; 32K non-streaming ceiling; empty 200 at 4,096 max_output_tokens; explicit cache 400

The next post in this series turns to developer workflow: building a human-review step that is more than a checkbox — because a compatibility suite catches what the team anticipated, and human review is the only layer that catches what it did not.

For AI tool features, rules and availability, refer to their official sites.