Decisions API: 400 risposte non fanno un workflow

Quattrocento domande in una sola richiesta. Dieci volte più veloce, secondo il produttore. Una tariffa che sembra fatta apposta per eliminare il costo delle microdecisioni. Presentata così, la Decisions API sembra la risposta a un problema che chi costruisce agenti conosce bene: passare più tempo ad aspettare un modello che a svolgere il lavoro vero. Ma c’è una differenza sostanziale tra accelerare una scelta e costruire un processo che sappia cosa farsene.

Il 22 ottobre 2026 OpenAI ha annunciato la disponibilità generale dell’endpoint POST /v1/decisions, basato su gpt-6-luna. La novità operativa non è che un modello sappia classificare: lo faceva già. È che ora esiste un contratto dedicato a risposte vincolate, con input testuali, immagini o JSON, fino a 400 domande per richiesta e una struttura di costo specifica. Il punto interessante, però, è capire dove finisce questo contratto e dove deve cominciare il software.

Un batch di 400 domande non è una sequenza di 400 decisioni

La documentazione tecnica della Decisions API è molto chiara su un dettaglio che rischia di sparire nei titoli: le domande inserite nello stesso array devono essere indipendenti. Se una decisione dipende dalla risposta precedente, servono richieste separate. Non è una nota marginale: è il confine tra un’ottimizzazione di trasporto e un motore di orchestrazione.

Immaginiamo un e-commerce che riceve la foto di un prodotto usato. Nella stessa richiesta possiamo chiedere se si vede un danno, a quale categoria appartiene l’oggetto e quanto è grave un difetto. Le tre valutazioni condividono l’evidenza iniziale, senza dipendere logicamente l’una dall’altra. È un buon candidato per il batching.

Diverso è il caso in cui la seconda domanda debba esistere soltanto se la prima ha rilevato un danno: prima verifico il difetto, poi scelgo la procedura di intervento, infine controllo se l’operazione è autorizzata. In quel caso non basta accodare tre domande nello stesso JSON e chiamarlo workflow. Occorre una macchina a stati, con precondizioni, transizioni, gestione degli errori e possibilità di fermarsi. Sono responsabilità dell’applicazione.

Il limite di 400 domande aumenta la densità di una richiesta, non garantisce una riduzione proporzionale del tempo totale né elimina la dipendenza causale tra passaggi. E soprattutto non trasforma un gruppo di inferenze in una transazione atomica.

Predicate, choice e score: il contratto vale più della risposta

L’API restituisce tre tipi principali di risposta. predicate stima una probabilità per una condizione; choice seleziona un valore da un insieme dichiarato; score valuta un input su livelli ordinati e produce una media pesata delle probabilità associate ai livelli. Non sono tre modi diversi di far scrivere al modello “sì” o “no”: sono tre contratti con semantiche differenti.

Un esempio pratico: un sistema di assistenza può usare choice per instradare una richiesta verso “fatturazione”, “supporto tecnico” oppure “altro”. Il valore “altro” non è una sconfitta del modello; è un ramo deliberato per i casi che non rientrano nella tassonomia. Per la gravità di un problema, invece, una scala ordinata consente uno score, ma un valore come 1,1 non è un livello discreto realmente osservato: è la media di una distribuzione. Se il codice lo tratta automaticamente come “medio”, sta introducendo una regola che l’API non ha deciso.

Anche confidence e probabilità per classe non sono una certificazione di correttezza. Devono essere confrontate con casi etichettati del proprio dominio. Una soglia può essere sensata per smistare ticket e del tutto inadeguata per autorizzare un rimborso, eseguire un comando o bloccare un cliente.

Un output tipizzato riduce l’ambiguità del formato. Non riduce automaticamente l’ambiguità del mondo su cui stai decidendo.

La policy deve restare deterministica

Prendiamo un agente che deve scegliere se richiedere un nuovo documento, aprire un ticket o avviare una procedura automatica. Il modello può classificare la richiesta e suggerire la prossima azione ammessa. Ma chi verifica l’identità dell’utente, il limite di spesa, lo stato corrente della pratica, i permessi e l’eventuale doppia esecuzione? Non un punteggio statistico.

Una progettazione robusta separa almeno tre responsabilità: interpretazione probabilistica dell’input, applicazione di regole verificabili e attuazione dell’azione. La prima può essere affidata alla Decisions API; la seconda appartiene al codice e alle policy; la terza richiede controlli su idempotenza, timeout e audit. Se le tre cose vengono fuse in un unico “decidi ed esegui”, il sistema può essere molto veloce nel commettere lo stesso errore.

Il tema si collega a quanto già discusso sugli agenti che non devono generare prosa per prendere una decisione. Qui il passo ulteriore non è dimostrare ancora quella distinzione: è progettare cosa succede dopo una risposta vincolata, quando quella risposta deve diventare un cambiamento reale.

La tariffa è semplice. Il costo del processo, meno

Per l’endpoint Decisions, OpenAI indica 0,10 dollari per milione di token di input non in cache e nessun addebito per i token di output. Nell’annuncio della disponibilità generale indica 0,01 dollari per milione di token di input letti dalla cache. Scritture in cache, maggiorazioni regionali e moltiplicatori per contesti lunghi seguono le regole applicabili: non si può moltiplicare il prezzo base per il numero di chiamate e dichiarare chiuso il preventivo.

Facciamo un conto puramente illustrativo: una decisione che consuma 2.000 token di input non in cache costa 0,0002 dollari di sola inferenza; un milione di decisioni identiche per consumo sarebbe pari a 200 dollari. È un calcolo aritmetico, non un benchmark di costo effettivo. Non include infrastruttura, retry, eventuali passaggi aggiuntivi, revisione umana e soprattutto le decisioni sbagliate.

Se una classificazione economica porta il 5% delle richieste in un percorso di recupero molto costoso, il confronto corretto non è soltanto prezzo per milione di token. È costo per richiesta conclusa correttamente, con un livello di qualità accettabile. La stessa logica vale per i tempi: il dato utile non è il record di latenza del modello, ma il tempo di completamento del flusso.

La cache non è magia: è una scelta su dove mettere il contesto

La disponibilità generale porta anche il prompt caching per il contesto condiviso. La guida specifica che il prefisso riutilizzabile si trova nell’input condiviso e che, per ottenere il beneficio, deve contenere almeno 1.024 token. Il contenuto delle singole questions, comprese eventuali immagini specifiche, non entra in quel prefisso. Le richieste possono beneficiare del breakpoint implicito al termine dell’input oppure usare breakpoint espliciti.

Questo suggerisce una progettazione precisa: mettere nel contesto stabile ciò che davvero resta identico fra richieste, mantenere separate le domande variabili e non confondere la presenza di un parametro di cache con un cache hit effettivo. La telemetria restituisce token letti e scritti in cache; sono già compresi nei token di input complessivi e non vanno sommati una seconda volta.

Una cache efficace può ridurre il costo e, in certi casi, la latenza. Ma se per ottenere il prefisso riutilizzabile si gonfia artificialmente ogni richiesta con contesto inutile, si sta ottimizzando un contatore a spese della progettazione. Prima si definisce l’evidenza necessaria; poi si verifica se conviene riusarla.

Il 10x è una dichiarazione del fornitore, non il tuo p95

OpenAI dichiara che Decisions può rispondere fino a dieci volte più rapidamente rispetto a GPT-6 Luna tramite Responses API. Nell’annuncio compaiono inoltre casi cliente con miglioramenti diversi, su workload e metriche diverse. Sono evidenze d’uso interessanti, ma non costituiscono un benchmark indipendente universale: non conosciamo per ogni applicazione identica distribuzione degli input, concorrenza, regione, rete, cache e politica dei retry.

Esistono confronti indipendenti pubblicati durante la beta, come un test su 400 decisioni che riporta differenze di accuratezza e costo rispetto a un altro modello. È un campione circoscritto, con dataset e metodologia propri; non dimostra quale servizio vincerà su tutte le richieste. Il suo valore è ricordare che la precisione va misurata sui casi d’uso, non dedotta dalla marca dell’endpoint.

Per un’adozione seria preparerei un dataset con classi sbilanciate, casi ambigui, esempi negativi, input degradati e modifiche minime che cambiano la risposta corretta. Misurerei accuracy per classe, falsi positivi e negativi, calibrazione delle probabilità, tasso di astensione, costo per decisione corretta, p50 e p95 sotto carico, errori di rete e retry. Un test con dieci esempi comodi serve a capire la sintassi dell’API, non a decidere un’architettura di produzione.

L’osservabilità deve distinguere richieste, domande e azioni

C’è un dettaglio contabile che racconta bene il problema. L’endpoint di usage organizzativo della Decisions API espone il numero di richieste al modello; una richiesta con più domande conta come una richiesta, non come il numero delle domande contenute. Se un cruscotto mostra solo il numero di chiamate, un batch di 400 valutazioni può sembrare un singolo evento operativo.

Per capire cosa accade servono almeno tre unità distinte: la richiesta inviata al provider, la singola domanda valutata e l’azione eventualmente eseguita dal sistema. Collegarle con identificativi e versioni di policy permette di rispondere a domande concrete: quale classificazione ha fatto scattare il fallback? Quante decisioni sono state scartate? Quanto tempo è passato tra risposta e azione? Quanti errori si sono verificati dopo una risposta formalmente valida?

Questo è anche il motivo per cui un orchestratore sottile ma verificabile conta più del numero di agenti o chiamate che riesce a far girare. Se perdi il collegamento tra decisione e conseguenza, hai accelerato l’inferenza e rallentato la diagnosi.

Quando adottarla, e quando lasciare decidere al codice

Ha senso provare Decisions quando la parte difficile è interpretare un input ambiguo e l’insieme delle risposte ammesse è limitato: classificazione documentale, routing, triage di ticket, priorità di revisione, analisi di un’immagine, scelta del prossimo ramo di una conversazione. Può essere utile anche in esperienze vocali: OpenAI documenta l’integrazione con GPT-Live per produrre decisioni durante il flusso.

Non è invece una scorciatoia per controlli deterministici: se una fattura supera un importo, se un utente ha un permesso, se una transazione è già stata eseguita o se una data cade oltre una scadenza, il software dispone già delle informazioni per rispondere con certezza. Chiedere a un modello di indovinare una regola che puoi calcolare è un modo costoso di introdurre un errore evitabile.

E quando la risposta richiede una spiegazione articolata, una sintesi o una generazione di contenuto, una API per decisioni vincolate non sostituisce automaticamente un modello generativo. I due strumenti risolvono problemi diversi; l’architettura migliore può usarli entrambi, ma solo dove aggiungono valore misurabile.

La velocità non è una strategia

La Decisions API rende più accessibile un componente che mancava in molte pipeline: un endpoint esplicitamente progettato per domande a risposta limitata, con costi e tempi potenzialmente adatti ai passaggi frequenti. È una novità concreta. Il rischio è usarla come l’ennesima scorciatoia per evitare di progettare il resto.

Un batch non sostituisce una macchina a stati. Una probabilità non sostituisce una policy. Un prezzo per token non sostituisce il costo per risultato. E un miglioramento di latenza, per quanto interessante, non prova che l’intero sistema sia diventato più affidabile.

La domanda da fare prima del prossimo endpoint non è “quanto è veloce?”. È quale decisione vogliamo automatizzare, quale evidenza la rende controllabile e chi impedisce che una risposta sbagliata diventi un’azione sbagliata? Il resto è implementazione. Importante, certo. Ma viene dopo.