Una richiesta con 10.000 token in ingresso e 1.000 in uscita costa circa 0,15 dollari con GPT-6 Astra e 0,0015 dollari con GPT-6 Luna, usando i prezzi standard consultati sul listino OpenAI il 3 ottobre 2026. È una differenza di cento volte sulla stessa quantità di testo. Per una PMI, scegliere sempre il modello più capace non è prudenza: è un errore di architettura che si moltiplica a ogni ticket, scheda prodotto, preventivo e aggiornamento WordPress.

La famiglia GPT-6 rende utile un approccio che finora molte aziende hanno rimandato: separare i compiti e assegnare a ciascuno il modello meno costoso che raggiunge una soglia di qualità verificata. OpenAI stessa presenta GPT-6 Astra per il lavoro di ragionamento più difficile, GPT-6.1 Sol per coding, ricerca e computer use complessi, e GPT-6 Luna per attività focalizzate e ripetitive su larga scala. Questa guida traduce la distinzione in un sistema operativo per PMI e professionisti, senza trasformare il routing in un progetto enterprise infinito.

Il caso pratico: una pipeline WordPress usa tre modelli

Prendiamo un flusso editoriale realistico. Un form raccoglie le informazioni del cliente, l’automazione classifica la richiesta, recupera documenti, prepara una bozza, controlla numeri e vincoli, quindi crea una bozza WordPress. Se tutto viene inviato ad Astra, il sistema funziona, ma paga ragionamento avanzato anche per leggere il settore da un campo a tendina. Se tutto viene inviato a Luna, il costo scende, ma una revisione contrattuale o un conflitto tra fonti può superare la capacità necessaria al compito.

La soluzione non è indovinare un modello medio. È dividere il workflow:

  • GPT-6 Luna classifica la richiesta, normalizza campi, estrae entità e produce JSON con uno schema fisso;
  • GPT-6.1 Sol scrive la bozza, usa strumenti, confronta documenti e gestisce i casi che richiedono giudizio;
  • GPT-6 Astra interviene solo quando il rischio o la complessità lo giustificano: conflitti tra fonti, revisione critica, debugging difficile o decisioni con un costo alto in caso di errore.

Questa è la mia take: il router non dovrebbe prevedere quale modello “suonerà meglio”. Deve applicare una politica esplicita basata su rischio, strumenti necessari e risultato dei test. La qualità non si delega al nome del modello; si misura sul compito.

1. Inventaria i compiti, non i reparti

“Marketing”, “assistenza” e “amministrazione” sono categorie troppo larghe per scegliere un modello. Nello stesso reparto convivono lavori molto diversi. L’assistenza può avere una classificazione a cinque etichette, una ricerca nella knowledge base e una risposta a un reclamo che cita condizioni contrattuali. Assegnare un solo modello al reparto nasconde questa differenza.

Per ogni automazione, crea una riga con sei campi:

  1. input reale, compresi allegati e lunghezza media;
  2. output richiesto e formato accettato;
  3. strumenti da usare, come ricerca, database, WordPress o browser;
  4. costo di un errore;
  5. tempo massimo accettabile;
  6. criterio che permette di dire “passato” o “fallito”.

Una classificazione di lead con output tra “commerciale”, “supporto” e “spam” ha un criterio semplice e può partire da Luna. Una migrazione di plugin che modifica database e checkout richiede più ragionamento, test e controllo: Sol è una base più sensata. Una revisione finale su una vulnerabilità o su un contratto ad alto impatto può meritare Astra, ma sempre con approvazione umana prima dell’azione.

Questo inventario impedisce anche un errore frequente: ottimizzare il modello mentre il requisito resta vago. Se nessuno ha definito cosa conta come risposta corretta, un confronto tra modelli produce impressioni, non dati.

2. Costruisci una matrice di routing minima

Il primo router può essere una tabella, non un altro modello. È più facile da controllare e da spiegare. Una configurazione iniziale per una PMI può seguire queste regole:

  • Luna per estrazione, classificazione, riassunti strutturati, riscritture vincolate e controlli ripetitivi;
  • Sol per generazione con più fonti, coding, uso di tool, pianificazione e casi con ambiguità gestibile;
  • Astra per escalation ad alta complessità o rischio, dopo che un controllo ha rilevato un conflitto reale;
  • nessun modello può pubblicare, pagare, cancellare o inviare dati sensibili senza la regola di autorizzazione prevista dal workflow.

OpenAI permette di modulare anche il livello di ragionamento. Nella guida ufficiale, “low” è indicato per attività ordinarie, “medium” per lavori che richiedono giudizio e “high” per debugging o analisi difficili; i livelli superiori vanno mantenuti solo se il miglioramento giustifica tempo e costo. Modello e reasoning effort sono quindi due leve distinte. Prima si sceglie la classe di modello, poi si alza lo sforzo soltanto dove gli eval mostrano un guadagno.

Non userei la lunghezza del prompt come unico segnale. Un documento lungo può richiedere una semplice estrazione; una domanda di due righe può autorizzare un rimborso o cambiare un dato critico. Il rischio nasce dall’azione e dal dominio, non dal numero di caratteri.

3. Parti dal modello forte, poi riduci con gli eval

Per una nuova automazione conviene ottenere prima un riferimento di qualità con il modello più capace appropriato. Raccogli da 30 a 100 casi reali, elimina i dati personali non necessari e definisci l’output corretto. Solo dopo prova Sol e Luna sugli stessi casi. Il modello più economico passa quando raggiunge la soglia richiesta, non quando produce tre demo convincenti.

Gli eval devono misurare il risultato utile. Per una scheda prodotto: campi obbligatori presenti, numeri copiati senza alterazioni, tono corretto e HTML valido. Per un ticket: categoria, priorità, risposta coerente con la knowledge base e nessuna promessa non autorizzata. Per codice WordPress: test superati, escaping e sanitizzazione, assenza di regressioni e diff revisionabile.

Introduci poi il modello economico in shadow mode. Riceve gli stessi input della produzione, ma il suo output non viene usato. Confronta errori, latenza e costo per almeno una settimana o un volume sufficiente a includere i casi rari. Il passaggio reale avviene solo dopo questo confronto.

Il costo utile da seguire non è “dollari per milione di token”. È il costo per attività completata correttamente. Se Luna costa cento volte meno ma richiede correzioni manuali su un ticket ogni cinque, il risparmio può sparire. Se passa il 99% delle classificazioni e inoltra l’1% a Sol, il routing sta facendo il suo lavoro.

4. Progetta l’escalation prima degli errori

Un router serio deve sapere quando fermarsi. Le condizioni di escalation possono essere deterministiche:

  • output non conforme allo schema JSON;
  • fonte richiesta ma assente;
  • due documenti che riportano valori incompatibili;
  • azione esterna sopra una soglia economica;
  • dato personale o categoria sensibile;
  • secondo tentativo fallito;
  • richiesta fuori dalle categorie coperte dagli eval.

Il primo errore può generare un retry controllato sullo stesso modello. Il secondo passa a Sol o Astra con il contesto dell’errore, non con una conversazione infinita. Se anche l’escalation fallisce, il workflow crea una coda per una persona. Nascondere l’errore dietro altri tentativi aumenta token e latenza, e rende più difficile capire quale passaggio non funziona.

Per le azioni esterne, separa generazione ed esecuzione. Il modello prepara un payload; codice deterministico valida campi, permessi e limiti; un operatore approva quando il rischio lo richiede. È lo stesso principio che uso per una pipeline editoriale WordPress: prima bozza e controlli, poi pubblicazione. Il modello può proporre. L’applicazione decide se ha l’autorità per agire.

5. Riduci i costi senza rompere il contesto

I tre modelli dichiarano una finestra di contesto fino a 1.050.000 token e un massimo di 128.000 token in uscita. Non è un invito a riempire ogni richiesta. Oltre 272.000 token in ingresso, le pagine modello indicano tariffe maggiorate per l’intera richiesta. Un contesto enorme aumenta inoltre il materiale da controllare e può mascherare istruzioni obsolete.

Per le automazioni ripetitive, mantieni stabile il prefisso: istruzioni, schema degli strumenti e regole condivise vengono prima; il contenuto variabile viene dopo. Il prompt caching riusa il lavoro quando le richieste condividono lo stesso prefisso. OpenAI indica che il caching è attivo di default sui modelli supportati e che riduce costo dell’input e tempo prima della risposta. La cache, però, richiede che il prefisso renderizzato coincida: cambiare continuamente l’ordine delle regole distrugge il riuso.

Su questo punto ho già mostrato perché il prompt caching di GPT-6 può costare di più quando i prefissi non sono stabili o si ignorano le scritture di cache. Il routing non sostituisce quel lavoro. Un modello economico alimentato con contesti duplicati resta un sistema inefficiente.

Per conversazioni e agenti lunghi, la guida GPT-6 consiglia la compaction per ridurre il contesto conservando lo stato necessario. In pratica, non spedire a ogni turno log, HTML e documenti già elaborati. Conserva gli artefatti fuori dal prompt, recupera solo ciò che serve e registra quali fonti hanno prodotto una decisione.

6. Aggiorna prompt, skill e confini decisionali

La nuova guida di OpenAI non suggerisce prompt sempre più lunghi. Chiede un incarico chiaro: risultato, destinatario, contesto, vincoli e definizione di “finito”. Per skill e istruzioni di progetto raccomanda descrizioni brevi, dettagli caricati quando servono e confini espliciti tra azioni autonome e azioni che richiedono approvazione.

Per una PMI questo significa togliere regole contraddittorie. Se un prompt dice “non chiedere mai” e un altro “chiedi conferma per ogni passaggio”, il modello non ha una politica operativa. Scrivi invece: può leggere documenti e preparare bozze; deve chiedere approvazione prima di inviare email, pubblicare, effettuare pagamenti o modificare dati di produzione. La precisione utile riguarda l’autorità, non ogni frase dell’output.

Chi sta già migrando automazioni può partire dalla mia guida a GPT-6.1 Sol su WordPress. Il passaggio successivo è non trattare Sol come destinazione universale: diventa il livello centrale di un sistema che usa Luna per il volume e Astra per le eccezioni difficili.

7. Piano di adozione in trenta giorni

Settimana 1: misura il flusso attuale

Seleziona una sola automazione con volume sufficiente e rischio contenuto. Registra input, output, token, latenza, revisioni manuali ed errori. Costruisci il set di eval dai casi reali. Non cambiare ancora modello e prompt insieme: perderesti il riferimento.

Settimana 2: prova i tre livelli

Esegui lo stesso set su Astra, Sol e Luna, con reasoning effort coerente. Confronta accuratezza, costo per successo e tempo. Definisci quali casi Luna può gestire e quali devono partire direttamente da Sol. Astra resta escalation, non default.

Settimana 3: shadow mode e osservabilità

Attiva il router senza affidargli azioni reali. Salva modello scelto, regola applicata, uso dei token, esito dell’eval e motivo dell’escalation. Evita di registrare contenuti sensibili se non servono. Un log utile spiega la decisione senza diventare una copia permanente di tutti i dati.

Settimana 4: produzione con limiti

Porta in produzione il percorso a basso rischio, con budget giornaliero, timeout, numero massimo di tentativi e coda umana. Rivedi ogni settimana i casi escalati. Se una categoria ricorre, migliora lo schema o aggiungi esempi; non aumentare automaticamente il modello per tutto il traffico.

La chiusura operativa

GPT-6 non obbliga una PMI a costruire un’orchestrazione complessa. Bastano una tabella di compiti, eval ripetibili, tre livelli di servizio e condizioni di stop. Luna assorbe il lavoro focalizzato e frequente. Sol gestisce il lavoro professionale complesso. Astra entra quando un caso difficile giustifica davvero prezzo e latenza.

Domani mattina farei una sola cosa: prenderei l’automazione con più chiamate e segnerei, per ogni passaggio, rischio dell’errore e criterio di successo. Se due passaggi hanno profili diversi, non dovrebbero ereditare lo stesso modello. Il risparmio arriva dal routing; l’affidabilità arriva dagli eval e dai confini di autorizzazione.

Fonti

Approfondimenti