Googles Decisions API beantwortet 1.000 Fragen und rechnet keine Ausgabe ab.

Der günstigste Teil von Gemini Decision 1 ist der Teil, den es nicht gibt. Google hat das Modell am 11. November 2026 hinter einer neuen Gemini Decisions API platziert, und auf der Preisseite steht der Output bei null – nicht günstig, nicht rabattiert, sondern nicht vorhanden, weil POST /v1beta/decisions keinen Fließtext zu generieren hat. Sie senden einen Block gemeinsamer Eingaben plus bis zu 1.000 typisierte Fragen; zurück erhalten Sie pro Frage eine kalibrierte Antwort und sonst nichts. Die Zahl im Leaderboard sorgte am Starttag für Aufmerksamkeit. Die Abrechnungszeile ist diejenige, die ändert, was Sie bauen, und es lohnt sich, die Rechnung aufzumachen, bevor Sie irgendjemandes Architekturdiagramm kopieren.

Jede andere Modellentscheidung, die Sie in den letzten zwei Jahren getroffen haben, wurde von zwei Kosten in entgegengesetzte Richtungen geprägt: Input, den Sie nur einmal senden möchten, und Output, den Sie kurz halten möchten. Dieser Endpoint beseitigt die zweite Spannung vollständig und ersetzt sie durch eine andere, die einem einzelnen Request innewohnt. Sobald Sie erkennen, wo die neue Spannung liegt, wirkt der Rest des API-Designs – die Fragenobergrenze, der gemeinsam genutzte Kontext, das Fehlen von Caching – nicht mehr willkürlich.

Was null Ausgabe-Tokens mit der Arithmetik anrichten

Nehmen Sie einen realistischen Auftrag zur Dokumentenbewertung: eine Richtlinie oder einen Vertrag mit 40.000 Tokens und 1.000 Fragen, die Sie dazu beantwortet haben möchten. Eine Anfrage an die Decisions API stellt 40.000 Eingabe-Tokens einmalig mit $0.10 pro Million in Rechnung, was vier Zehntel Cent entspricht — $0.004 für alle eintausend Antworten.

Stellen Sie jetzt dieselben 1.000 Fragen so, wie Sie sie eine Woche zuvor gestellt hätten, als 1.000 separate generate-content-Aufrufe. Jeder Aufruf muss das Dokument mitführen, weil ein Chat-Endpunkt es nicht über Aufrufe hinweg halten kann. Das sind 40 Millionen Eingabe-Tokens oder $4.00 zum gleichen Preis pro Token, und die Lücke wird größer, sobald man die Ausgabe-Tokens hinzurechnet, die jeder dieser Aufrufe erzeugt hätte. Die Envelope ist kein Komfortmerkmal. Es ist ein tausendfacher Kostenunterschied bei derselben Arbeit, und er resultiert aus einer einzigen Designentscheidung: Fragen werden in einem Durchlauf gegen einen gemeinsamen Kontext ausgewertet, nicht einmal pro Roundtrip.

Diese Rechnung verrät dir auch die Form der Arbeitslast, auf die dieses Modell ausgelegt ist. Viele Fragen zu einem großen Objekt, gemeinsam beantwortet. Wenn deine Fragen 1.000 verschiedene Objekte betreffen, erhältst du 1.000 Anfragen und keine der Einsparungen.

Das Kontingent: 262.144 Tokens, gemeinsam genutzt und auf 1.000 Fragen begrenzt.

Das Kontextfenster umfasst die gemeinsame Eingabe und alle Fragen in der Anfrage zusammen, bei 262.144 Tokens. Innerhalb dieses Budgets können Sie zwischen 1 und 1.000 Fragen stellen. Entscheidend ist die Obergrenze: 1.000 Fragen in einem einzigen Aufruf sind nicht das Revier eines Klassifikators, sondern so viel Urteilsvermögen wie bei einer Rules Engine, komprimiert in einen einzigen Durchlauf. Ein Support-Ticket kann gegen vierzig Richtlinienklauseln geprüft werden; eine Kreditakte kann auf einmal gegen sämtliche Underwriting-Regeln geprüft werden.

Zwei Eigenschaften der Form der Anfrage sind leicht zu übersehen und deren Entdeckung wird später teuer. Fragen werden unabhängig voneinander bewertet — die Antwort auf eine Frage konditioniert nicht die nächste, daher können Sie keine Schlussfolgerungskette aufbauen, indem Sie eine Folgefrage stellen, die von einer früheren Antwort abhängt. Und das Modell sieht Ihre Fragenschlüssel nie, sondern nur den Anweisungstext, den Sie schreiben; die Schlüssel dienen daher Ihrer eigenen Buchführung, und die Anweisungen müssen für sich stehen.

Drei Frageformen – und die Falle in jeder

• Ja/Nein — der noul type gibt eine Wahrscheinlichkeit zwischen 0,01 und 0,99 plus einen Konfidenzwert zurück. Die Grenze ist an beiden Enden begrenzt, sodass ein Routing-Schwellenwert von 0,995 nie ausgelöst wird, egal wie sicher sich das Modell ist. Wählen Sie Schwellenwerte innerhalb des Bereichs, den die API tatsächlich zurückgeben kann.

• Choice — zwei bis 255 benannte Optionen, die die gewinnende Option, eine Wahrscheinlichkeit für jede Option mit Summe eins und eine Konfidenz zurückgibt. Vor der Bewertung sortiert die API Ihre Optionsschlüssel alphabetisch in UTF-8-Byte-Reihenfolge, was bedeutet, dass die JSON-Schlüsselreihenfolge irrelevant ist und ein exaktes Unentschieden zugunsten des Schlüssels aufgelöst wird, der zuerst sortiert. Googles Empfehlung folgt daraus: Nennen Sie Ihre Auffangoption other, denn ein Name wie none_of_the_above sortiert vor den meisten echten Kategorien und gewinnt Unentschieden, die er verlieren sollte.

• Punktzahl — zwei bis 255 geordnete Bewertungsstufen, wobei zwei bis zehn empfohlen werden. Der Rückgabewert ist eine wahrscheinlichkeitsgewichtete erwartete Stufe, und da der Erwartungswert Array-Indizes statt der Beschriftungen mittelt, ergibt eine als 1/10/100/1000 geschriebene Skala eine Zahl, die nicht auf Ihrer Skala liegt. Halten Sie die Bewertungsstufen im Hinblick auf die Indizes gleichmäßig verteilt, oder wandeln Sie den erwarteten Index selbst wieder in eine Beschriftung um.

Was die Dokumentation als nicht verfügbar aufführt

Die Lücken weisen alle in dieselbe Richtung: Dies ist ein Single-Shot-Endpoint, um den herum nichts weiter vorhanden ist. Es gibt kein Kontext-Caching, sodass ein über mehrere Anfragen hinweg wiederverwendetes Richtliniendokument jedes Mal erneut vollständig abgerechnet wird. Es gibt keine Batch API, was einen nächtlichen Durchlauf der Tickets des letzten Jahres zum halben Preis ausschließt. Es gibt keine Flex- oder Priority-Stufe. Das Modell ist ausschließlich über die Gemini Developer API in Version v1beta verfügbar; in der von Google ausgelieferten Dokumentation gibt es keinen Vertex-AI-Eintrag – ein Detail, das für alle wichtig ist, deren Beschaffung über einen Cloud-Vertrag statt über einen API-Schlüssel läuft.

Medien sind ungewöhnlich breit gefasst und zugleich ungewöhnlich begrenzt. Text, Bild, Video, Audio und PDF werden alle in einer einzigen Anfrage übergeben. Die Grenzen liegen bei 100 MB für Inline-Base64, 50 MB für ein PDF und 15 MB pro externer HTTPS-URL. YouTube-Links werden nicht akzeptiert, ebenso wenig gs://-URIs; Sie übergeben Referenzen auf hochgeladene Dateien, signierte URLs oder Bytes.

Die Ratenlimits beginnen im kostenlosen Tarif bei 200 Anfragen und 50.000 Tokens pro Minute, steigen in Stufe 1 auf 1.500 und eine Million und erreichen in Stufe 2 5.000 Anfragen und vier Millionen Tokens pro Minute ohne tägliche Anfrageobergrenze. Der kostenlose Tarif ist kostenlos, wird aber laut Dokumentation zur Verbesserung der Google-Produkte genutzt, was ihn für alles unter einer Vertraulichkeitsklausel disqualifiziert.

Der Spielstand, kurz.

Auf dem Artificial Analysis Decision Index v2.1 erreicht das Modell 66 – ungerundet 65,98 – und belegt damit Platz neun von achtzehn Entscheidungsmodellen, die das Board bewertet. Bei zwei der sechs Komponenten liegt es eindeutig auf Platz eins, AA-Omniscience-Decision v1.1 und HLE-MultiChoice v1.1, die beide mit 15 % gewichtet sind, und bei AA-Paperclip mit 30 % Gewichtung liegt es im Mittelfeld – der Komponente, die den Großteil des Gesamtwerts bestimmt. Die gemessenen Kosten liegen bei 345 US-Dollar pro Million Aufgaben, die Latenz bei 211 Millisekunden pro Aufgabe gegenüber einem Median des Teilnehmerfelds von 209. Google hat zusammen mit der Veröffentlichung keine eigene Benchmark-Tabelle veröffentlicht; jede hier genannte Leistungsangabe stammt vom unabhängigen Board und wurde auf dessen eigener Testumgebung ermittelt. Die Arithmetik hinter der 66 ist eine separate Frage und ein separater Artikel.

Es in eine Pipeline einpassen, die Sie bereits routen

OrcaRouter führt gemini-decision-1 nicht mit, und der Grund ist struktureller, nicht kommerzieller Natur: Ein Endpunkt, der ausschließlich Wahrscheinlichkeiten liefert, ist kein Chat-Completions-Ziel; ein Router unserer Bauart hat also nichts, was er hinter einem einzigen Schlüssel bereitstellen könnte. Die Hälfte der Pipeline, für die wir stehen, ist die andere Hälfte. Ein Entscheidungsdienst besteht fast immer aus zwei Aufrufen – etwas entwirft die Kandidatenantwort, die Bewertungsrubrik oder die Shortlist, und etwas bewertet sie –, und der Aufruf zum Entwerfen ist derjenige, bei dem die Modellwahl tatsächlich umstritten ist.

Dieser Aufruf kann über mehr als 200 Modelle an einem einzigen Endpoint, zum Listenpreis des Anbieters, durchgereicht mit 0 % Aufschlag, laufen. Wenn ein Anbieter also einen Preis senkt, ist der neue Preis bei uns noch am selben Tag live und nicht erst im nächsten Abrechnungszyklus. Modell-Fusion verdient hier ihren Platz auf eine Weise, wie sie es in einer Chat-UI nicht tut: Zwei Drafter erzeugen konkurrierende Kandidatenantworten, und die Decisions API bewertet beide in einer einzigen Anfrage anhand derselben Rubrik, wodurch ein A/B-Test zu einer Entscheidung pro Datensatz wird.

Auch beim Failover lohnt es sich, präzise zu sein. Automatisches Failover schützt den generativen Aufruf — wenn der Anbieter hinter Ihrem Drafting-Modell Fehler zurückgibt, wird die Anfrage umgeleitet und die Pipeline läuft weiter. Den Scoring-Aufruf kann es nicht schützen, denn dafür gibt es genau eine Stelle, an die er gesendet werden kann. Wenn der Decisions-Endpunkt nicht erreichbar ist, ist Ihre Pipeline nicht erreichbar, und noch so viel Routing ändert daran nichts. Gestalten Sie die Drafting-Hälfte ausfallsicher und akzeptieren Sie, dass die Scoring-Hälfte eine Abhängigkeit darstellt.

Fazit

Die Decisions API lohnt sich aus einem Grund, und es ist nicht der Platz im Leaderboard: Sie fasst tausend Roundtrips zu einer abgerechneten Eingabe zusammen, und das verändert, welche Fragen günstig zu stellen sind. Bauen Sie darauf auf, wenn Ihre Probleme wie viele Beurteilungen über ein großes Objekt aussehen – ein Vertrag, eine Schadensakte, eine Stunde Video –, und rechnen Sie damit, Ihre Prompts in einer einzigen Anfrage zu halten, denn alles, was sie günstig macht, geschieht zwischen dem ersten und letzten Token eines einzelnen Aufrufs. Wenn Ihre Probleme wie eine Frage über tausend kleine Objekte aussehen, bringt Ihnen die Hülle nichts, und der Eingabetarif ist schlicht dreimal so hoch wie der, den ein günstigeres Entscheidungsmodell berechnet.