Gemini Decision vs Gemini Decision 1: Den ena är ett namn, den andra är ett modell-ID

Sök på Gemini Decision och du hittar lanseringsbevakning, en post på en resultattavla, en prisrad och en API-referens, alla med lite olika ord för samma sak. Sök på Gemini Decision 1 och du hittar det modell-id som faktiskt fungerar. De två strängarna skiljer sig med ett enda tecken och beter sig helt olika i kod: den ena är vad folk kallar produkten, och den andra är det enda värde som POST /v1beta/decisions accepterar. Om du har lagt en hel eftermiddag på ett 404-fel och undrat varför en modell som uppenbart finns inte går att hitta, är det här artikeln som hade räddat dig.

The confusion is not anyone's mistake in particular. G​oogle 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.

Vad de två namnen löses upp till

Börja med mappningen, eftersom allt annat följer av den.

• Gemini Decision — a product name. It refers to the decision-model line, and in G​oogle's own documentation it appears as the family label in prose, in the model card heading, and in sentences like "available with G​emini 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 G​emini Decision 1 only.

Two names, one model, and no alias between them. That last part is the unusual bit. Most G​oogle 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.

Där det andra namnet fortsätter att dyka upp

Anledningen till att tvetydigheten håller i sig är att tre separata system beskriver den här modellen och inget av dem delar någon namngivningskonvention.

Prissidan listar den under modellens eget namn, tillsammans med ett pris och en anteckning om att utdata inte är tillämplig. API-referensen beskriver slutpunkten och namnger modellen i tillgänglighetsmeningen i stället för i en modelltabell. Den oberoende leaderboarden som benchmarkar den använder det läsbara namnet i sin rad och sitt diagram. Ingen av dessa är fel, och ingen av dem är ett modell-id, så att kopiera från någon av dem till en förfrågningskropp ger samma fel.

Det finns en fjärde variationskälla som kommer att spela större roll med tiden: andra människors skrivande. Lanseringstexter, handledningar och forumssvar förkortar alla namnet, och en del av dem förkortar det till något som ser ut som ett id – gemener, bindestreck, trovärdigt. Lösningen är att inte lita på någon av dem. Fråga endpointen.

Hur du kontrollerar vad en given nyckel faktiskt kan anropa

Innan du skriver en begäran, lista de modeller som nyckeln har rätt till. Det standardmässiga list-models-anropet mot Generative Language API returnerar de modeller som är tillgängliga för ditt projekt med deras id:n, och att köra det en gång avgör frågan permanent för den nyckeln.

Om gemini-decision-1 visas har du åtkomst, och det är exakt den strängen som ska anges i begäran. Om den inte visas beror problemet på behörighet eller region, inte på stavning, och ingen mängd namnbyten kommer att hjälpa. Det du inte kommer att hitta i den listan är en post som heter gemini-decision, eftersom det inte finns någon sådan modell.

Den andra kontrollen gäller svaret. Ett lyckat svar på ett beslut identifierar modellen som betjänade det, så en pipeline som loggar modellfältet tillsammans med sitt eget förfrågnings-id kan månader senare svara på "vilken modell producerade det här svaret" utan att läsa om konfigurationen. Det låter som städning tills första gången någon frågar varför ett beslut ändrades och det ärliga svaret är att ett alias flyttades.

De tre misstag som denna tvetydighet faktiskt orsakar

• 404 för okänd modell. Den uppenbara. gemini-decision i förfrågningskroppen returnerar ett fel som låter som ett behörighetsproblem men inte är det. Om felet nämner modellen i stället för projektet, kontrollera strängen innan du kontrollerar faktureringskontot.

• Det tysta antagandet om alias. Svårare att upptäcka. Ett team som har internaliserat -latest-konventioner skriver en konfiguration med ett familjenamn och ett upplösningssteg, och upplösningssteget returnerar tyst det bokstavliga familjenamnet när inget alias finns. Felet dyker då upp vid den första verkliga förfrågan i stället för vid driftsättningen, vilket är den sämsta möjliga tidpunkten för det.

• Antagandet om felaktig slutpunkt. Ännu mer subtilt, eftersom modellen finns och namnet är rätt: gemini-decision-1 som skickas till en vanlig generate-content-slutpunkt misslyckas fortfarande. Modellen kan inte anropas på det sättet överhuvudtaget. Den är ett mål för enbart sannolikheter på decisions-slutpunkten, och en begäran som ber den om prosa ber om något som den inte producerar. Varje klientbibliotek som som standard använder chat completions kommer att behöva en explicit väg.

Vad detta säger om modellen, inte bara dess namn

Namngivningen är ett symptom på det verkliga designbeslutet, som är att detta inte är en chattmodell med ett annat utdataformat. En chattmodell returnerar text, så dess id kan fritt bytas ut mellan leverantörer, proxyservrar och gateways som alla talar samma schema. En modell som returnerar kalibrerade sannolikheter över dina egna typade frågor har inget sådant gemensamt schema, och id:t är bundet till en endpoint med en enda förfrågningsform.

Det är därför familjen ännu inte har något flytande alias och ingen andra medlem: det finns inget att vara kompatibel med. Det förklarar också varför modellen inte bara kan läggas till i en allmän router. OrcaRouter har inte gemini-decision-1, eftersom en slutpunkt som bara ger sannolikheter inte är ett mål för chat-completions, och att placera den bakom en nyckel som talar det schemat skulle vara ett löfte som routningslagret inte kan hålla. Det vi däremot har i beslutsutrymmet är TypeSafe:s typesafe/jev-1.14, en beslutsmodell som kan anropas via samma gränssnitt som allt annat i katalogen.

Den del av en beslutsprocess som routern faktiskt hanterar är utkastdelen – det generativa anropet som producerar kandidatsvaret eller den bedömningsmall som poängsättaren sedan utvärderar. Det anropet körs över fler än 200 modeller på en och samma slutpunkt, med leverantörens listpris vidaresänt med 0 % påslag, och det är anropet där byte av leverantör är en konfigurationsändring snarare än en omskrivning. Poängsättningsanropet är däremot avsiktligt bundet till en enda slutpunkt, och den ärliga arkitekturen behandlar det som ett fast beroende snarare än något att routa runt.

Om du väljer mellan de två strängarna i ett formulär

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 "G​emini Decision" with "G​emini 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 G​emini Decision shipped before G​emini Decision 1, and the shorter name is the family label for a family that currently has a single member.

Den praktiska konsekvensen är att varje jämförelsetabell, recension eller benchmark som du hittar där båda listas som separata poster beskriver samma modell två gånger. Två rader, en modell, ett pris. Om de två raderna skiljer sig åt i en siffra är en av dem inaktuell snarare än att den mäter något annat.

Slutsatsen

Use gemini-decision-1 in every request body, endpoint path and config value, and use "G​emini 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.