Gemini Decision vs Gemini Decision 1: het ene is een naam, het andere is een model-ID

Zoek naar Gemini Decision en je vindt berichtgeving over de lancering, een vermelding op een ranglijst, een prijsregel en een API-referentie, allemaal met net iets andere bewoordingen voor hetzelfde. Zoek naar Gemini Decision 1 en je vindt de model-id die daadwerkelijk werkt. De twee strings verschillen één teken van elkaar en gedragen zich in code volledig anders: de ene is hoe mensen het product noemen, en de andere is de enige waarde die POST /v1beta/decisions accepteert. Als je een middag aan een 404 hebt besteed en je afvroeg waarom een model dat overduidelijk bestaat niet te vinden is, dan is dit het artikel dat je die middag had bespaard.

De verwarring is niet specifiek iemands fout. G​oogle bracht op 11 november 2026 een model, een endpoint en een familienaam uit in dezelfde release, en de natuurlijke manier om over alle drie te schrijven is ze af te korten. Die afkorting werkt in lopende tekst en faalt in een request body, en de kloof tussen die twee feiten is waar de meeste supporttickets in deze categorie de komende maand vandaan zullen komen.

Waar de twee namen naar verwijzen

Begin met de mapping, want al het andere volgt daaruit.

• 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 — het model, en de id gemini-decision-1. Dit is de waarde die werkt. Het is het enige model dat de Decisions API levert, en de documentatie zegt dit expliciet: het endpoint is alleen beschikbaar met G​emini Decision 1.

Twee namen, één model, en geen alias ertussen. Dat laatste is het ongebruikelijke deel. De meeste G​oogle-modelfamilies bieden een meebewegende alias en een vastgezette id — een -latest-vorm voor prototypes en een gedateerde of genummerde vorm voor productie. Deze biedt alleen de vastgezette vorm, dus elk codepad dat ervan uitgaat dat families een zwevend hoofd hebben, zal hier falen in plaats van stilzwijgend een nieuwe versie te volgen.

Waar de tweede naam steeds weer blijft opduiken

De reden dat de ambiguïteit blijft voortbestaan, is dat drie afzonderlijke systemen dit model beschrijven en geen van hen een gedeelde naamgevingsconventie heeft.

De prijspagina vermeldt het onder de eigen naam van het model, samen met een tarief en een opmerking dat output niet van toepassing is. De API-referentie beschrijft het endpoint en noemt het model in de zin over beschikbaarheid in plaats van in een modeltabel. Het onafhankelijke leaderboard dat de benchmark uitvoert, gebruikt de leesbare naam in zijn rij en zijn grafiek. Geen van deze is fout, en geen ervan is een model-id, dus het kopiëren van een ervan naar een request body levert dezelfde fout op.

Er is een vierde bron van variatie die naarmate de tijd verstrijkt steeds belangrijker wordt: het geschreven werk van anderen. Berichtgeving rond de lancering, tutorials en forumannen verkorten allemaal de naam, en sommige verkorten die tot iets dat op een id lijkt — kleine letters, met koppeltekens, plausibel. De oplossing is om geen enkele daarvan te vertrouwen. Vraag het aan het endpoint.

Hoe je kunt controleren wat een bepaalde sleutel daadwerkelijk kan aanroepen

Voordat je een request schrijft, vraag je de modellen op waarop de sleutel recht heeft. De standaardaanroep list-models op de Generative Language API retourneert de modellen die beschikbaar zijn voor je project, met hun id's, en door die één keer uit te voeren is de kwestie voor die sleutel definitief beslecht.

Als gemini-decision-1 verschijnt, heb je toegang, en die exacte tekenreeks is wat in het verzoek wordt gezet. Als het niet verschijnt, ligt het probleem aan rechten of regio, niet aan de spelling, en geen enkele hernoeming zal helpen. Wat je in die lijst niet zult vinden, is een vermelding met de naam gemini-decision, want dat model bestaat niet.

De tweede controle betreft het antwoord. Een succesvol beslissingsantwoord identificeert het model dat het heeft geleverd, dus een pipeline die het modelveld samen met zijn eigen request-id logt, kan maanden later nog beantwoorden "welk model heeft dit antwoord geproduceerd" zonder de configuratie opnieuw te lezen. Dat klinkt als administratieve rompslomp totdat iemand voor het eerst vraagt waarom een beslissing is veranderd en het eerlijke antwoord is dat een alias is verplaatst.

De drie fouten die deze ambiguïteit daadwerkelijk veroorzaakt

• De 404 voor een onbekend model. De voor de hand liggende. gemini-decision in de request body geeft een fout die eruitziet als een rechtenprobleem, maar dat niet is. Als de fout het model noemt in plaats van het project, controleer dan de string voordat je het factureringsaccount controleert.

• De stille alias-aanname.Moeilijker te spotten. Een team dat de -latest-conventies heeft geïnternaliseerd, schrijft een config met een familienaam en een resolutiestap, en die resolutiestap geeft stilletjes de letterlijke familienaam terug wanneer er geen alias bestaat. De fout komt dan pas aan het licht bij het eerste echte verzoek in plaats van bij de deployment, wat het slechtst mogelijke moment is.

• De aanname van het verkeerde endpoint. Nog subtieler, omdat het model bestaat en de naam klopt: gemini-decision-1 dat naar een gewoon generate-content-endpoint wordt gestuurd, faalt nog steeds. Het model is op die manier helemaal niet aanroepbaar. Het is een target dat op het decisions-endpoint uitsluitend waarschijnlijkheden levert, en een verzoek dat er proza van vraagt, vraagt om iets wat het niet produceert. Elke clientbibliotheek die standaard op chat completions terugvalt, heeft een expliciet pad nodig.

Wat dit zegt over het model, en niet alleen over de naam ervan

De naamgeving is een symptoom van de echte ontwerpbeslissing, namelijk dat dit geen chatmodel is met een ander uitvoerformaat. Een chatmodel retourneert tekst, dus de id ervan kan vrij worden uitgewisseld tussen providers, proxies en gateways die allemaal hetzelfde schema spreken. Een model dat gekalibreerde waarschijnlijkheden retourneert over je eigen getypeerde vragen heeft geen dergelijk gemeenschappelijk schema, en de id is gebonden aan één endpoint met één requestvorm.

Daarom heeft de familie nog geen zwevende alias en nog geen tweede lid: er is niets om compatibel mee te zijn. Het verklaart ook waarom het model niet zomaar aan een algemene router kan worden toegevoegd. OrcaRouter heeft gemini-decision-1 niet in huis, omdat een endpoint met alleen waarschijnlijkheden geen doel is voor chat-completions, en het achter een sleutel plaatsen die dat schema spreekt, zou een belofte zijn die de routeringslaag niet kan nakomen. Wat we in de beslissingsruimte wél hebben, is TypeSafe's typesafe/jev-1.14, een beslissingsmodel dat via dezelfde interface als alles else in de catalogus aanroepbaar is.

Het deel van een beslissingspijplijn dat de router wél bedient, is het opstellende deel — de generatieve aanroep die het kandidaatantwoord of de rubric oplevert die de scorer vervolgens beoordeelt. Die aanroep loopt over meer dan 200 modellen op één endpoint, met de lijstprijs van de provider doorgegeven tegen 0% opslag, en het is de aanroep waarbij het wisselen van leverancier een configuratiewijziging is in plaats van een herschrijving. De beoordelingsaanroep daarentegen is naar ontwerp aan één endpoint gebonden, en de eerlijke architectuur behandelt die als een vaste afhankelijkheid in plaats van iets om omheen te routeren.

Als u moet kiezen tussen de twee tekenreeksen op een formulier

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.

De praktische consequentie is dat elke vergelijkingstabel, review of benchmark die beide als afzonderlijke vermeldingen opsomt, hetzelfde model twee keer beschrijft. Twee rijen, één model, één prijs. Als de twee rijen het oneens zijn over een getal, is een van beide verouderd in plaats van dat ze iets anders meten.

Kortom

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.