GPT-5 e il routing automatico tra modelli: la fine dei selettori manuali

OpenAI ha rilasciato giovedì GPT-5, presentato non come singolo modello ma come sistema che instrada automaticamente ogni query a uno tra diversi sub-modelli specializzati. Il selettore manuale tra GPT-4o, o1, o3-mini e varianti è sparito da ChatGPT. Sam Altman ha dichiarato sul blog OpenAI che il sistema sceglie da solo se rispondere veloce, ragionare a lungo, o cercare online. L’utente smette di scegliere il modello, sceglie solo la domanda.

La conseguenza è meno banale di quanto sembri.

Cosa è esattamente GPT-5

GPT-5 è un’architettura composta. Almeno tre sub-modelli (chiamati gpt-5-main, gpt-5-thinking, gpt-5-pro nel blog di lancio) gestiscono classi di task diverse. Sopra di loro siede un router che analizza la query, decide quale sub-modello attivare, in alcuni casi orchestrando più chiamate concatenate. L’utente vede un’unica interfaccia, riceve un’unica risposta, paga con un unico abbonamento.

Sulla performance, OpenAI dichiara stato dell’arte su quasi tutti i benchmark pubblici: 94,6% su AIME 2025 con tool, 88% su SWE-bench Verified, 84,2% su MMMU per task multimodali. I numeri sono rilevanti ma non sorprendenti rispetto a o3 e Claude Opus 4. La differenza vera è strutturale, non incrementale.

Il routing automatico cambia il modo di promptare

Fino a ieri il prompting avanzato includeva la scelta consapevole del modello. Per un task analitico complesso si selezionava o1 o o3. Per una bozza creativa, GPT-4o. Per estrarre dati strutturati, magari GPT-4.1 mini per risparmiare. La selezione era un’ottimizzazione che valeva tempo e denaro.

Con GPT-5, quella selezione la fa il router. In teoria è una buona notizia: l’utente non deve sapere cosa è meglio per cosa. In pratica introduce un livello di opacità nuovo. Non sai esattamente quale modello ha risposto, quanti reasoning tokens sono stati consumati, perché il router ha deciso quello che ha deciso. La fattura arriva, l’output arriva, il dietro le quinte è gestito.

Per la maggior parte degli utenti consumer è perfetto. Per chi prompta in produzione, per applicazioni dove la consistenza è critica, è un cambiamento da gestire con attenzione.

Cosa cambia per chi sviluppa applicazioni AI

L’API espone ancora i sub-modelli individualmente. Il router automatico è il default di ChatGPT, non un obbligo per chi sviluppa. Significa che per applicazioni in produzione si può continuare a scegliere gpt-5-thinking quando serve ragionamento, gpt-5-main quando serve velocità. La determinazione resta tua.

Comunque, OpenAI sta marcando una direzione. Nei prossimi due rilasci aspettatevi che il router diventi accessibile anche via API, e che progressivamente la documentazione spinga a usarlo. La frizione di mantenere logica di routing custom diventerà sempre più “perché stai facendo questo a mano”.

Per chi costruisce, il consiglio è di scrivere lo strato di routing della propria applicazione in modo astratto. Oggi è codice tuo. Domani potrebbe diventare una chiamata al router di OpenAI con un parametro auto. La portabilità è il vero asset.

Cosa cambia per chi opera in marketing AI

Tre cose, concretamente.

Primo, il selettore modello in ChatGPT consumer sparisce. Le sessioni di formazione interna che dedicavano dieci minuti a spiegare quando scegliere o3 e quando GPT-4o sono diventate obsolete. La nuova lezione è promptare meglio, lasciare al router il resto.

Secondo, l’output medio in conversazioni lunghe diventa più consistente. Una delle frustrazioni della vecchia interfaccia era cambiare modello a metà sessione e perdere parte del contesto qualitativo. Con un router unificato la sessione è più coerente, almeno nei test che ho eseguito.

Terzo, per agenzie che vendono “competenza prompting” il valore percepito scende. Quando il modello “capisce da solo” cosa fare, la skill di scegliere il setup giusto vale meno. La vera competenza si sposta sul lato applicativo: capire dove l’AI fa la differenza nel business specifico del cliente, non come configurarla.

I limiti del routing automatico

Tre cose che il router non sa fare bene, almeno in queste prime settimane.

Uno: non comunica chiaramente la propria decisione. Se chiedi una cosa apparentemente semplice ma critica, non sai se ti ha risposto un sub-modello veloce o uno che ha ragionato. Per task ad alto rischio (analisi legale, compliance, raccomandazioni mediche) questa opacità è un problema concreto.

Due: tende a sotto-allocare reasoning quando la query è formulata in modo conciso. Test pratici: lo stesso problema matematico complesso, posto in due righe, ottiene risposta veloce e a volte sbagliata. Posto in cinque righe con esplicito “ragiona passo passo”, attiva il sub-modello thinking. Significa che il prompting non è morto, è cambiato il vettore.

Tre: nei task agentici di lunga durata (oltre i 30 minuti) il router ha latenza addizionale a ogni step. Non sempre conviene rispetto a chiamare direttamente un sub-modello specifico via API.

Quello che cambierà nei prossimi mesi sull’API

Una nota sul comportamento del mercato API nei prossimi mesi. Sam Altman ha confermato in conferenza stampa che la modalità auto-routing arriverà progressivamente anche via API, con un parametro che sarà possibile attivare a costo equivalente di un piccolo overhead di latency. Per chi sviluppa applicazioni in produzione, sarà la scelta se delegare la decisione o continuare a controllarla manualmente.

La mia tesi operativa: per le applicazioni dove la consistenza dei costi è critica, conviene continuare a specificare il sub-modello. Per applicazioni dove la qualità batte il prezzo, conviene affidarsi al router. Il pattern dipende dal business case. Non c’è una risposta universale.

Su un punto sono ragionevolmente certo: i progetti che oggi instradano manualmente tra GPT-4o, o3-mini, e o3 dovranno essere rivisti. Quello stack non sopravviverà fino a fine anno senza modifiche. Chi pianifica budget di sviluppo deve prevedere un trimestre di riassetto.

Una nota tecnica sul cambiamento per chi opera in marketing automation. Le piattaforme che oggi instradano workflow su modelli OpenAI dovranno adeguare la propria orchestrazione interna. Il vecchio modo di selezionare il modello in base a tipo di task lascia il posto a uno strato in cui la piattaforma stessa diventa il router superiore al router di OpenAI. Chi costruisce così, ha un grado di libertà in più. Chi appoggia tutto sul comportamento del router GPT-5, accetta una dipendenza che non controlla.

La domanda strategica per chi pianifica AI in azienda

Stiamo entrando in una fase dove i fornitori AI smettono di vendere singoli modelli e iniziano a vendere sistemi composti. Anthropic ha mostrato già nei mesi scorsi la propria roadmap verso Claude come orchestratore di workflow. Google con Gemini Live sta facendo lo stesso lato consumer.

La domanda strategica non è “quale modello scegliamo”. È “stiamo costruendo applicazioni che dipendono dalla singola call a un modello, o stiamo costruendo applicazioni dove la logica di business è separata dal modello sottostante”.

Le seconde sono più resilienti, costano un po’ di più all’inizio, e si rivalutano meno male a ogni release. Le prime sono veloci da costruire e dolorose da migrare.

Spoiler: stiamo entrando nel periodo dove le applicazioni del primo tipo, costruite negli ultimi diciotto mesi, diventeranno il debito tecnico AI dei prossimi diciotto. Chi pianifica oggi tenendolo in conto, evita di trovarsi a riscrivere tutto a inizio 2026.