Googles Decisions API besvarar 1 000 frågor och debiterar inte för utdata

Den billigaste delen av Gemini Decision 1 är den del som inte finns. Google placerade modellen bakom ett nytt Gemini Decisions API den 11 november 2026, och prissidan listar utdata som noll — inte billigt, inte rabatterat, frånvarande, eftersom POST /v1beta/decisions inte har någon prosa att generera. Du skickar ett block med delad indata plus upp till 1 000 typade frågor; du får tillbaka ett kalibrerat svar per fråga och inget annat. Siffran på resultattavlan fick uppmärksamheten på lanseringsdagen. Faktureringsraden är den som förändrar vad du bygger, och det är värt att göra matematiken innan du kopierar någons arkitekturdiagram.

Varje annat modellbeslut du har fattat under de senaste två åren har formats av två kostnader som drar i motsatta riktningar: indata som du vill skicka en gång, och utdata som du vill hålla kort. Den här endpointen tar bort den andra spänningen helt och ersätter den med en annan, intern för en enda förfrågan. När du väl ser var den nya spänningen ligger slutar resten av API:ets design – frågetaket, den delade kontexten, avsaknaden av cachning – att verka godtycklig.

Vad noll output-tokens gör med aritmetiken

Ta ett realistiskt dokumentpoängsättningsjobb: en policy eller ett kontrakt på 40 000 token och 1 000 frågor som du vill få besvarade om det. Ett anrop till Decisions API debiterar 40 000 indatatoken en gång, till $0,10 per miljon, vilket är fyra tiondels cent — $0,004 för alla tusen svar.

Ställ nu samma 1 000 frågor på det sätt du skulle ha ställt dem en vecka tidigare, som 1 000 separata generate-content-anrop. Varje anrop måste bära med sig dokumentet, eftersom en chat-endpoint inte kan hålla kvar det mellan anrop. Det är 40 miljoner indatatoken, eller $4.00 till samma pris per token, och gapet ökar när du lägger till de utdatatoken som vart och ett av dessa anrop skulle ha producerat. Enveloppen är inte en bekvämlighetsfunktion. Det är en tusenfaldig kostnadsskillnad för samma arbete, och den kommer från ett enda designval: frågor utvärderas mot en delad kontext i en enda omgång, inte en per tur och retur.

Den aritmetiken säger dig också vilken form av arbetsbelastning den här modellen vill ha. Många frågor om ett stort objekt, besvarade tillsammans. Om dina frågor gäller 1 000 olika objekt får du 1 000 förfrågningar och inga besparingar.

Kuvertet: 262 144 tokens, gemensamt och begränsat till 1 000 frågor

Kontextfönstret omfattar den gemensamma indatan och alla frågor i begäran tillsammans, vid 262,144 token. Inom den budgeten kan du ställa mellan 1 och 1,000 frågor. Det tal som spelar roll är den övre gränsen: 1,000 frågor i ett enda anrop är inte klassificerarens domän – det är en hel regelverksmotors bedömning komprimerad till en enda körning. En supportbiljett kan kontrolleras mot fyrtio policyklausuler; en lånehandling kan testas mot alla regler för kreditbedömning på en gång.

Två egenskaper hos förfrågans utformning är lätta att missa och dyra att upptäcka senare. Frågor utvärderas oberoende av varandra – svaret på en fråga påverkar inte nästa, så du kan inte kedja resonemang genom att ställa en följdfråga som beror på ett tidigare svar. Och modellen ser aldrig dina frågenycklar, bara den instruktionstext du skriver, så nycklarna är till för din egen bokföring och instruktionerna måste stå på egna ben.

Tre frågeformer, och fällan i var och en

• Ja/nej — noul-typen returnerar en sannolikhet mellan 0,01 och 0,99 plus en konfidenspoäng. Gränsen är klämd i båda ändar, så ett routingtröskelvärde satt till 0,995 kommer aldrig att utlösas, oavsett hur säker modellen är. Välj tröskelvärden inom det intervall som API:et faktiskt kan returnera.

• Val — två till 255 namngivna alternativ, som returnerar det vinnande alternativet, en sannolikhet för varje alternativ som summerar till ett, och en konfidens. Innan poängsättningen sorterar API:t dina alternativnycklar alfabetiskt i UTF-8-byteordning, vilket innebär att JSON-nyckelordningen är irrelevant och att en exakt oavgjord situation avgörs till förmån för den nyckel som sorteras först. Googles vägledning följer av detta: döp ditt uppsamlingsalternativ till other, eftersom ett namn som none_of_the_above sorteras före de flesta verkliga kategorier och kommer att vinna oavgjorda situationer som det borde förlora.

• Poäng — två till 255 ordnade bedömningsnivåer, där två till tio rekommenderas. Returvärdet är en sannolikhetsviktad förväntad nivå, och eftersom det förväntade värdet medelvärdesbildar arrayindex i stället för etiketterna, ger en skala skriven som 1/10/100/1000 ett tal som inte finns på din skala. Håll bedömningsnivåerna jämnt fördelade sett till index, eller konvertera det förväntade indexet tillbaka till en etikett själv.

Vad dokumentationen listar som otillgängligt

Luckorna pekar alla åt samma håll: detta är en endpoint för engångsanrop utan något runt omkring. Det finns ingen cachelagring av kontext, så ett policydokument som återanvänds mellan förfrågningar debiteras igen i sin helhet varje gång. Det finns inget Batch API, vilket utesluter en nattlig genomgång av förra årets ärenden till halva priset. Det finns ingen Flex- eller Priority-nivå. Modellen finns endast på Gemini Developer API, i version v1beta, utan någon Vertex AI-listning i dokumentationen som Google levererade – en detalj som spelar roll för alla vars upphandling går via ett molnavtal i stället för en API-nyckel.

Media är ovanligt brett och ovanligt begränsat samtidigt. Text, bild, video, ljud och PDF går alla i en och samma begäran. Gränserna är 100 MB för inbäddad base64, 50 MB för en PDF och 15 MB per extern HTTPS-URL. YouTube-länkar accepteras inte, och inte heller gs://-URI:er; du skickar referenser till uppladdade filer, signerade URL:er eller byte.

Hastighetsgränserna börjar på 200 förfrågningar och 50 000 tokens per minut på gratisnivån, trappas upp till 1 500 och en miljon på nivå 1 och når 5 000 förfrågningar och fyra miljoner tokens per minut på nivå 2 utan dagligt tak för förfrågningar. Gratisnivån är kostnadsfri men dokumenteras som använd för att förbättra Googles produkter, vilket diskvalificerar den för allt som omfattas av en sekretessklausul.

Ställningen, kortfattat

På Artificial Analysis Decision Index v2.1 landar modellen på 66 – 65,98 oavrundat – på nionde plats av de arton beslutsmodeller som panelen rangordnar. Den är ohotad etta på två av de sex komponenterna, AA-Omniscience-Decision v1.1 och HLE-MultiChoice v1.1, båda viktade 15 %, och ligger i mitten av tabellen på AA-Paperclip med 30 % vikt, vilket är komponenten som avgör största delen av sammanvägningen. Uppmätt kostnad är 345 dollar per miljon uppgifter och latensen 211 millisekunder per uppgift, mot ett medianvärde för fältet på 209. Google publicerade ingen egen benchmarktabell i samband med lanseringen; varje prestandasiffra här är den oberoende panelens, i deras egen testrigg. Aritmetiken bakom 66:an är en separat fråga och en separat artikel.

Att passa in det i en pipeline som du redan dirigerar

OrcaRouter har inte gemini-decision-1, och skälet är strukturellt snarare än kommersiellt: en endpoint som bara ger sannolikheter är inte ett mål för chat-completions, så det finns inget för en router av vår typ att lägga bakom en och samma nyckel. Den halva av pipelinekedjan som vi riktar oss mot är den andra halvan. En beslutstjänst är nästan alltid två anrop – något tar fram kandidatsvaret, bedömningskriterierna eller kortlistan, och något poängsätter det – och det är i utkastanropet som modellvalet faktiskt är omtvistat.

Det anropet kan köras mot fler än 200 modeller på en enda slutpunkt, till leverantörens listpris som vidarebefordras med 0 % påslag, så när en leverantör sänker ett pris är det nya priset aktivt hos oss samma dag i stället för vid nästa faktureringsperiod. Modellsammanslagning har sin plats här på ett sätt som den inte har i ett chattgränssnitt: två utkastmodeller producerar konkurrerande kandidatsvar, och Decisions API poängsätter båda mot samma bedömningsmall i en enda begäran, vilket förvandlar ett A/B-test till ett beslut per post.

Det är också värt att vara precis när det gäller failover. Automatisk failover skyddar det generativa anropet – om leverantören bakom din utkastmodell returnerar fel omdirigeras begäran och pipeline fortsätter att rulla. Det kan inte skydda poängsättningsanropet, eftersom det finns exakt en plats att skicka det till. Om beslutsslutpunkten är nere är din pipeline nere, och ingen mängd routning ändrar på det. Designa utkastdelen så att den är motståndskraftig och acceptera att poängsättningsdelen är ett beroende.

Slutsatsen

Decisions API är värt att anamma av en anledning, och det är inte placeringen på resultattavlan: det kollapsar tusen rundturer till en enda debiterad indata, och det förändrar vilka frågor som är billiga att ställa. Bygg vidare på det om dina problem ser ut som många bedömningar över ett stort objekt – ett avtal, en skadeakt, en timmes video – och räkna med att hålla dina prompter inom en enda förfrågan, eftersom allt som gör det billigt sker mellan första och sista token i ett enda anrop. Om dina problem ser ut som en fråga över tusen små objekt ger kuvertet dig ingenting, och indatatakten är helt enkelt tre gånger vad en billigare beslutsmodell tar.