Miglior modello locale per OpenClaw: gemma4, gpt-oss:20b e qwen3-coder:30b misurati su quattro attività di agente

Su un M3 Max da 128 GB con OpenClaw 2026.9.7 e Ollama 0.35.0, gemma4 — il modello suggerito dalla configurazione Ollama di OpenClaw — ha superato tutte le 12 esecuzioni valutate su quattro attività agent; gpt-oss:20b ne ha superate 11 su 12 con quasi il triplo di chiamate agli strumenti fallite; e qwen3-coder:30b, la scelta abituale per il coding, ne ha superate 2 su 12 perché le sue chiamate agli strumenti continuavano a rompersi nel parser di Ollama. Abbiamo eseguito ogni modello tre volte per ogni attività in un workspace nuovo, valutato il risultato tramite script e registrato i conteggi degli strumenti e dei token di OpenClaw e il log del server Ollama. Misurato il 1° ottobre 2026.

Per sapere quanto costa OpenClaw e quanto costerebbe invece un modello ospitato, consulta prezzi di OpenClaw; per eseguire un modello locale con un fallback API, più agent e modelli in OpenClaw.

Cosa è stato eseguito

Le quattro attività

Risultati

I tempi sono quelli reali per esecuzione, inclusi circa cinque-sette secondi di avvio di OpenClaw. "Token in" è l'input non memorizzato nella cache registrato da OpenClaw; il contesto reinviato dalla cache si aggiunge a questo ed è conteggiato nella sezione dei costi qui sotto. La colonna delle chiamate agli strumenti fallite conta gli errori registrati da OpenClaw; i fallimenti di qwen3-coder sono avvenuti prima che una chiamata raggiungesse OpenClaw, quindi lì risultano zero e sono spiegati di seguito.

Cosa dicono i numeri

• gemma4 e gpt-oss:20b sono entrambi utilizzabili per brevi attività agent. Hanno superato 23 delle 24 esecuzioni, inclusa la correzione di due file, che richiede di leggere diversi moduli, modificarne due e rieseguire i test.
• gemma4 ha usato gli strumenti in modo più pulito. Nell'attività di lettura ha effettuato esattamente una chiamata allo strumento ogni volta; gpt-oss ne ha effettuate tre, due delle quali in genere sono fallite prima della lettura del file. Nelle dodici esecuzioni complessive gpt-oss ha avuto 19 chiamate agli strumenti fallite contro le 7 di gemma4 e ha registrato in media 9,1 turni dell'assistente per attività contro i 6,8 di gemma4.
• L'unico fallimento è stato gpt-oss nell'attività di conteggio: dopo tredici chiamate agli strumenti ha scritto un counts.json non valido e ha terminato il turno senza una risposta.
• La velocità non è il fattore distintivo qui. Mediana di 53 s per gemma4 e 54 s per gpt-oss in tutte le esecuzioni; l'esecuzione singola più lenta è stata quella di gemma4, 133 s per la correzione di due file, con diciassette chiamate agli strumenti. Le esecuzioni di qwen3-coder sono state più brevi solo perché sono fallite subito.
• I modelli più grandi non hanno portato maggiore accuratezza in queste attività. gpt-oss:20b ha quasi il triplo dei parametri di gemma4 e qwen3-coder:30b, progettato per il codice, ha ottenuto il punteggio più basso dei tre.

Dodici esecuzioni per modello bastano a vedere uno schema in queste attività, ma non a classificare i modelli in generale. Non sono state testate attività lunghe, basi di codice più grandi né altre quantizzazioni.

Perché qwen3-coder:30b ha fallito

Non per il coding. Delle sue dieci esecuzioni fallite:

• Cinque sono terminate nel parser di Ollama. qwen3-coder scrive le chiamate agli strumenti come XML e, quando un argomento conteneva codice, chiudeva un elemento <parameter> con </function>. Il log del server di Ollama 0.35.0 ha registrato "qwen tool call parsing failed … XML syntax error … element <parameter> closed by </function>" e OpenClaw ha terminato il turno con "Agent run failed".
• Quattro non hanno mai effettuato una chiamata. La risposta annunciava il passaggio successivo e poi mostrava un semplice </tool_call> come testo, senza nulla che Ollama potesse interpretare come una chiamata; il turno si è concluso lì. Questo è il sintomo che la documentazione di OpenClaw associa all'URL /v1 — qui si è verificato con l'API nativa.
• Una era una risposta errata: contava le righe dell'intestazione CSV come righe di dati.

Il parser è quello di Ollama, quindi questo risultato riguarda Ollama 0.35.0, non è un verdetto sul modello. Se esegui qwen3-coder con OpenClaw, controlla nel log di ollama serve la voce "qwen tool call parsing failed" prima di attribuire la colpa al modello e ripeti il test dopo un aggiornamento di Ollama.

La configurazione che ha fatto la differenza

• URL nativo di Ollama. La documentazione di OpenClaw afferma che l'URL compatibile con OpenAI /v1 "interrompe le chiamate agli strumenti e i modelli possono emettere JSON grezzo di chiamata allo strumento come testo normale"; per le esecuzioni è stato usato baseUrl senza /v1, insieme a api: "ollama".
• Imposta contextWindow nelle voci scritte manualmente. In un test rapido, una voce di modello esplicita senza questo valore è stata risolta con un contesto di 200.000 token; la configurazione Ollama di OpenClaw imposta 32.768 per i modelli locali, ed è questo il valore usato nelle esecuzioni.
• Il contesto di Ollama è separato. Ollama 0.35.0 ha caricato gemma4 e gpt-oss con 131.072 token e qwen3-coder con 262.144 — 45,3 GB residenti — indipendentemente dai 32.768 di OpenClaw; è questo, non il budget di OpenClaw, a determinare la memoria.
• Isola la shell. Un modello locale che esegue comandi shell sulla tua macchina rappresenta il rischio reale. Con sandbox.mode: "all", exec è stato eseguito nell'immagine Docker di OpenClaw con il solo workspace montato; l'immagine viene compilata una volta con il comando docker build indicato nella documentazione di sandboxing di OpenClaw.

// ~/.openclaw/openclaw.json — the runs used one model per config; the
// fallbacks line shows the pattern and was not part of the measured runs
{
  models: { providers: { ollama: {
    apiKey: "ollama-local",
    baseUrl: "http://127.0.0.1:11434",   // native Ollama URL — no /v1
    api: "ollama",
    timeoutSeconds: 600,
    models: [
      { id: "gemma4:latest", name: "gemma4:latest", contextWindow: 32768, maxTokens: 8192,
        params: { keep_alive: "30m" } },
      { id: "gpt-oss:20b",   name: "gpt-oss:20b",   contextWindow: 32768, maxTokens: 8192,
        params: { keep_alive: "30m" } },
    ],
  } } },
  agents: { defaults: {
    model: { primary: "ollama/gemma4:latest", fallbacks: ["ollama/gpt-oss:20b"] },
    sandbox: { mode: "all", workspaceAccess: "rw" },   // shell runs in Docker
  } },
  tools: { exec: { mode: "full" } },
}

Quali sono i costi locali

Un modello locale sostituisce un costo per token con tempo, spazio su disco ed elettricità. Per esecuzione, OpenClaw ha registrato circa 16.415 token di input non memorizzati nella cache, 78.469 token di contesto memorizzato nella cache reinviato e 1.142 token di output per gemma4, oltre a 13.761, 88.688 e 1.192 per gpt-oss. Come calcolo approssimativo — i tokenizer differiscono tra i modelli — gli stessi conteggi alle tariffe Kunavo di Claude Haiku 4.5 ($0,70 in ingresso, $0,07 in cache, $3,50 in uscita per milione) corrispondono a circa $0,021 e $0,020 per esecuzione. La potenza assorbita non è stata misurata; l'elettricità per esecuzione è watt × secondi ÷ 3.600.000 × il prezzo per kWh.

Lo schema pratico consiste nell'usare un modello locale come principale, con un fallback ospitato per i turni che il modello locale non riesce a gestire. OpenClaw accetta un elenco fallbacks per agente; una chiave Kunavo funziona come provider compatibile con OpenAI accanto a Ollama e viene fatturata per token a partire da un saldo prepagato. Nessuno presso Kunavo ha eseguito OpenClaw contro il suo endpoint: queste esecuzioni sono state interamente locali.

Domande frequenti

Eseguito il 1° ottobre 2026 su un Apple M3 Max (128 GB): OpenClaw 2026.9.7 (npm, Node 24.21.0), Ollama v0.35.0 (binario di release), gemma4:latest, gpt-oss:20b e qwen3-coder:30b scaricati dal registro Ollama e verificati tramite sha256. Ciascuna delle 36 esecuzioni ha usato un workspace nuovo e uno stato OpenClaw nuovo, exec nella sandbox Docker di OpenClaw e un valutatore basato su script; le chiamate agli strumenti e i conteggi dei token sono l'output JSON prodotto da OpenClaw. I fixture delle attività, i valutatori e lo script dell'adattatore sono pubblicati insieme alle evidenze di questa pagina. Non sono stati misurati: consumo energetico, attività lunghe, altre quantizzazioni o macchine più piccole.