De Decisions API van Google beantwoordt 1.000 vragen en rekent geen kosten voor output

Het goedkoopste deel van Gemini Decision 1 is het deel dat niet bestaat. Google zette het model achter een nieuwe Gemini Decisions API op 11 november 2026, en de prijspagina vermeldt output op nul — niet goedkoop, niet afgeprijsd, afwezig, omdat POST /v1beta/decisions geen proza te genereren heeft. Je stuurt één blok gedeelde invoer plus maximaal 1.000 getypeerde vragen; je krijgt één gekalibreerd antwoord per vraag terug en niets anders. De score op het leaderboard trok op de lanceerdag de aandacht. De factureringsregel is degene die verandert wat je bouwt, en het loont de moeite de rekensom te maken voordat je iemands architectuurdiagram kopieert.

Elke andere modelbeslissing die je de afgelopen twee jaar hebt genomen, werd bepaald door twee kosten die elkaar tegenwerkten: input die je maar één keer wilt versturen, en output die je kort wilt houden. Dit endpoint haalt de tweede spanning volledig weg en vervangt die door een andere, interne spanning binnen één enkele request. Zodra je ziet waar de nieuwe spanning zit, ziet de rest van het ontwerp van de API — het maximum aantal vragen, de gedeelde context, het ontbreken van caching — er niet langer willekeurig uit.

Wat nul outputtokens met de rekenkunde doet

Neem een realistische taak voor het scoren van documenten: een beleidsdocument of contract van 40.000 tokens, en 1.000 vragen die je erover beantwoord wilt hebben. Eén verzoek aan de Decisions API brengt 40.000 invoertokens één keer in rekening, tegen $0,10 per miljoen, wat vier tienden van een cent is — $0,004 voor alle duizend antwoorden.

Stel nu dezelfde 1.000 vragen op de manier waarop je ze een week eerder zou hebben gesteld, als 1.000 afzonderlijke generate-content-aanroepen. Elke aanroep moet het document meedragen, omdat een chat-endpoint het niet tussen aanroepen kan vasthouden. Dat is 40 miljoen invoertokens, of $4,00 tegen hetzelfde tarief per token, en het verschil wordt groter zodra je de uitvoertokens optelt die elk van die aanroepen zou hebben opgeleverd. De envelop is geen gemaksfunctie. Het is een duizendvoudig kostenverschil voor hetzelfde werk, en het komt voort uit één ontwerpkeuze: vragen worden in één pass tegen één gedeelde context geëvalueerd, niet één per round trip.

Die rekensom vertelt je ook wat de vorm is van de werkbelasting die dit model wil. Veel vragen over één groot object, samen beantwoord. Als je vragen over 1.000 verschillende objecten gaan, krijg je 1.000 requests en geen enkele besparing.

De envelop: 262.144 tokens, gedeeld en beperkt tot 1.000 vragen

Het contextvenster omvat de gedeelde invoer en alle vragen in het verzoek samen, bij 262.144 tokens. Binnen dat budget kun je tussen 1 en 1.000 vragen stellen. Het getal dat ertoe doet, is de bovengrens: 1.000 vragen in één aanroep is geen kwestie van classifiers; het is een regelengine-waardige hoeveelheid oordeelsvermogen, samengeperst in één doorgang. Een supportticket kan tegen veertig beleidsclausules worden getoetst; een leningdossier kan in één keer tegen elke acceptatieregel worden getest.

Twee eigenschappen van de vorm van het verzoek zijn gemakkelijk over het hoofd te zien en kostbaar om er later achter te komen. Vragen worden onafhankelijk van elkaar beoordeeld — het antwoord op de ene vraag bepaalt niet de volgende, dus je kunt redeneringen niet aan elkaar koppelen door een vervolgvraag te stellen die afhangt van een eerder antwoord. En het model ziet nooit je vraagsleutels, alleen de instructietekst die je schrijft, dus de sleutels zijn voor je eigen administratie en de instructies moeten op zichzelf kunnen staan.

Drie vraagvormen, en de valkuil in elk ervan

• Ja/nee — het noul-type retourneert een waarschijnlijkheid tussen 0,01 en 0,99 plus een betrouwbaarheidsscore. De grens is aan beide uiteinden vastgeklemd, dus een routeringsdrempel op 0,995 zal nooit afgaan, hoe zeker het model ook is. Kies drempels binnen het bereik dat de API daadwerkelijk kan retourneren.

• Keuze — twee tot 255 benoemde opties, met als resultaat de winnende optie, een waarschijnlijkheid voor elke optie die optelt tot één, en een betrouwbaarheid. Vóór het scoren sorteert de API je optiesleutels alfabetisch in UTF-8-bytevolgorde, wat betekent dat de volgorde van JSON-sleutels irrelevant is en een exacte tie wordt beslecht in het voordeel van de sleutel die als eerste sorteert. De richtlijn van Google volgt daaruit: noem je catch-all-optie other, omdat een naam als none_of_the_above vóór de meeste echte categorieën sorteert en ties wint die hij zou moeten verliezen.

• Score — twee tot 255 geordende rubricniveaus, waarbij twee tot tien wordt aanbevolen. De retourwaarde is een kansgewogen verwacht niveau, en omdat de verwachte waarde de array-indexen middelt in plaats van de labels, levert een schaal geschreven als 1/10/100/1000 een getal op dat niet op je schaal voorkomt. Houd de rubric gelijkmatig verdeeld in termen van indexen, of converteer de verwachte index zelf terug naar een label.

Wat de documentatie als niet beschikbaar vermeldt

De hiaten wijzen allemaal dezelfde kant op: dit is een single-shot-endpoint zonder dat er iets omheen zit. Er is geen contextcaching, dus een beleidsdocument dat bij meerdere verzoeken wordt hergebruikt, wordt telkens opnieuw volledig in rekening gebracht. Er is geen Batch API, waardoor een nachtelijke verwerking tegen halve prijs van de tickets van vorig jaar niet mogelijk is. Er is geen Flex- of Priority-tier. Het model staat alleen op de Gemini Developer API, versie v1beta, zonder vermelding van Vertex AI in de documentatie die Google heeft geleverd — een detail dat van belang is voor iedereen wiens inkoop via een cloudcontract verloopt in plaats van via een API-sleutel.

Media is ongewoon breed en tegelijkertijd ongewoon beperkt. Tekst, afbeeldingen, video, audio en pdf gaan allemaal in één verzoek. De limieten zijn 100 MB aan inline base64, 50 MB voor een pdf en 15 MB per externe HTTPS-URL. YouTube-links worden niet geaccepteerd en gs://-URI's ook niet; je geeft verwijzingen naar geüploade bestanden, ondertekende URL's of bytes door.

Snelheidslimieten beginnen bij 200 verzoeken en 50.000 tokens per minuut in de gratis tier, stijgen naar 1.500 en één miljoen in Tier 1 en bereiken 5.000 verzoeken en vier miljoen tokens per minuut in Tier 2 zonder dagelijkse limiet op verzoeken. De gratis tier is kosteloos, maar volgens de documentatie wordt deze gebruikt om de producten van Google te verbeteren, waardoor deze niet in aanmerking komt voor alles wat onder een geheimhoudingsclausule valt.

De score, in het kort

Op de Artificial Analysis Decision Index v2.1 komt het model uit op 66 — 65,98 onafgerond — negende van de achttien beslissingsmodellen die de raad rangschikt. Het staat als enige eerste op twee van de zes componenten, AA-Omniscience-Decision v1.1 en HLE-MultiChoice v1.1, beide met een weging van 15%, en in de middenmoot op AA-Paperclip met 30% weging, de component die het grootste deel van de samengestelde score bepaalt. De gemeten kosten bedragen $345 per miljoen taken en de latentie 211 milliseconden per taak, tegenover een veldmediaan van 209. Google publiceerde bij de release geen eigen benchmarktabel; elk prestatiecijfer hier is afkomstig van de onafhankelijke raad, gemeten op diens eigen harness. De rekenkundige onderbouwing achter de 66 is een aparte kwestie en een apart artikel.

Het inpassen in een pipeline waar je al doorheen routeert

OrcaRouter ondersteunt gemini-decision-1 niet, en de reden is structureel in plaats van commercieel: een endpoint dat alleen waarschijnlijkheden levert, is geen doel voor chat-completions, dus er is niets dat een router in onze vorm achter één sleutel kan zetten. Het deel van de pipeline waar wij voor zijn, is het andere deel. Een beslissingsservice bestaat bijna altijd uit twee calls — iets stelt het kandidaatantwoord, de rubric of de shortlist op, en iets scoort het — en juist bij de call waarin wordt opgesteld, wordt de modelkeuze echt betwist.

Die aanroep kan draaien over meer dan 200 modellen op één endpoint, tegen de lijstprijs van de provider, doorgegeven met 0% markup, dus wanneer een leverancier een prijs verlaagt, staat het nieuwe bedrag dezelfde dag aan onze kant live in plaats van bij de volgende factureringscyclus. Model fusion verdient hier zijn plek op een manier waarop dat in een chat-UI niet zo is: twee drafters produceren concurrerende kandidaatantwoorden, en de Decisions API scoort beide tegen dezelfde rubric in één verzoek, waardoor een A/B-test een beslissing per record wordt.

Ook over failover moet je precies zijn. Automatische failover beschermt de generatieve aanroep — als de provider achter je draftingmodel fouten teruggeeft, wordt het verzoek omgeleid en blijft de pipeline draaien. De scoringaanroep kan er niet door worden beschermd, want daar is precies één plek om naartoe te sturen. Als het decisions-endpoint down is, ligt je pipeline plat, en geen enkele vorm van routering verandert dat. Ontwerp de draftinghelft veerkrachtig en accepteer dat de scoringhelft een afhankelijkheid is.

Kortom

De Decisions API is om één reden het adopteren waard, en dat is niet de positie op de ranglijst: hij brengt duizend roundtrips terug tot één gefactureerde input, en dat verandert welke vragen goedkoop te stellen zijn. Bouw erop voort als je problemen eruitzien als veel beoordelingen over één groot object — een contract, een claimdossier, een uur video — en reken erop dat je je prompts binnen één request houdt, want alles wat hem goedkoop maakt, gebeurt tussen het eerste en het laatste token van één enkele aanroep. Als je problemen eruitzien als één vraag over duizend kleine objecten, levert de envelop je niets op en is het inputtarief simpelweg drie keer wat een goedkoper beslissingsmodel rekent.