Gemini Decision vs Gemini Decision 1: One Is a Name, One Is a Model ID
- GoogleNEWGoogle: Gemini 4 Carbon2026-11-10$2.00 / $10.00 per 1M tokens · 226 tok/s
- AnthropicNEWAnthropic: Claude Fable 5.22026-11-09$8.00 / $40.00 per 1M tokens · 101 tok/s
- orcaNEWOrca: OrcaC2 1.02026-11-0717 tok/s
- OrcaNEWOrcaCyber: GLM 5.3 Abliterated / Uncensored2026-11-04$3.00 / $5.00 per 1M tokens · 82 tok/s
- OrcaNEWOrcaCyber: Hy4 Abliterated / Uncensored2026-11-04$0.80 / $1.60 per 1M tokens · 182 tok/s
- OrcaNEWOrcaCyber: Kimi K3.1 Pro Abliterated / Uncensored2026-11-04$4.00 / $20.00 per 1M tokens · 46 tok/s
- OrcaOrcaCyber: MiniMax M3.1 Flash Abliterated / Uncensored2026-10-29$0.80 / $1.60 per 1M tokens · 139 tok/s
- OrcaOrcaCyber: GLM 5.3 Flash Abliterated / Uncensored2026-10-27$0.80 / $1.60 per 1M tokens · 63 tok/s
- OrcaOrcaCyber: Qwen3.8 Flash Next Abliterated / Uncensored2026-10-26$0.80 / $1.60 per 1M tokens · 96 tok/s
- OrcaOrcaCyber: MiMo V2.6 Flash Abliterated / Uncensored2026-10-26$0.80 / $1.60 per 1M tokens · 42 tok/s
- MoonshotMoonshotAI: Kimi K3.1 Pro2026-10-2447Intelligence
- OrcaOrcaCyber: DeepSeek V4.1 Flash Abliterated / Uncensored2026-10-23$0.80 / $1.60 per 1M tokens · 182 tok/s
- minimaxMiniMax: M3.1 Flash2026-10-1929Intelligence
- OrcaOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 per 1M tokens · 138 tok/s
- deepseekDeepSeek: DeepSeek V4.1 Flash 10172026-10-1733Intelligence
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-10-1740Intelligence
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 per 1M tokens · 111 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2955Intelligence
- anthropicAnthropic: Claude Sonnet 5.52026-09-2855Intelligence
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 per 1M tokens · 319 tok/s
Search for Gemini Decision and you will find launch coverage, a leaderboard entry, a pricing row and an API reference, all using slightly different words for the same thing. Search for Gemini Decision 1 and you will find the model id that actually works. The two strings differ by a single character and behave completely differently in code: one is what people call the product, and the other is the only value that POST /v1beta/decisions will accept. If you have spent an afternoon on a 404 wondering why a model that plainly exists cannot be found, this is the article that would have saved it.
The confusion is not anyone's mistake in particular. Google shipped a model, an endpoint and a family name in the same release on 11 November 2026, and the natural way to write about all three is to shorten them. The shortening works in prose and fails in a request body, and the gap between those two facts is where most of the support tickets in this category will come from over the next month.
What the two names resolve to
Start with the mapping, because everything else follows from it.
• Gemini Decision — a product name. It refers to the decision-model line, and in Google's own documentation it appears as the family label in prose, in the model card heading, and in sentences like "available with Gemini Decision only". It is not a model id, there is no alias behind it, and passing it as model returns an unknown-model error rather than falling back to the newest member of the family.
• Gemini Decision 1 — the model, and the id gemini-decision-1. This is the value that works. It is the only model the Decisions API serves, and the documentation says so explicitly: the endpoint is available with Gemini Decision 1 only.
Two names, one model, and no alias between them. That last part is the unusual bit. Most Google model families offer a moving alias and a pinned id — a -latest form for prototypes and a dated or numbered form for production. This one offers only the pinned form, so any code path built on the assumption that families have a floating head will fail here rather than silently tracking a new version.
Where the second name keeps appearing
The reason the ambiguity has legs is that three separate systems describe this model and none of them share a naming convention.
The pricing page lists it under the model's own name, alongside a rate and a note that output is not applicable. The API reference describes the endpoint and names the model in the availability sentence rather than in a model table. The independent leaderboard that benchmarks it uses the readable name in its row and its chart. None of these is wrong, and none of them is a model id, so copying from any of them into a request body produces the same failure.
There is a fourth source of variation that will matter more as time passes: other people's writing. Launch coverage, tutorials and forum answers all shorten the name, and some of them shorten it to something that looks like an id — lowercase, hyphenated, plausible. The fix is not to trust any of them. Ask the endpoint.
How to check what a given key can actually call
Before writing a request, list the models the key is entitled to. The standard list-models call on the Generative Language API returns the models available to your project with their ids, and running it once settles the question permanently for that key.
If gemini-decision-1 appears, you have access, and that exact string is what goes in the request. If it does not, the problem is entitlement or region rather than spelling, and no amount of renaming will help. What you will not find in that list is an entry called gemini-decision, because there is no such model.
The second check is on the response. A successful decision response identifies the model that served it, so a pipeline that logs the model field alongside its own request id can answer "which model produced this answer" months later without re-reading configuration. That sounds like housekeeping until the first time someone asks why a decision changed and the honest answer is that an alias moved.
The three mistakes this ambiguity actually causes
• The unknown-model 404. The obvious one. gemini-decision in the request body returns an error that reads like a permissions problem and is not. If the error mentions the model rather than the project, check the string before you check the billing account.
• The silent alias assumption. Harder to spot. A team that has internalised -latest conventions writes a config with a family name and a resolution step, and the resolution step quietly returns the literal family name when no alias exists. The failure then appears at the first real request rather than at deploy, which is the worst possible time for it.
• The wrong-endpoint assumption. Subtler still, because the model exists and the name is right: gemini-decision-1 sent to an ordinary generate-content endpoint still fails. The model is not callable that way at all. It is a probabilities-only target on the decisions endpoint, and a request that asks it for prose is asking for something it does not produce. Any client library that defaults to chat completions will need an explicit path.
What this says about the model, not just its name
The naming is a symptom of the real design decision, which is that this is not a chat model with a different output format. A chat model returns text, so its id can be swapped freely between providers, proxies and gateways that all speak the same schema. A model that returns calibrated probabilities over your own typed questions has no such common schema, and the id is bound to one endpoint with one request shape.
That is why the family has no floating alias and no second member yet: there is nothing to be compatible with. It also explains why the model cannot simply be added to a general-purpose router. OrcaRouter does not carry gemini-decision-1, because a probabilities-only endpoint is not a chat-completions target, and putting it behind a key that speaks that schema would be a promise the routing layer cannot keep. What we do carry in decision space is TypeSafe's typesafe/jev-1.14, a decision model that is callable through the same interface as everything else on the catalogue.
The part of a decision pipeline the router does serve is the drafting half — the generative call that produces the candidate answer or the rubric that the scorer then evaluates. That call runs across more than 200 models on one endpoint with provider list price passed through at 0% markup, and it is the call where swapping vendors is a config change rather than a rewrite. The scoring call, by contrast, is bound to one endpoint by design, and the honest architecture treats it as a fixed dependency rather than something to route around.
If you are choosing between the two strings on a form
There is a version of this question that is not about identifiers at all, and it is worth answering directly because the phrasing invites it: someone comparing "Gemini Decision" with "Gemini Decision 1" may believe they are looking at two products, an older one and a newer one, and want to know which to adopt. There is only one. Nothing called Gemini Decision shipped before Gemini Decision 1, and the shorter name is the family label for a family that currently has a single member.
The practical consequence is that any comparison table, review or benchmark you find that lists both as separate entries is describing the same model twice. Two rows, one model, one price. If the two rows disagree on a number, one of them is out of date rather than measuring something different.
Bottom line
Use gemini-decision-1 in every request body, endpoint path and config value, and use "Gemini Decision" only where a human reads it. There is no alias to fall back on, no second model hiding behind the shorter name, and no chat-completions path to the longer one. The cost of getting this wrong is small — one 404, one confused afternoon — but the cost of assuming an alias exists is larger, because that mistake survives review and fails in production. Pin the id, log the model the response names, and treat the family name as prose.
