Meilleur modèle local pour OpenClaw : gemma4, gpt-oss:20b et qwen3-coder:30b mesurés sur quatre tâches d’agent

Sur un M3 Max de 128 Go exécutant OpenClaw 2026.9.7 avec Ollama 0.35.0, gemma4 — le modèle recommandé par la configuration Ollama d’OpenClaw — a réussi les 12 exécutions évaluées sur quatre tâches agentiques ; gpt-oss:20b en a réussi 11 sur 12 avec près de trois fois plus d’appels d’outils échoués ; et qwen3-coder:30b, le choix habituel pour le code, en a réussi 2 sur 12, car ses appels d’outils échouaient sans cesse dans l’analyseur d’Ollama. Nous avons exécuté chaque modèle trois fois pour chaque tâche dans un espace de travail vierge, évalué le résultat par script et enregistré les nombres d’appels d’outils et de tokens fournis par OpenClaw lui-même ainsi que le journal du serveur Ollama. Mesuré le 1er octobre 2026.

Pour connaître le coût d’OpenClaw lui-même et celui d’un modèle hébergé, consultez les tarifs d’OpenClaw ; pour exécuter un modèle local avec un repli vers une API, consultez plusieurs agents et modèles dans OpenClaw.

Ce qui a été exécuté

Les quatre tâches

Résultats

Les temps sont mesurés au mur pour chaque exécution, y compris environ cinq à sept secondes de démarrage d’OpenClaw. « Tokens en entrée » désigne l’entrée non mise en cache telle qu’OpenClaw l’a enregistrée ; le contexte renvoyé depuis le cache s’y ajoute et est comptabilisé dans la section des coûts ci-dessous. La colonne des appels d’outils échoués compte les échecs enregistrés par OpenClaw ; les échecs de qwen3-coder se sont produits avant qu’un appel n’atteigne OpenClaw, ils apparaissent donc comme zéro ici et sont expliqués ci-dessous.

Ce que disent les chiffres

• gemma4 et gpt-oss:20b sont tous deux utilisables pour les tâches agentiques courtes. 23 de leurs 24 exécutions ont réussi, y compris la correction de deux fichiers, qui nécessite de lire plusieurs modules, d’en modifier deux et de relancer les tests.
• gemma4 a utilisé les outils plus proprement. Pour la tâche de lecture, il a effectué exactement un appel d’outil à chaque fois ; gpt-oss en a effectué trois, dont deux échouaient généralement avant la lecture du fichier. Sur les douze exécutions, gpt-oss a enregistré 19 appels d’outils échoués contre 7 pour gemma4, et a effectué en moyenne 9.1 tours d’assistant par tâche contre 6.8 pour gemma4.
• L’unique échec concernait gpt-oss sur la tâche de comptage : après treize appels d’outils, il a écrit un counts.json mal formé et a terminé le tour sans réponse.
• La vitesse n’est pas le facteur différenciant ici. Temps médian de 53 s pour gemma4 et de 54 s pour gpt-oss sur l’ensemble des exécutions ; l’exécution individuelle la plus lente a été celle de gemma4, avec 133 s sur la correction de deux fichiers et dix-sept appels d’outils. Les exécutions de qwen3-coder étaient plus courtes uniquement parce qu’elles échouaient tôt.
• Les modèles plus grands n’ont pas amélioré la précision sur ces tâches. gpt-oss:20b possède presque trois fois plus de paramètres que gemma4 et qwen3-coder:30b, conçu pour le code, a obtenu le score le plus faible des trois.

Douze exécutions par modèle suffisent pour voir une tendance sur ces tâches, mais pas pour classer les modèles en général. Les tâches longues, les bases de code plus importantes et d’autres quantifications n’ont pas été testées.

Pourquoi qwen3-coder:30b a échoué

Ce n’était pas lié au codage. Sur ses dix exécutions échouées :

• Cinq se sont terminées dans l’analyseur d’Ollama. qwen3-coder écrit les appels d’outils en XML et, lorsqu’un argument contenait du code, il fermait un élément <parameter> avec </function>. Le journal du serveur d’Ollama 0.35.0 a enregistré « qwen tool call parsing failed … XML syntax error … element <parameter> closed by </function> », et OpenClaw a terminé le tour avec « Agent run failed ».
• Quatre n'ont jamais effectué d'appel. La réponse annonçait l'étape suivante, puis affichait un simple </tool_call> sous forme de texte, sans rien qu'Ollama puisse analyser comme un appel ; le tour s'est terminé là. C'est le symptôme que la documentation d'OpenClaw associe à l'URL /v1 — ici, il s'est produit avec l'API native.
• Une était une mauvaise réponse : elle comptait les lignes d'en-tête du CSV comme des lignes de données.

L'analyseur est celui d'Ollama ; il s'agit donc d'un résultat pour Ollama 0.35.0, et non d'un verdict sur le modèle. Si vous exécutez qwen3-coder avec OpenClaw, surveillez le journal de ollama serve pour repérer « qwen tool call parsing failed » avant d'accuser le modèle, puis refaites le test après une mise à niveau d'Ollama.

La configuration qui comptait

• URL Ollama native. La documentation d'OpenClaw indique que l'URL compatible OpenAI /v1 « perturbe les appels d'outils et les modèles peuvent émettre du JSON brut d'appel d'outil sous forme de texte brut » ; les exécutions utilisaient baseUrl sans /v1, avec api: "ollama".
• Épinglez contextWindow dans les entrées rédigées manuellement. Lors d'un test rapide, une entrée de modèle explicite sans cette valeur a abouti à un contexte de 200 000 tokens ; la configuration Ollama d'OpenClaw utilise elle-même 32 768 pour les modèles locaux, valeur retenue par ces exécutions.
• Le contexte d'Ollama est distinct. Ollama 0.35.0 a chargé gemma4 et gpt-oss avec 131 072 tokens, et qwen3-coder avec 262 144 — 45,3 Go en mémoire — indépendamment des 32 768 d'OpenClaw ; c'est ce paramètre, et non le budget d'OpenClaw, qui détermine la mémoire.
• Isolez le shell. Le véritable risque ici est qu'un modèle local exécute des commandes shell sur votre machine. Avec sandbox.mode: "all", exec s'exécutait dans l'image Docker d'OpenClaw, avec uniquement l'espace de travail monté ; l'image est construite une fois avec la commande docker build indiquée dans la documentation sur le bac à sable d'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" } },
}

Coûts locaux

Un modèle local remplace une facturation par token par du temps, du stockage et de l'électricité. À chaque exécution, OpenClaw a enregistré environ 16,415 tokens d'entrée non mis en cache, 78,469 tokens de contexte mis en cache renvoyés et 1,142 tokens de sortie pour gemma4, ainsi que 13,761, 88,688 et 1,192 pour gpt-oss. À titre de calcul approximatif — les tokeniseurs diffèrent selon les modèles — les mêmes volumes aux tarifs Kunavo de Claude Haiku 4.5 ($0.70 en entrée, $0.07 en cache, $3.50 en sortie par million) représentent environ $0.021 et $0.020 par exécution. La consommation électrique n'a pas été mesurée ; l'électricité par exécution se calcule ainsi : watts × secondes ÷ 3 600 000 × votre prix par kWh.

Le schéma pratique consiste à utiliser un modèle local principal avec un recours hébergé pour les tours qu'un modèle local échoue à traiter. OpenClaw accepte une liste de fallbacks par agent ; une clé Kunavo fonctionne comme fournisseur compatible OpenAI à côté d'Ollama, avec une facturation au token sur un solde prépayé. Personne chez Kunavo n'a exécuté OpenClaw contre son endpoint — ces exécutions étaient entièrement locales.

Questions fréquentes

Exécuté le 1er octobre 2026 sur un Apple M3 Max (128 Go) : OpenClaw 2026.9.7 (npm, Node 24.21.0), Ollama v0.35.0 (binaire de publication), gemma4:latest, gpt-oss:20b et qwen3-coder:30b téléchargés depuis le registre Ollama et vérifiés par sha256. Chacune des 36 exécutions utilisait un espace de travail vierge et un nouvel état OpenClaw, exec dans le bac à sable Docker d'OpenClaw et un évaluateur par script ; les appels d'outils et les décomptes de tokens proviennent de la sortie JSON d'OpenClaw. Les jeux de test des tâches, les évaluateurs et le script adaptateur sont publiés avec les éléments justificatifs de cette page. Non mesurés : consommation électrique, tâches longues, autres quantifications ou machines de moindre capacité.