Quando David Ondrej ha pubblicato un clip il 25 aprile in cui "Gemini 3.1 Pro" ripeteva dieci messaggi consecutivi in OpenClaw — auto-citandosi, non volendo smettere e alla fine bloccandosi — ha sollevato la domanda cruciale che ogni team con OpenClaw si pone prima o poi: quale modello funziona davvero in questo ambiente e quali invece si disgregano silenziosamente? I benchmark di marketing non rispondono a questa domanda. Nemmeno le classifiche. Solo l'utilizzo reale.
Gestiamo OpenClaw da alcuni mesi in progetti di clienti e scambiamo modelli non appena ne sono disponibili di nuovi. Questa è la guida pratica che avremmo voluto avere all'inizio: a quali modelli ci affidiamo oggi in OpenClaw, quali non utilizziamo più e come decidere per il vostro specifico carico di lavoro. (Parole chiave italiane: Machine Learning, API, CLI, OpenClaw, modelli di Machine Learning)
Cosa significa "migliore" in OpenClaw
OpenClaw non è una chat-box. È un framework agentico: utilizzo di strumenti, modifica di file, lunghe sequenze di task, contesto persistente, hooks e una CLI per l'automazione in stile Cron. Un modello con 90 punti nel benchmark di coding può comunque essere la scelta sbagliata se ignora le convenzioni degli hook di OpenClaw, viola i contratti di Tool-Call o brucia la finestra di contesto leggendo lo stesso file quattro volte di seguito.
Tre proprietà contano più dei numeri di benchmark:
- Disciplina di Tool-Call — chiama lo strumento giusto con lo schema giusto al primo tentativo?
- Disciplina di Stop — sa quando il task è completato o gira in loop?
- Economia di Contesto — rilegge ciò che è già nel contesto o si fida di esso?
Quasi tutto il resto ne consegue. Valutiamo ogni modello nelle nostre note di deployment in base a questi tre punti. Ecco come appaiono le principali opzioni Frontier alla fine di aprile 2026.
Sonnet 4.6 — il Default che si è guadagnato il suo posto
Anthropic Claude Sonnet 4.6 è il modello che impostiamo come default in quasi ogni deployment di OpenClaw — e si è guadagnato questo posto, non gli è stato regalato. Disciplina di Tool-Call: eccellente. Disciplina di Stop: il migliore della classe — quando un task di Sonnet 4.6 è completato, si ferma. Raramente rilegge file che gli sono stati appena mostrati. Il rapporto costo-per-task per i tipici workflow di Agent si colloca all'incirca dove si trovava Haiku prima dell'adeguamento dei prezzi.
Dove mostra delle debolezze: i refactoring multi-step profondi in codebase sconosciute a volte richiedono una lama più affilata. In sede di Code-Review, decisioni architetturali o debugging di tracce con una lunga catena causa-effetto, Sonnet 4.6 occasionalmente si arrende troppo presto. Proprio in questi casi ricorriamo a Opus.
Per una valutazione più approfondita del motivo per cui il lavoro agentico si è spostato verso questo modello, consultate il nostro articolo su il modello di lavoro agentico che OpenAI ha fornito contro il mito di Claude. (articolo in tedesco)
Opus 4.7 — quando la profondità del ragionamento ripaga davvero
Opus 4.7 è il peso massimo. Non lo impostiamo come predefinito perché i costi per attività si sommano rapidamente, ma è il nostro percorso di escalation per tre classi di lavoro:
- Debugging complesso, in cui la catena causa-effetto si estende su più file e i sintomi sono fuorvianti
- Decisioni architetturali, in cui il modello deve valutare onestamente i compromessi, invece di scegliere la prima risposta plausibile
- Attività one-shot ad alto rischio come script di migrazione, modifiche allo schema o qualsiasi cosa che tocchi i dati di produzione
Opus 4.7 è anche il modello di cui ci fidiamo di più quando conta il pensiero adattivo, ovvero quando il modello dovrebbe investire in token di ragionamento prima di eseguire un Tool-Call. I costi sono reali, ma il tasso di successo nelle attività difficili li giustifica. Regola empirica: se un'esecuzione di Sonnet fallisce due volte con errori simili, esegui l'escalation a Opus invece di ripetere.
GPT-5.5 in OpenClaw — Coder potente, strumento sbagliato per ora
GPT-5.5 in OpenClaw è al contempo interessante e frustrante. Come puro coder è potente, e la conferma di OpenAI che GPT-5.5 = Codex (Romain Huet, 25 aprile) significa che non c'è più "Codex per il coding, GPT-5.5 per compiti generali". Un modello, due framework.
Ma OpenClaw non è il suo framework. Osserviamo due schemi di errore ricorrenti quando integriamo GPT-5.5 in OpenClaw:
- Tool-Call-Schema-Drift — occasionalmente inventa campi di tool che non esistono, soprattutto in contesti più lunghi
- Disciplina di stop più permissiva — produce più frequentemente di Sonnet 4.6 testi di riempimento del tipo "Ci sto ancora lavorando"
Per OpenClaw, la nostra raccomandazione oggi è: lasciate GPT-5.5 nella Codex-CLI, dove le sue convenzioni corrispondono al suo training, e mantenete i modelli Anthropic in OpenClaw. Questo potrebbe cambiare non appena il framework si evolverà attorno ad altri provider. Eseguiamo test ad ogni Minor-Release.
DeepSeek V4 — Una rivoluzione dei costi che richiede test reali
DeepSeek V4 (1,6 trilioni di parametri, licenza MIT, drasticamente più economico di Opus per compiti comparabili) è appena arrivato. Abbiamo trattato in dettaglio le implicazioni sui prezzi nel nostro articolo sul terremoto dei prezzi di DeepSeek V4.
In OpenClaw, i nostri primi test dimostrano che DeepSeek V4 Flash esegue il 70-80% dei tipici carichi di lavoro Haiku a una frazione del costo. V4 Pro è seriamente competitivo con Opus in compiti di ragionamento isolati, tuttavia la disciplina di arresto è inferiore ai modelli Anthropic. Non siamo ancora pronti a raccomandarlo come predefinito nelle implementazioni dei clienti: è troppo presto per sapere come si comporta in lunghi cicli di agent e la variante Open-Weights richiede un'infrastruttura di Self-Hosting che la maggior parte dei team non possiede.
Se siete sensibili ai costi e volete investire nella valutazione: iniziate con V4 Flash su lavori Cron OpenClaw a basso rischio (scansioni Intel, riepiloghi, controlli di qualità dei contenuti) e misurate la disciplina di arresto e l'accuratezza delle chiamate agli strumenti (Tool-Call). Non utilizzatelo in lavori di tipo produzione fino a quando non avrete una cronologia di stabilità di diverse settimane. Questo è particolarmente importante per applicazioni di Machine Learning e integrazioni API. Considerate anche l'utilizzo di una CLI per monitorare e gestire le performance.
Modelli che abbiamo testato e che non raccomandiamo
Alcuni segnali derivanti dagli ultimi sei mesi di lavoro di deployment:
- Gemini 2.5 Pro e varianti 3.x: Incoerente in OpenClaw. Il rapporto di Ondrej corrisponde ai nostri test. Il modello è forte nel suo ambiente (Vertex, AI Studio), ma non rispetta in modo affidabile le convenzioni degli strumenti di OpenClaw. Non vi accediamo più.
- Nemotron e Qwen Mid-Tier: Buoni come fallback nella nostra Cost-Cascade, ma i tassi di timeout aumentano in contesti più lunghi. Adatti solo per brevi burst.
- Versioni precedenti di Claude (3.5, 4.0, 4.5): Obsolete. Nessun motivo per utilizzarle, a meno che non sia necessario per motivi di costo. Questo è importante per l'ottimizzazione dei costi e la scelta del modello di Machine Learning più adatto.
Maggiori informazioni sul contesto dei provider sono disponibili nella nostra analisi sui prezzi di calcolo agentici. Questo può aiutare a comprendere meglio i costi relativi all'utilizzo di diverse API.
Come scegliere: una matrice decisionale
Ecco come procediamo quando un cliente chiede: "Quale modello dovremmo utilizzare?"
| Workload | Default | Escalation a | Perché |
|---|---|---|---|
| Cron job giornalieri (Audit, Scan, Summarize) | Sonnet 4.6 | Opus 4.7 se la precisione è critica | La disciplina di stop di Sonnet mantiene i costi prevedibili |
| Generazione e revisione del codice | Sonnet 4.6 | Opus 4.7 per bug difficili | Saltare GPT-5.5 in OpenClaw; utilizzare in Codex-CLI |
| Attività una tantum ad alto rischio (Migrazioni, Correzioni in produzione) | Opus 4.7 | — | Costi giustificati dai costi di un singolo errore |
| Lavoro di massa sensibile ai costi | DeepSeek V4 Flash (Test) | Sonnet 4.6 | Convalidare la disciplina di stop prima del ridimensionamento |
| Attività multimodali (Visione, Audio) | Sonnet 4.6 con Vision | Opus 4.7 | Comportamento più coerente in OpenClaw |
La leva che utilizziamo più spesso: in caso di Retry, eseguire l'escalation da Sonnet a Opus, mai il contrario. Se Sonnet fallisce due volte, Opus di solito lo risolve al primo tentativo. Se Opus fallisce, un Retry con Opus raramente aiuta: l'attività probabilmente necessita di un inquadramento diverso. (framing diverso, Machine Learning, API)
FAQ
D: Posso cambiare modello in OpenClaw a metà task? Sì — OpenClaw supporta il cambio di modello tramite flag CLI o configurazione per singolo job. Lo utilizziamo nella nostra cascata di fallback Cron: se Sonnet va in timeout due volte, la successiva esecuzione tenta automaticamente un altro provider. Configuratelo prima di averne bisogno.
D: "Gemini 3.1 Pro" è effettivamente un modello pubblicato? Al 26 aprile 2026, non troviamo alcun annuncio ufficiale di Google per "Gemini 3.1 Pro". Il video di David Ondrej potrebbe riferirsi a un nome interno o a un rilascio silenzioso. Trattate qualsiasi affermazione su "Gemini 3.x" come non confermata finché il blog di Google non la convalida.
D: Dovrei sempre utilizzare il modello più potente "per sicurezza"? No. Utilizzare Opus 4.7 per un job che Sonnet 4.6 svolge bene costa da cinque a dieci volte di più per lo stesso risultato, e i loop di ragionamento più lunghi possono introdurre propri schemi di errore. Adattate il modello al carico di lavoro — aumentate in caso di retry, non per impostazione predefinita. Questo è particolarmente importante quando si utilizzano tecniche di Machine Learning e API complesse.
D: Quanto spesso dovrei testare di nuovo quale modello è più adatto? Almeno mensilmente, settimanalmente se gestite deployment OpenClaw produttivi. Il comportamento del modello cambia dopo ogni minor release e la compatibilità del framework cambia più velocemente di quanto suggeriscano i valori di benchmark. È fondamentale monitorare le performance per ottimizzare i costi e l'efficacia delle vostre soluzioni di Intelligenza Artificiale.
Conclusioni
Per la maggior parte dei team che utilizzano OpenClaw nel 2026, la configurazione predefinita corretta è Sonnet 4.6 con Opus 4.7 come percorso di escalation. GPT-5.5 appartiene alla Codex-CLI, non a OpenClaw. DeepSeek V4 merita una valutazione per carichi di lavoro sensibili ai costi, ma non è ancora pronto per la produzione in questo framework. Le varianti Gemini rimangono incoerenti.
I valori di benchmark continueranno a cambiare. Ciò che conta in OpenClaw è la disciplina di Tool-Call, la disciplina di Stopp e l'economia di contesto — e su questi tre assi i modelli Anthropic sono ancora in vantaggio.
Se avete bisogno di aiuto per impostare la giusta cascata di modelli per la vostra implementazione di OpenClaw — valori predefiniti, fallback, regole di escalation — prenotate una conversazione di scoperta con Context Studios. L'abbiamo fatto per un numero sufficiente di clienti da poter saltare la fase di tentativi ed errori. (Parole chiave italiane: Machine Learning, API, CLI, modelli di linguaggio, intelligenza artificiale)