Grok 4.5 on OpenRouter? Availability Tracking Guide
Check whether Grok 4.5 is on OpenRouter safely: provider source, pricing sync, context, tool support, caching, and fallback rules.
It’s Dora. I checked Grok 4.5 on OpenRouter because this is the kind of launch-window confusion that quietly breaks configs.
One person sees a rumor. Another person writes a model slug. Then someone routes traffic before the model actually exists.
If you use OpenRouter or another LLM gateway, this is the boring part that matters. As of July 6, 2026, I found **Grok 4.3 on OpenRouter**. I did not find a citable Grok 4.5 model page. This note records what is visible, what is not visible, and what I would verify before putting any Grok 4.5 API route into production. That’s all I can confirm.
Current OpenRouter Availability Status

What is visible for Grok 4.3 today
OpenRouter currently shows x-ai/grok-4.3 with text and image input, text output, a 1M context window, and visible pricing. The same page exposes the operational tabs I care about: Providers, Effective Pricing, Performance, Uptime, Benchmarks, Apps, and Activity.
That matters more than a screenshot from social media. It tells me what can actually be called, routed, priced, and monitored.
xAI’s official models page also lists grok-4.3, with 1M context and token pricing. For direct provider evidence, that page comes before any gateway listing.
Why not to assume Grok 4.5 availability
I did not find a citable Grok 4.5 OpenRouter page during this check. I would not ship against x-ai/grok-4.5 until OpenRouter or xAI exposes the actual slug.
Reported parameter counts, V9 architecture notes, Cursor-related training claims, or private-beta chatter are background. They do not prove OpenRouter availability. They do not prove xAI API support. I don’t know. Better than making something up.
What to Verify When a Model Appears

Provider, model slug, pricing, context, modalities
When a Grok 4.5 page appears, record the exact model slug, provider slug, canonical ID, release date, context length, input/output modalities, max output behavior, and pricing. Then check the machine-readable OpenRouter models API, because UI pages and API metadata can drift for a short window.
Do not round this off to “Grok 4.5 is on OpenRouter.” The useful statement is narrower: “OpenRouter lists this exact slug, with these providers, these prices, and these supported parameters, checked on this date.”
Tool support, caching, rate limits, fallback behavior
Tool support is where neat launch notes get messy. Verify function tools, structured outputs, reasoning controls, streaming, prompt caching, and unsupported parameters.
Then compare that against xAI’s rate limits page. Gateway availability does not tell you your direct API tier, TPM, RPS, region behavior, or account eligibility. If tool calls matter, test them. A model can answer text well and still break your function-call path.
How OpenRouter Changes the Adoption Decision
Fast testing vs direct provider control
OpenRouter is useful for fast smoke tests. One gateway, many models, less client churn. The Grok 4.3 page even gives a quick-start path for an OpenAI-compatible API shape.
Direct xAI control is different. It gives you provider-owned docs, account-specific limits, billing visibility, and a cleaner support path. I would test through a gateway first when speed matters. I would move direct when latency, procurement, data policy, or exact model behavior matters.
Routing, retries, monitoring, and effective pricing
OpenRouter changes the failure model. Its provider routing docs show provider ordering, fallback controls, parameter requirements, and data-policy routing.
That is useful. It can also hide model-specific failures.
If Grok 4.5 returns bad JSON and your fallback silently routes to another model, your app may show “success” while your Grok-specific eval failed. During qualification, disable fallback or log the native model, provider, finish reason, cost, cache status, and error class. Good enough is not good enough here.
Safe Tracking Workflow
Official xAI docs first, OpenRouter page second
My order is boring:
Check xAI models and release notes first. Check the xAI console if you have access. Then check the OpenRouter model page. Then check the OpenRouter API metadata.
OpenRouter availability means gateway access. It does not automatically mean xAI direct API availability. The two can overlap. They are not the same evidence.
Changelog and evidence screenshot checklist
For the launch-day file, capture four screenshots: xAI model/pricing/rate-limit rows, OpenRouter model header with slug, OpenRouter provider/pricing/performance/uptime tabs, and one successful test response showing the actual routed model and provider.
If Grok 4.5 appears, update the article that day with provider, slug, pricing, context, modalities, tool support, caching, rate limits, and fallback behavior. No old draft should survive that event unchanged.
FAQ

Is Grok 4.5 listed on OpenRouter yet?
As of July 6, 2026, I did not find a citable Grok 4.5 OpenRouter model page. Grok 4.3 is visible.
Does OpenRouter availability mean xAI direct API support?
No. It means the gateway lists a route. Direct xAI support needs xAI docs, console visibility, or release notes.
What should I verify before routing traffic?
Verify slug, provider, price, context, modalities, tools, caching, rate limits, fallback rules, and monitoring fields.
Can OpenRouter fallback hide model-specific failures?
Yes. Fallback can keep the request alive while masking which model actually handled it. Log the native model and provider during testing.
Conclusion
The safe answer is simple: Grok 4.3 is visible; Grok 4.5 is not confirmed from the sources I checked. For builders, the job is not to predict the launch. The job is to keep a clean evidence trail so the first production call does not depend on a rumor wearing a model slug.
Previous posts:





