Gemini Decision vs. Gemini Decision 1: Das eine ist ein Name, das andere eine Modell-ID

Suchen Sie nach Gemini Decision und Sie finden Launch-Berichterstattung, einen Leaderboard-Eintrag, eine Preiszeile und eine API-Referenz, die alle leicht unterschiedliche Wörter für dieselbe Sache verwenden. Suchen Sie nach Gemini Decision 1 und Sie finden die Modell-ID, die tatsächlich funktioniert. Die beiden Zeichenfolgen unterscheiden sich um ein einziges Zeichen und verhalten sich im Code völlig unterschiedlich: Die eine ist das, was die Leute das Produkt nennen, und die andere ist der einzige Wert, den POST /v1beta/decisions akzeptiert. Wenn Sie einen Nachmittag mit einem 404 verbracht haben und sich gefragt haben, warum ein Modell, das offensichtlich existiert, nicht gefunden werden kann, ist dies der Artikel, der Ihnen das erspart hätte.

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.

Worauf die beiden Namen auflösen

Beginne mit dem Mapping, denn alles andere folgt daraus.

• 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.

Wo der zweite Name immer wieder erscheint

Der Grund, warum die Mehrdeutigkeit Bestand hat, ist, dass drei separate Systeme dieses Modell beschreiben und keines von ihnen eine einheitliche Namenskonvention verwendet.

Die Preisseite führt es unter dem eigenen Namen des Modells auf, zusammen mit einem Tarif und einem Hinweis, dass die Ausgabe nicht anwendbar ist. Die API-Referenz beschreibt den Endpunkt und nennt das Modell im Verfügbarkeitssatz statt in einer Modelltabelle. Das unabhängige Leaderboard, das es als Benchmark testet, verwendet den lesbaren Namen in seiner Zeile und in seinem Diagramm. Nichts davon ist falsch, und keines davon ist eine Modell-ID, sodass das Kopieren aus einem davon in einen Anfrage-Body denselben Fehler erzeugt.

Es gibt eine vierte Quelle der Variation, die mit der Zeit immer wichtiger wird: die Texte anderer Leute. Launch-Berichterstattung, Tutorials und Forenantworten kürzen den Namen allesamt ab, und manche kürzen ihn zu etwas, das wie eine ID aussieht – kleingeschrieben, mit Bindestrichen, plausibel. Die Lösung besteht nicht darin, irgendeiner davon zu vertrauen. Frag den Endpoint.

So prüfen Sie, was ein bestimmter Schlüssel tatsächlich aufrufen kann

Bevor Sie eine Anfrage schreiben, listen Sie die Modelle auf, auf die der Schlüssel Anspruch hat. Der standardmäßige list-models-Aufruf an der Generative Language API gibt die für Ihr Projekt verfügbaren Modelle samt ihren IDs zurück, und wenn man ihn einmal ausführt, ist die Frage für diesen Schlüssel dauerhaft geklärt.

Wenn gemini-decision-1 erscheint, hast du Zugriff, und genau diese Zeichenfolge gehört in die Anfrage. Wenn nicht, liegt das Problem an der Berechtigung oder der Region und nicht an der Schreibweise, und kein noch so häufiges Umbenennen wird helfen. Was du in dieser Liste nicht finden wirst, ist ein Eintrag namens gemini-decision, denn ein solches Modell gibt es nicht.

Die zweite Prüfung betrifft die Antwort. Eine erfolgreiche Entscheidungsantwort gibt an, welches Modell sie bereitgestellt hat, sodass eine Pipeline, die das Feld „Modell“ zusammen mit ihrer eigenen Anfrage-ID protokolliert, Monate später beantworten kann, „welches Modell diese Antwort erzeugt hat“, ohne die Konfiguration erneut lesen zu müssen. Das klingt nach Hausmeisterei, bis zum ersten Mal jemand fragt, warum sich eine Entscheidung geändert hat, und die ehrliche Antwort lautet, dass ein Alias verschoben wurde.

Die drei Fehler, die diese Mehrdeutigkeit tatsächlich verursacht

• Der 404 bei unbekanntem Modell. Der offensichtliche Fall. gemini-decision im Request-Body gibt einen Fehler zurück, der wie ein Berechtigungsproblem klingt, aber keines ist. Wenn der Fehler das Modell statt des Projekts nennt, prüfe den String, bevor du das Abrechnungskonto prüfst.

• Die stille Alias-Annahme. Schwerer zu erkennen. Ein Team, das -latest-Konventionen verinnerlicht hat, schreibt eine Konfiguration mit einem Familiennamen und einem Auflösungsschritt, und der Auflösungsschritt gibt stillschweigend den wörtlichen Familiennamen zurück, wenn kein Alias existiert. Der Fehler tritt dann bei der ersten echten Anfrage auf statt beim Deployment – der denkbar schlechteste Zeitpunkt dafür.

• Die Annahme des falschen Endpunkts. Noch subtiler, weil das Modell existiert und der Name stimmt: gemini-decision-1, an einen gewöhnlichen generate-content-Endpunkt gesendet, schlägt weiterhin fehl. Das Modell ist auf diese Weise überhaupt nicht aufrufbar. Es ist ein reines Wahrscheinlichkeitsziel am decisions-Endpunkt, und eine Anfrage, die von ihm Prosa verlangt, verlangt etwas, das es nicht erzeugt. Jede Client-Bibliothek, die standardmäßig auf Chat-Completions setzt, benötigt einen expliziten Pfad.

Was das über das Modell aussagt – nicht nur über seinen Namen.

{{1}}Die Benennung ist ein Symptom der eigentlichen Designentscheidung, nämlich dass dies kein Chat-Modell mit einem anderen Ausgabeformat ist.{{/1}} Ein Chat-Modell gibt Text zurück, daher kann seine ID frei zwischen Anbietern, Proxys und Gateways ausgetauscht werden, die alle dasselbe Schema sprechen. Ein Modell, das kalibrierte Wahrscheinlichkeiten über Ihre eigenen typisierten Fragen zurückgibt, hat kein solches gemeinsames Schema, und die ID ist an einen Endpunkt mit einer einzigen Anfrageform gebunden.

Deshalb hat die Familie noch keinen fließenden Alias und noch kein zweites Mitglied: Es gibt nichts, womit sie kompatibel sein müsste. Das erklärt auch, warum das Modell nicht einfach zu einem Allzweck-Router hinzugefügt werden kann. OrcaRouter führt gemini-decision-1 nicht, weil ein reiner Wahrscheinlichkeits-Endpunkt kein Chat-Completions-Ziel ist und ihn hinter einem Schlüssel zu platzieren, der dieses Schema spricht, ein Versprechen wäre, das die Routing-Schicht nicht halten kann. Was wir im Entscheidungsraum führen, ist TypeSafe's typesafe/jev-1.14, ein Entscheidungsmodell, das über dieselbe Schnittstelle aufrufbar ist wie alles andere im Katalog.

Der Teil einer Entscheidungs-Pipeline, den der Router tatsächlich bedient, ist die Entwurfshälfte – der generative Aufruf, der die Kandidatenantwort oder die Rubrik erzeugt, die der Scorer anschließend bewertet. Dieser Aufruf läuft über mehr als 200 Modelle an einem einzigen Endpunkt, wobei die Listenpreise der Anbieter mit 0 % Aufschlag weitergegeben werden, und es ist der Aufruf, bei dem ein Anbieterwechsel eine Konfigurationsänderung statt einer Neufassung ist. Der Bewertungsaufruf hingegen ist konstruktionsbedingt an einen Endpunkt gebunden, und die ehrliche Architektur behandelt ihn als feste Abhängigkeit und nicht als etwas, das man umgehen sollte.

Wenn Sie auf einem Formular zwischen den beiden Zeichenfolgen wählen

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.

Die praktische Konsequenz ist, dass jede Vergleichstabelle, jeder Testbericht oder Benchmark, in der bzw. dem beide als separate Einträge aufgeführt sind, dasselbe Modell zweimal beschreibt. Zwei Zeilen, ein Modell, ein Preis. Wenn die beiden Zeilen bei einer Zahl voneinander abweichen, ist eine davon veraltet und misst nicht etwas anderes.

Fazit

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.