GPT-6.1 Sol vs GPT-6 Sol: cosa ha fruttato una settimana di lavoro extra, e cosa no

Se hai GPT-6 Sol in produzione oggi e stai cercando di decidere se GPT-6.1 Sol valga una migrazione, la risposta dipende interamente da quale dei tuoi costi è maggiore — e i due modelli sono progettati in modo che la risposta non sia quasi mai "entrambi". GPT-6 Sol è stato rilasciato il 22 settembre 2026 a $2,00 per milione di token in input, $0,20 in cache e $10,00 in output. GPT-6.1 Sol è stato rilasciato il 29 settembre 2026 a $2,00 input, $0,10 in cache e $10,00 output, con un miglioramento dichiarato dal fornitore di 6,4 punti percentuali su complesse attività di ingegneria del software a uno sforzo di ragionamento inferiore. I prezzi di input e output non sono cambiati. La tariffa della cache si è dimezzata. Quella singola riga modificata è l'intero caso finanziario, e tutto il resto è un argomento di capacità che, a questo punto della vita del rilascio, proviene da una sola fonte.

Tre cose sono cambiate. Una di queste è un disegno di legge.

Togli il marketing e il delta tra questi due deployment è abbastanza breve da starci in testa.

• Input in cache — 0,10 $ per milione di token su GPT-6.1 Sol contro 0,20 $ su GPT-6 Sol. Misurato anziché dichiarato, e l'unico cambiamento che si traduce in aritmetica.
• Capacità, secondo il fornitore — OpenAI dichiara un vantaggio di 6,4 punti su DeepSWE v1.1 con uno sforzo di ragionamento e un costo inferiori, più del doppio del punteggio su Terminal-Bench Science 0.1 allo sforzo massimo, sette punti sul set offline di OSWorld 2.0 allo sforzo massimo, 4,8 punti su AutomationBench a sforzo medio, e un tasso di errori fattuali che scende dall'11,4% al 7,7% su un set di prompt deliberatamente atto a indurre errori. Il tutto non riprodotto.
• Scala di ragionamento — GPT-6.1 Sol supporta basso, medio, alto, xhigh e massimo, e non supporta nessuno; GPT-6 Sol li supporta tutti e sei. Questo è il delta che rompe il codice, ed è quello che nessuno mette in un post di lancio.

Tutto il resto è identico o quasi: la stessa finestra di contesto da 1.050.000 token, lo stesso limite di output di 128.000 token, la stessa tariffa di scrittura in cache di 2,50 $, la stessa soglia di riprezzamento di 272K token oltre la quale un'intera richiesta viene fatturata a 2× per input e cache e a 1,5× per output, lo stesso requisito dell'API Responses per il tool calling e la stessa assenza di supporto al fine-tuning. Il knowledge cutoff è passato dal 20 al 30 aprile 2026 — dieci giorni, il tipo di cifra che ti dice quanto questo sia stato un adattamento piuttosto che una ricostruzione.

Perché la linea di cache vale più di quanto sembri

Una lettura della cache dimezzata è una strana cosa con cui aprire un aggiornamento di prodotto, finché non si guarda a cosa assomiglia davvero il traffico degli agenti. Un ciclo dell'agente reinvia un prefisso stabile — prompt di sistema, schemi degli strumenti, contesto recuperato, cronologia della conversazione — a ogni turno, e in una sessione lunga lo stesso prefisso viene fatturato decine o centinaia di volte. È il traffico in cui un tasso di cache smette di essere un errore di arrotondamento e diventa la voce dominante in fattura.

Fai i conti su una singola sessione agente lunga. Supponi un prefisso di 120.000 token riutilizzato per 40 turni, quindi 4,8 milioni di token di input in cache per sessione, più un modesto 150.000 token di output nuovi. Su GPT-6 Sol le letture in cache costano $0,96 e l'output $1,50 — circa $2,46 per sessione. Su GPT-6.1 Sol la stessa sessione costa $0,48 per le letture in cache e gli stessi $1,50 per l'output: circa $1,98. Per sessione la differenza è di 48 centesimi, il che non è un fattore decisionale. Moltiplicala per centomila sessioni al mese e sono $48.000 — il che invece lo è.

Due avvertenze mantengono la cosa onesta. Le letture dalla cache vengono fatturate alla tariffa della cache solo quando il prefisso va effettivamente a segno, quindi il risparmio effettivo è il tasso di hit moltiplicato per la differenza, non la differenza stessa. E il prefisso deve essere sotto i 272.000 token perché le tariffe standard si applichino: supera quel limite e l'intera richiesta viene ritariffata a 2× per input e cache e 1,5× per output, il che può vanificare un risparmio di 10 centesimi sul prefisso. Le sessioni a contesto lungo sono quelle in cui è meno probabile che i calcoli della cache assomiglino alla brochure.

Il gap di benchmark è reale, e viene da un solo posto.

Il post di lancio di OpenAI è insolitamente specifico riguardo alle sue valutazioni, il che è un punto a suo favore, e ognuno di quei numeri è il fornitore che valuta il proprio modello, il che è il punto a sfavore. Il pattern che li accomuna è coerente: il confronto che ricorre è sempre con GPT-6 Astra, e il confronto con Astra è sempre un confronto sui costi. Su DeepSWE v1.1 l'affermazione è che eguaglia Astra a circa un quinto del costo. Su GDP.pdf, si avvicina allo stato dell'arte di Astra a circa un quinto del costo per attività. Su OSWorld 2.0, entro 2,1 punti da Astra a circa un settimo del costo per attività. Sulla fattualità, entro 1,9 punti da Astra a meno di un quinto del costo per attività. Non è un caso di stesura; è la tesi del prodotto, ed è una tesi sul prezzo, non sulla leadership di capacità.

L'unico punto in cui OpenAI rinuncia al proprio inquadramento merita credito: su Terminal-Bench Science 0.1 dichiara senza giri di parole che GPT-6 Astra detiene ancora il punteggio più alto tra i modelli testati, al 68,1%, e che dovrebbe essere usato per la ricerca scientifica più ardua. Un post di lancio che ti dice quando comprare il fratello più costoso è un post di lancio con un po' di disciplina.

Nello specifico, nei confronti di GPT-6 Sol, lo stato onesto del confronto è questo: non esiste un punteggio indipendente per nessuno dei due modelli con questa configurazione. Artificial Analysis dispone di una valutazione completa di GPT-6 Sol al massimo sforzo di ragionamento: un Intelligence Index di 48, 1,06 $ per attività dell'indice, 77 milioni di token di output generati rispetto a una mediana di classifica di 88 milioni, e un Coding Agent Index di 57 a 2,99 $ per attività. Non ha alcuna voce per GPT-6.1 Sol al 30 settembre; lo slug del modello restituisce 404 e la stringa non compare nella classifica in tempo reale. Quindi l'unico confronto misurato e di terze parti disponibile oggi è tra GPT-6 Sol e i modelli di altri laboratori, non tra GPT-6 Sol e il suo stesso successore. Chiunque vi mostri adesso un grafico 6.1 contro 6.0 vi sta mostrando la slide di OpenAI.

La migrazione è un cambio di stringa, tranne quando non lo è.

La guida alla migrazione di OpenAI per la famiglia GPT-6 vale la pena di essere letta prima di cambiare l'identificatore, perché due suoi elementi rompono il codice funzionante. Il primo è la scala del ragionamento: se una qualsiasi richiesta invia reasoning_effort: "none", GPT-6.1 Sol la rifiuta, e il rimedio documentato è iniziare da low e confrontare su attività rappresentative invece di presumere che l'impostazione più bassa sia equivalente. I flussi di lavoro che usavano none come baseline di latenza perdono quella baseline. Il secondo è la chiamata degli strumenti: GPT-6.1 Sol supporta Chat Completions ma non la chiamata degli strumenti tramite essa — gli strumenti richiedono l'API Responses. Se il tuo stack chiama funzioni su /v1/chat/completions, non stai scambiando una stringa, stai portando un endpoint. L'istruzione dello stesso fornitore agli sviluppatori già su GPT-6 Sol è di rivedere quella guida prima di passare, il che è un segnale chiaro che questo non è l'aggiornamento sostitutivo immediato che lo scarto di una settimana lascia intendere.

I restanti parametri si comportano come segue: sforzo di ragionamento, output strutturati, streaming, caching dei prompt e il set di strumenti vengono tutti mantenuti, e la stessa regola di riprezzamento 272K si applica in modo identico a entrambi i modelli. Imposta model su gpt-6.1-sol, mantieni la tua impostazione dello sforzo dove era supportata e rimuovi temperature, top_p e top_logprobs ogni volta che lo sforzo non è none — quest'ultimo vale per entrambi i modelli ed è una fonte comune di errori 400 dopo qualsiasi migrazione a un modello di ragionamento.

Migrare senza scommettere un percorso di produzione su di esso

La migrazione realistica non è un cutover, è uno shadow run: invia una fetta di traffico di produzione al nuovo identificatore, mantieni il vecchio come il percorso che risponde e confronta sui tuoi task. Questo è un problema di routing, ed è l'unico punto in cui la piattaforma tramite cui effettui le chiamate cambia la forma del lavoro. OrcaRouter serve oggi GPT-6 Sol al prezzo di listino di OpenAI, senza markup — la scheda da $2,00 / $0,20 / $10,00, inclusa la regola di ripricing a 272K — quindi il braccio di riferimento del confronto è attivo sulla stessa chiave di tutto il resto, e il braccio 6.1 può essere aggiunto al set di route non appena sarà chiamabile, senza un secondo contratto o un secondo SDK. Fino ad allora la posizione onesta è che GPT-6 Sol è il modello disponibile da chiamare, e vale la pena dirlo chiaramente invece di lasciar intendere il contrario: openai/gpt-6.1-sol restituisce "model not found" sul nostro endpoint del catalogo pubblico oggi. Il failover automatico è ciò che rende sicuro lo shadow run quando arriverà davvero — se la nuova route dà errore, la richiesta si completa sulla vecchia e lo scopri dai log anziché dai tuoi utenti.

Chi dovrebbe muoversi ora: i team i cui costi sono dominati dall'input in cache nelle lunghe sessioni degli agenti, e i team i cui flussi di lavoro usano già la Responses API e non inviano mai none. Per loro si tratta quasi di un aggiornamento gratuito — il fornitore dichiara i guadagni in termini di capacità, il costo della cache è dimezzato e la migrazione consiste in una sola stringa. Chi dovrebbe aspettare: i team con none in un percorso critico per la latenza, i team il cui tool calling passa attraverso Chat Completions, e chiunque abbia bisogno di un dato proveniente dall'esterno di OpenAI prima di impegnarsi. Per quest'ultimo gruppo l'attesa non ha una data di fine pubblicata, e la cosa sensata da fare con il tempo è costruire l'eval set che il confronto richiederà — perché quando arriverà il punteggio indipendente, sarà riferito al traffico di qualcun altro.