Grok 4.6 Is GA on Google Cloud. The Route Is the Product

Your production agent hits a 429 on Google Cloud's US Grok 4.6 endpoint. The tempting fallback is global. But Google says the two routes draw from one Grok base-model quota, so the swap does not create headroom. Google's residency guidance gives the global endpoint no processing-location guarantee. One fallback can therefore fail twice: it can preserve the capacity bottleneck while discarding the location boundary that made the request acceptable.

That is the practical meaning of Google Cloud's September 18, 2026 change. Grok 4.6 is now generally available for production on global and US multi-region endpoints in Gemini Enterprise Agent Platform. Grok was already there; what changed is the route's production status.

xAI introduced the underlying model on August 12, and Google listed it in Preview on August 21. AWS and Microsoft had also announced Grok 4.6 distribution before this GA. The reviewed September material identifies no new checkpoint, benchmark uplift, or first-ever Google access.

GA lowers a procurement barrier for teams already using Google IAM, billing, and agent infrastructure. It does not make Grok interchangeable with Gemini, Claude, or the direct xAI API. The Google route still has fixed quota, a shared endpoint pool, a whole-request price jump above 200K input tokens, stateless Responses behavior, and partner-model terms that need separate review.

RohitAI already covered Grok 4.6's August launch, context economics, and coding-agent claims. The September question is operational: can this exact route satisfy the workload, failure, data, and contract requirements? The model name is no longer enough. The route contract is the product.

From model launch to production route

The cleanest way to understand the announcement is as a sequence of different events, not one month-long launch.

This distinction matters for both editorial accuracy and engineering. A model launch asks whether a new checkpoint changes the capability frontier. A route GA asks whether a provider-specific serving path is ready to enter a production risk register. Google's September release note establishes the second event; it supplies no evidence of a new checkpoint or capability change.

A model ID is not a deployment contract. If your router records only “grok-4.6,” it has thrown away the fields most likely to explain an outage, bill, policy violation, or migration bug.

The Google route contract, in one table

The current Google model card lists text and image input, text output, reasoning, function calling, and structured output. Those are useful capabilities. The less glamorous rows determine whether a fleet can actually use them.

“Standard PayGo unsupported” is easy to misread. It describes a capacity mode, not the absence of token billing. Google publishes input, cache-hit, and output prices for Grok 4.6. You pay for usage while operating inside the route's fixed-quota design.

Two endpoint names, one capacity pool

Google publishes the same headline quota figures beside global and US, but its xAI quota documentation says those endpoints draw from one underlying quota per base model. Account limits can differ, so the console and quota APIs—not the documentation table—must drive your scheduler.

Consider a simple, illustrative agent turn using 20K input tokens and 2K output tokens. Ignoring cache treatment, burst rules, latency, retries, and other traffic, the published limits imply this quota-only ceiling:

turns_per_minute = min(13 QPM, 188000 / 20000 input, 16000 / 2000 output)
                 = min(13, 9.4, 8)
                 = 8 turns/minute

ten_turn_tasks_per_minute <= 8 / 10 = 0.8

That is arithmetic, not a load test or service guarantee. It shows why the 524K context headline cannot double as a concurrency plan. Output TPM becomes the bottleneck in this example before QPM does. A different prompt shape produces a different answer.

The non-obvious failure mode is policy-damaging failover. If a US-constrained workflow receives a 429, retrying on global does not unlock new base-model quota, but it can discard the location constraint that made the route acceptable. A valid fallback needs separately verified capacity and an equally acceptable jurisdiction—not just another hostname.

Inspect real project quotas before promising volume. Use one shared limiter across both Google Grok endpoints, queue bounded work, add jittered retries, and fail closed when a route would violate the workload's region policy. If sustained capacity is mandatory, obtain a quota path or qualify a genuinely independent route before launch.

Above 200K, Grok reprices the whole request

The current Google pricing page lists Grok 4.6 at $2 per million input tokens, $0.50 per million cache-hit tokens, and $6 per million output tokens through 200K input. Above 200K input, the rates become $4, $1, and $12. The higher tier applies to all tokens in the request, not only the tokens beyond the line. Google's exact boundary is greater than 200K, so exactly 200K remains in the lower column. That is route-specific: our August direct-API analysis used xAI's at-or-above-200K wording; do not carry that boundary into Google's tariff.

That creates a routing discontinuity. At 199K uncached input plus 10K output, the tariff calculation is $0.458. At 201K plus the same output, it is $0.924. Two thousand extra input tokens can nearly double the bill because the entire request moves tiers.

These are tariff-only examples using Google's current global rates: Sonnet 5 at $2 input and $10 output per million, and Gemini 3.8 Flash's promotional $0.75 input and $3.75 output through December 31, 2026. Gemini's scheduled January 1, 2027 rates are $1.50 input and $7.50 output. The examples include all listed output, including reasoning where billed as output, and omit caching, tools, retries, negotiated prices, and any difference in accepted-result quality.

The insight is not that one model is universally cheaper. It is that prompt length can reorder the tariff ranking before quality enters the comparison. A router that chooses on a model's base price can make the wrong decision when summarization, retrieval stuffing, or an agent transcript pushes input across the threshold.

Measure cost per accepted outcome on your workload. Record uncached input, cache hits, all billed output, retries, tool failures, and human review. Then apply the tier to the trace as billed. “Dollars per million” is a component price, not a production efficiency metric.

OpenAI compatibility stops at the request shape

Google documents Grok through its Responses API and OpenAI-compatible calling surface, including streaming. That can reduce client rewrites. It does not establish parity with xAI's direct API, every OpenAI Responses feature, or another provider's tool loop.

State is application-owned today—and the default is planned to change

For Google-hosted Grok today, store=true and previous_response_id are unsupported, and store defaults to false. Google also documents a future stateful release in which the default is planned to become true, without announcing a date.

That makes an omitted boolean a migration risk. If stateless handling is part of your approved design, send store:false explicitly and keep an acceptance test for it. Maintain your own authorized conversation state, idempotency keys, and side-effect ledger. When stateful support ships, treat the default change like an API migration even if the model name stays identical.

Reasoning effort needs a route-specific test

xAI's August Google announcement advertises low, medium, high, and xhigh reasoning levels for Grok 4.6. Google's current generic Grok reasoning guide says reasoning_effort is unsupported and illustrates an older Grok model. Those first-party documents conflict.

The honest answer is that the Google 4.6 behavior remains unresolved from documentation alone. A request might reject, ignore, translate, or honor the field depending on the live endpoint and version. Send model-specific canaries for every effort value, record the response and usage, and seek written clarification before making the knob part of an SLO or cost policy.

Keep other direct-provider claims separate too. xAI documents 500K context and direct tools such as web search, X search, and code execution. Google lists 524,288 context for its route, but the reviewed sources do not establish that every xAI-hosted tool or state feature transfers. Protocol familiarity is an integration convenience, not a capability warranty.

One cloud account, multiple legal boundaries

The managed route has meaningful enterprise advantages. Google's partner-model guide says prompts and responses in this managed API are not shared with third parties and that Customer Data is processed under its Cloud Data Processing Addendum. Google's public service terms also say it will not train or fine-tune models on Customer Data without prior permission or instruction.

Those statements must stay in scope. They describe Google's managed service, not the Grok consumer app, a direct xAI call, your application logs, an external search tool, or every downstream store. Google separately documents prompt logging for Partner and Open Models MaaS as off by default. Prompt logging, API response storage, application observability, caching, and model training are different controls; one “zero retention” label cannot safely collapse them.

There is also a contract boundary. Google flags xAI models as Separate Offerings. Its service terms assign separate conditions to those offerings and exclude them from Google's stated indemnification obligations. A shared bill and IAM surface do not make Grok legally identical to Gemini. Review the exact terms accepted in your account; public documentation is not a substitute for a negotiated contract.

Enablement reflects the same separation. An administrator needs procurement-entitlement permissions and organization policy that permits the partner model, while the runtime identity needs inference permission. Keep those roles apart. The identity that can call an approved model should not automatically be able to add another paid model to the organization.

A second non-obvious result follows: model choice gets easier while cloud exit can get harder. Evaluating Grok, Gemini, and Claude behind one Google control plane reduces procurement and integration friction. It also moves the application toward Google-specific identity, quota, endpoint, state, and governance semantics. Model plurality is not infrastructure independence.

A useful router is a policy engine, not a leaderboard with network access. It must know which route may process the data, which pool has capacity, which tariff applies, what state is retained, and which fallback remains contractually acceptable.

A production acceptance test for this exact route

GA is a reason to run a serious canary, not to flip a model alias across the fleet. Use representative work, the same tools and harness, and an acceptance rubric that measures operations as well as answer quality.

1. Write a route manifest. Version the dependency beyond its model ID. At minimum record:

   provider, model version, API surface, endpoint, and jurisdiction; actual account QPM, input TPM, output TPM, and shared-pool identity; capacity mode, price tier, cache policy, and long-context threshold; state flag, effort support, structured-output behavior, tools, timeout, and fallback policy; terms version, data classification, owner, and rollback route.

2. Build a 60-task canary. Use 15 short stateless tasks, 15 structured-output or function-call tasks, 15 multi-turn agent traces, and 15 long-context tasks straddling the 200K billing threshold. Include known hard failures, not only happy paths.

3. Probe the disputed semantics. Try each documented reasoning-effort value, an invalid value, store:false, store:true, previous_response_id, streaming interruption, schema violations, tool errors, and retries. Record whether each field is honored, rejected, or apparently ignored.

4. Load the shared limiter. Exercise mixed global and US traffic against one rate-control policy. Observe 429s, burst behavior, queue age, and retry amplification. Do not infer a second pool from endpoint labels.

5. Test region failure closed. For a US-constrained dataset, force the preferred route unavailable. The system should stop or use a separately approved US route; it should not silently switch to global. Trace retrieval, tool calls, logs, artifacts, and storage as well as inference.

6. Reconcile traces to bills. For requests below and above 200K, compare uncached input, cache hits, reasoning/output tokens, retries, and the applied tier with the invoice or usage export. Repeat after any pricing-page change.

7. Compare accepted outcomes. Run the same harness against direct Grok and relevant Google-hosted alternatives. Measure accepted-result rate, end-to-end p50/p95 latency, 429s, tool failures, schema validity, human review minutes, retries, and dollars per accepted result.

Do not call this a matched model evaluation if providers receive different prompts, tools, timeouts, or retry budgets. And do not use an August benchmark as evidence that the September Google route has the same latency, reliability, or cost behavior. No reviewed source supplies a matched production test of the new GA route.

Where Grok 4.6 on Google fits first

This suggests a practical initial role: a bounded alternative or escalation route for Google-standardized teams, not an automatic default for every agent turn. That is our inference from the published capacity and feature contract, not a claim about measured customer adoption.

The model is familiar. The production object is new.

Google's September 18 GA record does not establish a more intelligent Grok 4.6 checkpoint. It makes the existing model easier for a Google Cloud customer to place inside a production procurement and agent stack. That is meaningful—but only if the route survives acceptance testing.

The teams that benefit will resist the convenience of a model dropdown. They will version the route, enforce the shared quota, price the entire trace, make state explicit, fail closed on jurisdiction, and review the separate terms. They will compare accepted outcomes instead of launch scores.

The strategic shift is simple: frontier-model competition is moving into cloud catalogs, but the catalog entry is not a commodity. The route—its capacity, defaults, geography, and contract—is now part of the product.