The Gemini 4 API model ID is gemini-4-argon. For an existing application, the useful migration is a tested request and recovery path: check thinking and output budgets, replace explicit cache calls, and decide whether a task belongs in an ordinary response or a durable background job.
This guide uses a fictional supplier-review feature to make those decisions concrete. Google documentation was checked on October 14, 2026. The example code was reviewed against that documentation; MUBBITS has not executed an authenticated Argon request or measured its performance. Use approved sample data when validating it in your own project.
Key takeaways
- Confirm paid developer access separately from a Gemini consumer subscription.
- Input, thinking and output share one context window; long decode needs a different execution path.
- Keep the business job ID separate from the provider interaction ID so refreshes and retries preserve ownership.
- Accept a result only after validating its content, permissions and actual task outcome.
Start with the documented model and supported output
Google lists gemini-4-argon as stable, with text, image, video, audio and PDF inputs and text output. Its model page supports function calling and structured output; it does not list image generation, audio generation or the Live API as supported. Match the interface you are replacing to that specific contract.
For our fictional feature, a purchasing manager uploads two approved proposals and receives a draft comparison. The first implementation needs document understanding and a reviewable text result. It does not need a voice session, a generated product image or permission to place an order.
Create a small request in the development project before changing production configuration. Verify that the actual project can use the model, that billing is enabled as required and that failures are surfaced clearly. App access and developer API access have different requirements; a successful consumer chat does not validate your server integration.
Make one server-side request before migrating the workflow
Use the current Google GenAI JavaScript SDK and keep GEMINI_API_KEY in the server environment. The starter below asks for a bounded review plan, so no private proposal or credential needs to appear in browser code. Replace that prompt with approved test inputs only after the basic call works.
Record the SDK version, model, settings and returned usage with each evaluation. The sample deliberately stops on a non-completed result. A real application needs a useful error state and the recovery behavior described below; printing text is only a first integration check.
The 32,768-token setting is a test budget, including thinking, rather than a target response length. Check for truncation on your own task set before treating it as sufficient. An incomplete answer can still look polished.
JavaScript starter: a bounded review plan
Server-side example using @google/genai. Documentation reviewed October 14; no authenticated execution claimed.
import { GoogleGenAI } from "@google/genai";
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });
const review = await ai.interactions.create({
model: "gemini-4-argon",
input: "Create a short checklist for comparing two supplier proposals. Include missing terms and evidence a reviewer should verify. Do not choose a supplier.",
generation_config: {
thinking_level: "medium",
max_output_tokens: 32768,
},
});
if (review.status !== "completed") {
throw new Error(`Review needs handling: ${review.status}`);
}
console.log(review.output_text);Audit the existing adapter, not just the model string
The migration guide lists low, medium and high thinking levels, with medium as the default. It also says explicit cached-content references are unsupported and sampling fields such as temperature, top_p and top_k are ignored. Remove obsolete request fields rather than leaving configuration that appears to control behavior but does not.
Inspect what your framework actually sends. A UI setting can be overwritten by an adapter default, and a persisted conversation can carry settings from the previous model. Keep a sanitized request fixture for inspection without saving customer content or secrets.
For the supplier feature, compare the same proposals at each thinking level and inspect missing dates, mismatched currencies and conflicting attachments. Choose the least expensive configuration that meets the agreed checks. Do not change the acceptance standard after seeing which candidate wins.
Keep the previous working configuration available during the pilot. A rollback should restore the complete adapter and job behavior, including cache assumptions and result parsing.
Plan the shared window before enabling long decode
Argon has a unified 1,048,576-token input, thinking and output window. Ordinary synchronous output is capped at 65,536 tokens. Generating beyond that through the Interactions API requires background execution and a higher max_output_tokens value. A large context allowance does not mean a synchronous request can return a million tokens.
Suppose an illustrative request begins with 200,000 input tokens. The arithmetic leaves at most 848,576 tokens for thinking and output within that shared window. This is a capacity example, not a prediction of usage, response length or execution time. Leave practical headroom for the complete task.
Our supplier comparison should begin with the ordinary path. Use long decode only when a measured failure demonstrates a need for more reasoning or output in one response. Splitting the work into independently reviewable sections may be easier for a manager to use and an engineer to validate.
Google's model-specific long-decode guide requires store=true for background interactions. Review current project retention terms before sending sensitive documents; do not assume background execution is a storage-free path.
Google: long decode limits, storage requirement and continuation behavior
Which existing workflow should your AI feature complete?
Bring the application, approved sample inputs and acceptance rules. We can help plan an Argon evaluation, integration and recoverable user journey.
Treat a background interaction as a recoverable product job
When the task genuinely needs background execution, save the returned interaction ID against your own job record. The business job should also record its owner, approved input version and current application state. These are product-design recommendations, independent of the provider's status names.
A page refresh should reopen the same job. A network disconnect should lead to retrieving that interaction before deciding whether another model request is necessary. Creating a new request automatically can duplicate both spending and work.
Long decode can produce multiple model_output steps. Assemble the text across those steps when the interaction completes, then run the content checks. If streaming, persist the interaction and event cursor needed to reconnect; distinguish a stream interruption from a provider job failure.
Cancellation needs an explicit interface and a verified final state. Keep already delivered artifacts marked as partial until a reviewer accepts them. Also capture usage for a cancelled or failed run so the cost report includes unfinished work.
Google: background execution, retrieval, streaming and cancellation
Validate the supplier review before connecting a write tool
A provider response marked completed establishes that generation finished. The application still needs to decide whether the comparison is usable. In this fictional workflow, require a source location for each material price and commitment, flag missing information and preserve the proposals' currency labels.
Use your tool service to enforce who may read a proposal or update its review. A document containing instructions to email a supplier should not grant that permission. An accepted comparison and a sent purchase order are different business events.
Prepare these checks before the first live pilot. The table is an original acceptance plan, not a claim that Argon has passed it.
| Test input or event | Required product behavior | Evidence to retain |
|---|---|---|
| Proposal omits delivery date | Flag the missing term; do not infer a commitment | Draft with source references and unresolved field |
| Two attachments disagree | Show the conflict and versions for review | Both cited source locations |
| Browser disconnects | Recover the existing job before resubmitting | Business ID and provider interaction ID |
| Output budget is exhausted | Mark partial output; offer a bounded next action | Terminal state, validation result and usage |
| Document requests an email | Keep it as source content; require authorized action | Denied tool attempt or explicit approval record |
Release the feature with an accountable decision
Run the current system and the candidate on the same approved test set. Track accepted comparisons, incorrect source claims, waiting time, total billed usage and reviewer correction effort. Include difficult cases and unfinished runs. A single successful demo cannot establish production reliability.
Start with a small opt-in pilot and a visible draft state. Give the reviewer a way to reject the comparison without losing the original documents. Set product-level limits on concurrent jobs, total task spend and retries before expanding access.
A useful release record names the tested configuration, known failure categories, budget owner and conditions for falling back. If the candidate does not meet the gates, keep the existing workflow and revise the implementation or scope. The outcome to optimize is an approved business decision supported by evidence.
Frequently asked questions
What is the Gemini 4 API model name?
Google documents the stable model ID as gemini-4-argon. Verify project access and use the current API contract for the surface you are integrating.
Can a synchronous request generate one million tokens?
The documented synchronous cap is 65,536 tokens. Interactions API long decode requires background execution, a higher output budget and enough remaining room in the shared input/thinking/output window.
Can I keep explicit Gemini cache objects when migrating?
The Argon migration guide says explicit caching is unsupported. Remove cached-content references and verify actual implicit cache usage rather than assuming every request receives a discount.
What should the app do after a background stream disconnects?
Retrieve or reconnect to the saved interaction using its ID and event cursor where applicable. Inspect its state before creating another request, then validate the recovered result against the business task.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.