GPT-Image-2.6 vs GPT-Image-2.5: la sostituzione è una stringa, la fattura no

Migrare da GPT-Image-2.5 a GPT-Image-2.6 è, a livello API, l’aggiornamento meno drammatico che OpenAI abbia rilasciato in tutto l’anno. Stessi due endpoint, stesso listino tariffe, stessa ripartizione Flare contro Sunburst. Cambia la stringa del modello e nient’altro deve cambiare. Questa è anche la trappola. GPT-Image-2.6 aggiunge un parametro che GPT-Image-2.5 non ha mai avuto — una manopola della complessità — e ometterlo non lo disattiva. Per impostazione predefinita è su alto. Una pipeline che scambia la stringa e va in produzione non sta acquistando la stessa quantità di lavoro per la stessa somma di denaro; sta acquistando più lavoro, ed è per questo che il primo report dei costi dopo una migrazione può cambiare anche se le tariffe pubblicate non sono cambiate.

Entrambi i modelli sono diventati disponibili a livello generale con gli stessi termini commerciali, ed è questo che rende insolito questo confronto. Non c’è alcuna discussione sul prezzo da fare. La questione riguarda interamente dove viene impiegato il nuovo lavoro e se il tuo traffico è strutturato in modo da trarne beneficio.

La superficie API è davvero un drop-in — con un buco al suo interno.

OpenAI ha rilasciato GPT-Image-2.6 il 4 novembre 2026 come due modelli API anziché uno, ereditando la struttura stabilita con la 2.5. Il livello orientato al dettaglio e alla coerenza è GPT-Image-2.6 Sunburst; il livello di velocità è GPT-Image-2.6 Flare. I loro predecessori, GPT-Image-2.5 Sunburst e GPT-Image-2.5 Flare, mantengono gli stessi nomi e lo stesso rapporto tra loro.

• Stringhe modello — gpt-image-2.6-flare e gpt-image-2.6-sunburst sostituiscono gpt-image-2.5-flare e gpt-image-2.5-sunburst, stessa logica di denominazione, una per la latenza e una per il dettaglio.

• Endpoint — /v1/images/generations e /v1/images/edits, invariati. Nessun nuovo endpoint da integrare.

• Tariffe — 5 $ per milione di token di input di testo, 8 $ per milione di token di input immagine, 30 $ per milione di token di output immagine, con input in cache a 1,25 $ e 2,00 $. Identiche byte per byte alla 2.5.

• Livelli di qualità — basso, medio, alto, xhigh, max e auto. La stessa scala.

• Dimensioni consigliate — 1024×1024, 1536×1024 e 1024×1536 restano in testa alla documentazione, con dimensioni personalizzate accettate in multipli di 16 e rapporti d'aspetto da 1:3 a 3:1.

• La lacuna — 2.6 non è disponibile tramite la Batch API. Se il tuo consumo per le immagini si basa su un job notturno a metà prezzo, quel job non si sposta ancora.

Quell'ultima riga è quella che in effetti rompe qualcosa. Tutto ciò che sta sopra è una sostituzione di stringa e un'esecuzione di regressione. Il divario sul batch è un ostacolo architetturale proprio per i carichi di lavoro — cataloghi di massa, backfill notturni, generazione A/B su larga scala — in cui uno sconto del 50% è la ragione stessa per cui il carico di lavoro esiste.

La manopola della complessità è la vera funzionalità, e il suo valore predefinito è la sorpresa

La complessità è un nuovo asse che si affianca alla qualità anziché collocarsi al suo interno, e la distinzione è più importante di quanto sembri. La qualità controlla il rendering: quanti token di output vengono impiegati nell'immagine. La complessità controlla la pianificazione: quanto ragionamento svolge il modello prima di iniziare il rendering. Puoi richiedere un'immagine a bassa qualità di una scena complessa, oppure un'immagine ad alta qualità di una scena semplice, e nella 2.6 queste sono richieste davvero separate.

La documentazione è esplicita sul fatto che omettere il parametro ne imposta il valore predefinito su high. Quindi un chiamante che migra una richiesta 2.5 cambiando solo il nome del modello e nient'altro opta silenziosamente per il budget di pianificazione massimo a ogni chiamata. Non è un bug — è il valore predefinito sensato per un modello il cui punto di forza è pensare di più — ma significa che il primo mese di traffico 2.6 non è un confronto omogeneo con l'ultimo mese di traffico 2.5.

C'è almeno un dato pubblico che punta nella stessa direzione. Un test pratico su tre immagini pubblicato il 4 novembre ha riportato $0.1245 per l'output di 2.6 contro $0.0446 per le stesse immagini fisse su 2.5 — circa il triplo, su un tariffario che non è cambiato. Tre immagini non sono un benchmark e non dovrebbero essere citate come tale; il campione è di gran lunga troppo piccolo per stabilire un moltiplicatore. Ciò che fa, però, è dimostrare il meccanismo, e il meccanismo è documentato: più token di pianificazione per richiesta, attivi per impostazione predefinita, fatturati a $30 per milione.

Se devi fare un solo passo operativo da questo articolo, fai questo. Imposta esplicitamente la complessità — medium è un'ipotesi iniziale ragionevole per replicare il comportamento dell'era 2.5 — e poi misura i token di output per richiesta prima e dopo. Non misurare i dollari per richiesta. I dollari per richiesta ti diranno che la rate card non è cambiata, cosa che già sapevi. I token per richiesta ti diranno se il modello sta facendo più lavoro di quanto hai chiesto.

Dove si traduce realmente il presunto aumento di velocità del 50%

OpenAI descrive GPT-Image-2.6 come circa il 50% più veloce nel complesso, ma i dati per livello sono molto più interessanti del titolo, e sono numeri forniti direttamente dal vendor, non misurati in modo indipendente. Flare è riportato a circa 2,6× rispetto al suo predecessore, con rendering di bassa qualità che si completano in appena sei secondi. Sunburst è riportato a circa 1,15×.

Quei due numeri descrivono due aggiornamenti completamente diversi. Se la tua pipeline esegue Flare per l'iterazione — esplorazione delle miniature, ottimizzazione dei prompt, qualsiasi attività in cui una persona attende il risultato — 2.6 rappresenta una svolta e la migrazione si ripaga da sola già solo in termini di attenzione. Se la tua pipeline esegue Sunburst per la qualità dell'output finale, un miglioramento della latenza del 15% rientra nell'intervallo della variabilità tra un'esecuzione e l'altra sulla maggior parte delle configurazioni di hosting, e la velocità non è affatto un motivo per migrare.

Vale la pena segnalarlo con onestà: lo stesso piccolo test pratico che ha riportato l'inflazione dei token ha anche riportato che 2.6 è più lento di 2.5 sulle sue tre immagini, il che contraddice quanto dichiarato dal fornitore. Con n=3 si tratta di rumore, non di una confutazione. Ma è un promemoria del fatto che «50% più veloce» è un dato aggregato da presentazione di lancio tra livelli di qualità, mentre una pipeline reale vede un solo livello con un'unica impostazione di qualità.

Nessuno ha ancora totalizzato 2,6 e 2,5 è ancora in testa

Questa è la parte del confronto che gran parte della copertura sorvola. Artificial Analysis, con le sue board AA-Image-T2I v2.1 e di editing, non aveva affatto una riga per GPT-Image-2.6 quando è stata consultata il 5 novembre 2026. Non un punteggio basso — nessuna riga.

Quello che quei tabelloni mostrano è che il modello che viene sostituito li sta ancora vincendo:

• Da testo a immagine — GPT-Image-2.5 Sunburst (max) 1.224 Elo da 13.153 voti, primo posto. GPT-Image-2.5 Flare (max) 1.207 da 12.498, secondo posto. GPT Image 2 (high) 1.188, terzo posto.

• Modifica immagini — GPT-Image-2.5 Sunburst (max) 1.200 da 18.370 voti, primo. GPT-Image-2.5 Flare (max) 1.183 da 19.259, terzo dietro MAI-Image-2.7-Preview a 1.197.

Il materiale di lancio di OpenAI cita Design Arena per un primo posto di 2.6 Sunburst. Si tratta di un'affermazione reale su una classifica reale, ma è un bacino di valutatori diverso su una scala diversa, e un fornitore che sceglie la classifica che lusinga il proprio rilascio non è una prova di nulla che un acquirente possa usare. Il dato comparabile, di terze parti e votato per 2.6 non esiste ancora. Finché non esisterà, la posizione difendibile è che 2.5 è il modello di immagini con il punteggio indipendente più alto su entrambe le classifiche principali e che 2.6 non è comprovato — migliore nei modi specifici in cui OpenAI afferma che sia migliore, e non misurato in tutto il resto.

Una migrazione che si completa in un pomeriggio

La sostituzione costa così poco che l'approccio sensato non è una migrazione big-bang, ma una migrazione misurata, condotta sui propri prompt anziché sul set di prompt di benchmark di qualcun altro.

Inizia fissando la complessità a un valore scelto da te, così il cambiamento è un cambiamento che hai fatto tu anziché uno arrivato per impostazione predefinita. Poi riesegui un paio di centinaia di prompt reali dai tuoi log di produzione — non i prompt puliti delle fixture di test, quelli disordinati con refusi e rapporti d'aspetto scomodi. Confronta due numeri: token di output per immagine accettata e immagini accettate ogni cento tentativi. È il secondo il numero in cui si vedrebbe un miglioramento della coerenza, ed è quello che determina davvero se l'aggiornamento fa risparmiare, perché un'immagine che scarti costa l'intero budget di token e non restituisce nulla.

Mantieni un percorso di fallback alla 2.5 per il lavoro in batch, dato che la 2.6 non può ancora servirlo. E considera qualsiasi traffico Sunburst una questione di qualità piuttosto che di velocità: se il tasso di accettazione non si muove, hai comprato un miglioramento della latenza del 15% e un conto di pianificazione più salato.

Quando restare su 2.5 è la risposta giusta

Tre casi sono abbastanza chiari da nominare. I carichi di lavoro batch dovrebbero restare, perché 2.6 non è sulla Batch API e 2.5 sì. Le pipeline di qualità Sunburst dovrebbero restare a meno che il test del tasso di accettazione non dica il contrario, perché un aumento di velocità di 1,15× non ripaga un cambiamento del modello di costo. E chiunque abbia già un tasso di accettazione accettabile dovrebbe restare, perché le nuove capacità — esportazione SVG, GIF animate, editing guidato dal markup — sono funzionalità aggiuntive, non miglioramenti di qualità, e ti servono solo se hai un prodotto da consegnare che le richiede.

L'aggiornamento è autentico. È solo concentrato sulla latenza di Flare e su nuovi formati di output, e questi ambiti sono più ristretti di quanto implichi «un nuovo modello».

Disponibilità e la scomoda forma di una migrazione divisa

OrcaRouter include oggi GPT-Image-2.5 Flare e GPT-Image-2.5 Sunburst al prezzo di listino con 0% di ricarico, quindi la tariffa del provider è quella che paghi, senza alcun margine aggiunto. GPT-Image-2.6 non è nel catalogo al 5 novembre 2026 — un giorno dopo il lancio — il che rende il problema pratico immediato una questione di routing più che di modellistica: durante il bake-off, il traffico su 2.5 gira su un'unica chiave con failover automatico, mentre il traffico su 2.6 va direttamente a OpenAI con un secondo contratto e una seconda fattura.

Vale la pena pianificare tenendo conto di questa divisione, anziché scoprirla. Controlla il catalogo prima di impegnare un percorso di produzione su 2.6, perché la parità del giorno di lancio non è qualcosa che qualsiasi router possa promettere su un modello che ha ventiquattro ore. Quando arriverà, la regola del pass-through significa che la tariffa del fornitore è quella che pagherai lo stesso giorno — una variazione di prezzo da parte di OpenAI arriverebbe senza una rinegoziazione da parte nostra — ma fino ad allora, la lettura onesta della situazione è che 2.5 è instradabile e 2.6 no.

Il che è un altro argomento a favore di una migrazione grande quanto un pomeriggio rispetto a una grande quanto un fine settimana. Esegui 2.5 attraverso il router, mantieni stabile la tua baseline di costi e aggiungi 2.6 dietro un flag dopo aver misurato cosa fa il default di complessità ai tuoi conteggi di token. Il modello non va da nessuna parte, e l'endpoint batch arriverà prima del tuo prossimo ciclo di pianificazione trimestrale.