L'API Decisions di Google risponde a 1.000 domande e non fattura alcun output

La parte più economica di Gemini Decision 1 è quella che non esiste. Google ha messo il modello dietro una nuova Gemini Decisions API l'11 novembre 2026, e la pagina dei prezzi indica l'output a zero — non economico, non scontato, assente, perché POST /v1beta/decisions non ha prosa da generare. Invii un blocco di input condiviso più fino a 1.000 domande tipizzate; ricevi indietro una risposta calibrata per domanda e nient'altro. Il numero della classifica ha attirato l'attenzione il giorno del lancio. La riga di fatturazione è quella che cambia ciò che costruisci, e vale la pena fare i calcoli prima di copiare il diagramma architetturale di qualcun altro.

Ogni altra decisione relativa al modello che hai preso negli ultimi due anni è stata determinata da due costi che tirano in direzioni opposte: input che vuoi inviare una sola volta e output che vuoi mantenere breve. Questo endpoint elimina del tutto la seconda tensione e la sostituisce con una diversa, interna a una singola richiesta. Una volta capito dove si colloca la nuova tensione, il resto del design dell'API — il limite massimo delle domande, il contesto condiviso, l'assenza di caching — smette di sembrare arbitrario.

Cosa fanno zero token di output all'aritmetica

Prendi un caso realistico di scoring di documenti: una policy o un contratto da 40.000 token e 1.000 domande a cui vuoi ottenere risposta. Una singola richiesta all'API Decisions fattura 40.000 token di input una volta sola, a $0,10 per milione, cioè quattro decimi di centesimo — $0,004 per tutte e mille le risposte.

Ora poni le stesse 1.000 domande come le avresti poste una settimana prima, sotto forma di 1.000 chiamate separate a generate-content. Ogni chiamata deve trasportare il documento, perché un endpoint chat non ha modo di mantenerlo tra una chiamata e l'altra. Sono 40 milioni di token di input, ovvero $4.00 alla stessa tariffa per token, e il divario aumenta una volta aggiunti i token di output che ciascuna di quelle chiamate avrebbe prodotto. L'envelope non è una funzione di comodità. È una differenza di costo di mille volte sullo stesso lavoro, e deriva da un'unica scelta progettuale: le domande vengono valutate rispetto a un unico contesto condiviso in un'unica passata, non una per ogni round trip.

Questa aritmetica ti dice anche la forma del carico di lavoro che questo modello richiede. Molte domande su un unico grande oggetto, a cui si risponde insieme. Se le tue domande riguardano 1.000 oggetti diversi, ottieni 1.000 richieste e nessun risparmio.

L'involucro: 262.144 token, condivisi e limitato a 1.000 domande

La finestra di contesto copre insieme l'input condiviso e ogni domanda nella richiesta, a 262,144 token. All'interno di quel budget puoi porre tra 1 e 1,000 domande. Il numero che conta è il limite superiore: 1,000 domande in una singola chiamata non sono territorio da classificatore, sono la quantità di giudizio di un motore di regole compressa in un'unica passata. Un ticket di supporto può essere verificato rispetto a quaranta clausole di policy; una pratica di prestito può essere testata rispetto a ogni regola di sottoscrizione in una volta.

Due proprietà della struttura della richiesta sono facili da trascurare e costose da scoprire in seguito. Le domande vengono valutate in modo indipendente — la risposta a una domanda non condiziona la successiva, quindi non puoi concatenare il ragionamento ponendo una domanda di approfondimento che dipenda da una risposta precedente. Inoltre il modello non vede mai le chiavi delle tue domande, ma solo il testo delle istruzioni che scrivi, quindi le chiavi servono solo a te per tenere traccia e le istruzioni devono essere autosufficienti.

Tre forme di domanda, e la trappola dentro ciascuna

• Sì/no — il tipo noul restituisce una probabilità compresa tra 0.01 e 0.99 più un punteggio di confidenza. Il limite è bloccato a entrambe le estremità, quindi una soglia di instradamento impostata a 0.995 non scatterà mai, indipendentemente da quanto il modello sia sicuro. Scegli soglie all'interno dell'intervallo che l'API può effettivamente restituire.

• Scelta — da due a 255 opzioni denominate, che restituisce l'opzione vincente, una probabilità per ogni opzione la cui somma è uno e un livello di confidenza. Prima del punteggio, l'API ordina le chiavi delle opzioni alfabeticamente in ordine di byte UTF-8, il che significa che l'ordine delle chiavi JSON è irrilevante e un pareggio esatto si risolve verso la chiave che viene ordinata per prima. La guida di Google deriva da ciò: assegna alla tua opzione catch-all il nome other, perché un nome come none_of_the_above si colloca prima della maggior parte delle categorie reali e vincerà pareggi che dovrebbe perdere.

• Punteggio — da due a 255 livelli di rubrica ordinati, con due-dieci consigliati. Il valore restituito è un livello atteso ponderato per probabilità e, poiché il valore atteso calcola la media degli indici dell'array anziché delle etichette, una scala scritta come 1/10/100/1000 produce un numero che non appartiene alla tua scala. Mantieni la rubrica uniformemente spaziata in termini di indici oppure converti tu stesso l'indice atteso in un'etichetta.

Ciò che la documentazione elenca come non disponibile

Le lacune vanno tutte nella stessa direzione: questo è un endpoint a chiamata singola, senza nulla attorno. Non c’è caching del contesto, quindi un documento di policy riutilizzato tra richieste viene addebitato di nuovo per intero ogni volta. Non esiste la Batch API, il che esclude una scansione notturna a metà prezzo dei ticket dell’anno scorso. Non esiste il livello Flex o Priority. Il modello è disponibile solo sulla Gemini Developer API, alla versione v1beta, senza alcuna voce Vertex AI nella documentazione fornita da Google — un dettaglio che conta per chiunque abbia un approvvigionamento che passa attraverso un contratto cloud anziché una chiave API.

I media sono insolitamente ampi e insolitamente limitati allo stesso tempo. Testo, immagini, video, audio e PDF vanno tutti in un'unica richiesta. I limiti sono 100 MB di base64 inline, 50 MB per un PDF e 15 MB per ogni URL HTTPS esterno. I link YouTube non sono accettati e nemmeno gli URI gs://; si passano riferimenti a file caricati, URL firmati o byte.

I limiti di frequenza partono da 200 richieste e 50.000 token al minuto nel piano gratuito, passano a 1.500 e un milione al Tier 1, e raggiungono 5.000 richieste e quattro milioni di token al minuto al Tier 2 senza limite giornaliero di richieste. Il piano gratuito è gratuito ma documentato come utilizzato per migliorare i prodotti Google, il che lo rende inutilizzabile per qualsiasi cosa soggetta a una clausola di riservatezza.

Il punteggio, in breve

Sull'Artificial Analysis Decision Index v2.1 il modello si colloca a 66 — 65,98 senza arrotondamento — nono tra i diciotto modelli decisionali classificati dalla board. È primo assoluto su due delle sei componenti, AA-Omniscience-Decision v1.1 e HLE-MultiChoice v1.1, entrambe ponderate al 15%, e a metà classifica su AA-Paperclip, con peso del 30%, che è la componente che determina la maggior parte del composito. Il costo misurato è di $345 per milione di attività e la latenza di 211 millisecondi per attività, rispetto a una mediana del settore di 209. Google non ha pubblicato alcuna tabella di benchmark propria con il rilascio; ogni cifra prestazionale qui riportata è quella della board indipendente, sul suo harness. L'aritmetica dietro il 66 è una questione separata e un articolo separato.

Inserirlo in una pipeline che già instradi

OrcaRouter non supporta gemini-decision-1, e la ragione è strutturale più che commerciale: un endpoint che restituisce solo probabilità non è una destinazione di chat-completions, quindi non c'è nulla che un router come il nostro possa mettere dietro un'unica chiave. La metà della pipeline a cui ci dedichiamo è l'altra metà. Un servizio decisionale consiste quasi sempre in due chiamate — qualcosa redige la risposta candidata, la rubrica o la shortlist, e qualcosa la valuta — ed è la chiamata di redazione quella in cui la scelta del modello è realmente contesa.

Quella chiamata può essere eseguita su oltre 200 modelli su un unico endpoint, al prezzo di listino del provider trasferito con 0% di ricarico, così quando un fornitore taglia un prezzo il nuovo valore è attivo dalla nostra parte lo stesso giorno anziché al ciclo di fatturazione successivo. La fusione di modelli qui si guadagna il suo posto in un modo in cui non accade in una UI di chat: due redattori producono risposte candidate concorrenti, e la Decisions API le valuta entrambe rispetto alla stessa rubrica in un'unica richiesta, il che trasforma un test A/B in una decisione per singolo record.

Vale la pena essere precisi anche sul failover. Il failover automatico protegge la chiamata generativa — se il provider dietro il tuo modello di redazione restituisce errori, la richiesta viene reindirizzata e la pipeline continua ad avanzare. Non può proteggere la chiamata di valutazione, perché c'è esattamente un solo posto a cui inviarla. Se l'endpoint delle decisioni è inattivo, la tua pipeline è inattiva, e nessuna quantità di routing lo cambia. Progetta la metà della redazione perché sia resiliente e accetta che la metà della valutazione è una dipendenza.

In definitiva

L'API Decisions vale la pena adottarla per un motivo, e non è la posizione in classifica: riduce mille andate e ritorni a un unico input fatturato, e questo cambia quali domande è economico porre. Costruisci su di essa se i tuoi problemi assomigliano a molti giudizi su un unico grande oggetto — un contratto, un fascicolo di sinistro, un'ora di video — e aspettati di mantenere i tuoi prompt all'interno di una sola richiesta, perché tutto ciò che la rende economica accade tra il primo e l'ultimo token di una singola chiamata. Se i tuoi problemi assomigliano a una domanda su mille piccoli oggetti, l'involucro non ti offre nulla e la tariffa di input è semplicemente tre volte quella addebitata da un modello decisionale più economico.