Skip to main content

Model Routing

You can give the platform several candidate models instead of one, and constrain which of them may be used. Candidates are validated and filtered before a generation run starts, so an impossible request fails immediately in the HTTP response rather than asynchronously, minutes later.

Set models for a fallback chain, and model_routing_filter to require capabilities — a minimum context window, image input, a cost ceiling. Candidates that fail are dropped; generation proceeds with whatever survives. If nothing survives, you get an error up front.

Setting no filter is a valid choice and changes nothing about how a thread behaves.

Allowed models​

Read this first: the platform accepts a curated allowlist, not the full OpenRouter catalog. Everything else on this page filters within this set.

Model IDProvider
google/gemini-3.6-flashGoogle
google/gemini-3.5-flashGoogle
google/gemini-3.1-flash-liteGoogle
google/gemini-3.1-pro-previewGoogle
google/gemini-3-flash-previewGoogle
anthropic/claude-sonnet-5Anthropic
anthropic/claude-sonnet-4.6Anthropic
deepseek/deepseek-v4-flashDeepSeek
deepseek/deepseek-v4-proDeepSeek
openrouter/autoRouter — picks a model for you

Requesting anything else — in model or any entry of models — fails immediately:

{
  "code": "MODEL_INVALID",
  "message": "model \"openai/gpt-5\" is not allowed",
  "reason": "MODEL_NOT_ALLOWED"
}

OpenRouter variant suffixes are fine — :nitro, :free, and :floor are stripped before the check, so google/gemini-3.6-flash:nitro is allowed. Leaving model unset is also fine; you get the platform default.

The same allowlist applies when storing a per-user default via update-generation-config.

Where to next​

PageCovers
FilteringWhere to set a filter, every field, and how they combine
Error HandlingThe synchronous error shape and each error code
ExamplesLong-context, cost-capped, and structured-output recipes