Un modello troppo potente su ogni richiesta trasforma un’automazione utile in una fattura imprevedibile. Succede quando lo stesso motore gestisce sia la classificazione di un modulo WordPress sia il controllo di una proposta commerciale complessa. La correzione non è scrivere un prompt più lungo: è decidere prima quale lavoro merita più ragionamento.

Il problema: un solo modello per lavori diversi

In un workflow reale le richieste non hanno tutte lo stesso peso. Estrarre nome, email e oggetto da un modulo è un compito ripetitivo con un risultato facilmente controllabile. Valutare un preventivo, diagnosticare un errore intermittente o verificare una modifica al checkout richiede invece giudizio e più passaggi. La guida ufficiale alla famiglia GPT-6 distingue proprio questi casi: GPT-6 Luna per attività focalizzate e ripetute su larga scala, GPT-6.1 Sol per coding, ricerca e computer use complessi, GPT-6 Astra per il ragionamento più difficile. Anche il livello di reasoning cambia il profilo del lavoro: low per estrazioni e piccole modifiche, medium per confronti e pianificazione, high per debug e revisione accurata. Usare sempre il livello massimo non aggiunge controllo; sposta soltanto più richieste sulla fascia lenta e costosa.

La soluzione: instrada per rischio, non per abitudine

Dividi il flusso in tre corsie prima di collegarlo all’API. Nella prima metti operazioni reversibili e verificabili con regole semplici: classificare un ticket, estrarre campi, creare un riassunto strutturato. Nella seconda metti i casi che richiedono una scelta, come confrontare due plugin o preparare una bozza di risposta a un cliente. Nella terza restano azioni ad alto impatto: modifiche al codice, analisi di sicurezza, decisioni economiche e pubblicazioni. Parti dalla combinazione meno costosa che soddisfa il test della corsia; sali di modello o reasoning solo quando il controllo fallisce. È lo stesso principio utile nel prompt caching per WordPress: il risparmio stabile arriva dall’architettura, non da una frase magica aggiunta al prompt. Il router può essere una condizione nel workflow, non serve un secondo agente.

Tre passaggi per applicarlo oggi

Primo: raccogli 15-20 richieste reali del processo e scrivi accanto a ciascuna l’output atteso. Non usare esempi inventati, perché nascondono le eccezioni che poi arrivano in produzione. Secondo: assegna ogni richiesta a una corsia e definisci un controllo automatico. Per un form può essere uno schema JSON con campi obbligatori; per una bozza editoriale può essere la presenza delle fonti; per una modifica WordPress sono test, diff e revisione umana. Terzo: registra almeno modello usato, reasoning, esito del controllo, latenza e passaggio a una corsia superiore. Dopo una settimana saprai quali richieste stanno pagando capacità che non usano e quali, invece, falliscono perché partono troppo in basso. La guida OpenAI suggerisce anche di cambiare il reasoning durante una conversazione: è utile quando il contesto resta valido ma il compito diventa più difficile.

L’errore da evitare e la take finale

Non lasciare che sia il modello a dichiarare da solo che la propria risposta è “abbastanza buona”. Un’autovalutazione testuale non sostituisce un controllo esterno: schema valido, fonte presente, test superato, totale coerente o approvazione umana. Evita anche il routing basato soltanto sulla lunghezza del prompt. Una richiesta corta come “pubblica questa modifica” può avere un impatto maggiore di venti pagine da riassumere. La mia regola è semplice: il modello si sceglie sul costo dell’errore e sulla possibilità di verificarlo, non sul fascino del modello più nuovo. Parti piccolo, misura il fallimento, poi aumenta capacità. Se non hai un test che decide quando salire di livello, non hai ancora un router: hai solo spostato a caso la spesa tra tre nomi diversi.