Bestes lokales Modell für OpenClaw: gemma4, gpt-oss:20b und qwen3-coder:30b, gemessen anhand von vier Agentenaufgaben

Auf einem M3 Max mit 128 GB, auf dem OpenClaw 2026.9.7 mit Ollama 0.35.0 lief, bestand gemma4 – das Modell, das OpenClaws eigene Ollama-Einrichtung empfiehlt – alle 12 bewerteten Durchläufe über vier Agentenaufgaben; gpt-oss:20b bestand 11 von 12 mit fast dreimal so vielen fehlgeschlagenen Tool-Aufrufen; und qwen3-coder:30b, die übliche Wahl fürs Programmieren, bestand 2 von 12, weil seine Tool-Aufrufe im Ollama-Parser wiederholt fehlschlugen. Wir führten jedes Modell dreimal pro Aufgabe in einem frischen Arbeitsbereich aus, bewerteten das Ergebnis per Skript und zeichneten OpenClaws eigene Tool- und Tokenzählungen sowie Ollamas Serverprotokoll auf. Gemessen am 1. Oktober 2026.

Was OpenClaw selbst kostet und was ein gehostetes Modell stattdessen kosten würde, findest du unter OpenClaw-Preise; zum Ausführen eines lokalen Modells mit API-Fallback unter Mehrere Agenten und Modelle in OpenClaw.

Was ausgeführt wurde

Die vier Aufgaben

Ergebnisse

Die Zeiten sind die Wall-Clock-Zeit pro Durchlauf, einschließlich etwa fünf bis sieben Sekunden für den OpenClaw-Start. „Tokens ein“ sind die ungecachten Eingaben, wie OpenClaw sie aufgezeichnet hat; der aus dem Cache erneut gesendete Kontext kommt hinzu und wird im folgenden Kostenabschnitt gezählt. Die Spalte für fehlgeschlagene Tool-Aufrufe zählt die von OpenClaw aufgezeichneten Fehler; die Fehler von qwen3-coder traten auf, bevor ein Aufruf OpenClaw erreichte, daher werden sie dort als null angezeigt und unten erklärt.

Was die Zahlen aussagen

• gemma4 und gpt-oss:20b sind beide für kurze Agentenaufgaben brauchbar. 23 ihrer 24 Durchläufe bestanden, einschließlich des Zwei-Dateien-Fixes, der das Lesen mehrerer Module, die Bearbeitung von zwei Modulen und einen erneuten Testlauf erfordert.
• gemma4 verwendete Tools sauberer. Bei der Leseaufgabe führte es jedes Mal genau einen Tool-Aufruf aus; gpt-oss führte drei aus, von denen gewöhnlich zwei fehlschlugen, bevor es die Datei las. Über alle zwölf Durchläufe hatte gpt-oss 19 fehlgeschlagene Tool-Aufrufe gegenüber 7 bei gemma4 und durchschnittlich 9.1 Assistant-Turns pro Aufgabe gegenüber 6.8 bei gemma4.
• Der einzige Fehler war gpt-oss bei der Zählaufgabe: Nach dreizehn Tool-Aufrufen schrieb es eine fehlerhafte counts.json und beendete den Turn ohne Antwort.
• Geschwindigkeit ist hier nicht der entscheidende Unterschied. Der Median lag über alle Durchläufe bei 53 s für gemma4 und 54 s für gpt-oss; der langsamste einzelne Durchlauf war gemma4s 133-s-Durchlauf beim Zwei-Dateien-Fix mit siebzehn Tool-Aufrufen. Die Durchläufe von qwen3-coder waren nur deshalb kürzer, weil sie früh fehlschlugen.
• Die größeren Modelle brachten bei diesen Aufgaben keine höhere Genauigkeit. gpt-oss:20b hat fast dreimal so viele Parameter wie gemma4, und qwen3-coder:30b, das für Code entwickelt wurde, erzielte von den drei Modellen das niedrigste Ergebnis.

Zwölf Durchläufe pro Modell reichen aus, um bei diesen Aufgaben ein Muster zu erkennen, aber nicht, um Modelle allgemein zu bewerten. Lange Aufgaben, größere Codebasen und andere Quantisierungen wurden nicht getestet.

Warum qwen3-coder:30b fehlschlug

Nicht beim Programmieren. Von den zehn fehlgeschlagenen Durchläufen:

• Fünf endeten im Ollama-Parser. qwen3-coder schreibt Tool-Aufrufe als XML, und wenn ein Argument Code enthielt, schloss es ein <parameter>-Element mit </function>. Ollamas Serverprotokoll bei 0.35.0 verzeichnete "qwen tool call parsing failed … XML syntax error … element <parameter> closed by </function>", und OpenClaw beendete den Turn mit "Agent run failed".
• Vier führten nie einen Aufruf aus. Die Antwort kündigte den nächsten Schritt an und gab dann ein einzelnes </tool_call> als Text aus, ohne etwas, das Ollama als Aufruf parsen konnte; der Turn endete dort. Das ist das Symptom, das OpenClaws Dokumentation mit der /v1-URL verbindet – hier trat es bei der nativen API auf.
• Einer war eine falsche Antwort: Das Modell zählte die CSV-Kopfzeilen als Datenzeilen.

Der Parser gehört zu Ollama, daher ist dies ein Ergebnis für Ollama 0.35.0 und kein Urteil über das Modell. Wenn du qwen3-coder mit OpenClaw ausführst, beobachte das Protokoll von ollama serve auf "qwen tool call parsing failed", bevor du das Modell verantwortlich machst, und teste nach einem Ollama-Upgrade erneut.

Die entscheidenden Einstellungen

• Native Ollama-URL. OpenClaws Dokumentation sagt, dass die /v1 OpenAI-kompatible URL „Tool-Aufrufe kaputt macht und Modelle rohes Tool-Call-JSON als einfachen Text ausgeben können“; die Durchläufe verwendeten baseUrl ohne /v1, zusammen mit api: "ollama".
• Bei manuell geschriebenen Einträgen contextWindow festlegen. In einem Smoke-Test ergab ein expliziter Modelleintrag ohne diese Einstellung einen Kontext von 200.000 Tokens; OpenClaws eigene Ollama-Einrichtung trägt 32.768 für lokale Modelle ein, und genau das wurde in diesen Durchläufen verwendet.
• Ollamas Kontext ist getrennt. Ollama 0.35.0 lud gemma4 und gpt-oss mit 131.072 Tokens und qwen3-coder mit 262.144 – 45.3 GB resident –, unabhängig von OpenClaws 32.768; das bestimmt den Speicherbedarf, nicht OpenClaws Budget.
• Die Shell sandboxen. Ein lokales Modell, das Shell-Befehle auf deinem Rechner ausführt, ist hier das eigentliche Risiko. Mit sandbox.mode: "all" lief exec im Docker-Image von OpenClaw, wobei nur der Arbeitsbereich eingebunden war; das Image wird einmal mit dem Befehl docker build aus OpenClaws Sandbox-Dokumentation erstellt.

// ~/.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" } },
}

Was lokale Ausführung kostet

Ein lokales Modell ersetzt eine Rechnung pro Token durch Zeit, Speicherplatz und Strom. Pro Durchlauf zeichnete OpenClaw für gemma4 etwa 16,415 ungecachete Eingabetokens, 78,469 Tokens erneut gesendeten gecachten Kontexts und 1,142 Ausgabetokens auf, für gpt-oss 13,761, 88,688 und 1,192. Als grobe Rechnung – Tokenizer unterscheiden sich zwischen Modellen – ergeben dieselben Mengen zu den Kunavo-Tarifen von Claude Haiku 4.5 ($0.70 Eingabe, $0.07 gecacht, $3.50 Ausgabe pro Million) etwa $0.021 und $0.020 pro Durchlauf. Der Stromverbrauch wurde nicht gemessen; die Stromkosten pro Durchlauf berechnen sich als Watt × Sekunden ÷ 3.600.000 × dein Preis pro kWh.

Das praktische Muster ist ein lokales Primärmodell mit einem gehosteten Fallback für die Turns, bei denen das lokale Modell fehlschlägt. OpenClaw akzeptiert eine fallbacks-Liste pro Agent; ein Kunavo-Schlüssel funktioniert neben Ollama als OpenAI-kompatibler Provider und wird pro Token aus einem vorausbezahlten Guthaben abgerechnet. Niemand bei Kunavo hat OpenClaw gegen seinen Endpunkt ausgeführt – diese Durchläufe waren vollständig lokal.

Häufig gestellte Fragen

Ausgeführt am 1. Oktober 2026 auf einem Apple M3 Max (128 GB): OpenClaw 2026.9.7 (npm, Node 24.21.0), Ollama v0.35.0 (Release-Binary), gemma4:latest, gpt-oss:20b und qwen3-coder:30b aus der Ollama-Registry, geprüft per sha256. Jeder der 36 Durchläufe verwendete einen frischen Arbeitsbereich und einen frischen OpenClaw-Zustand, exec in OpenClaws Docker-Sandbox und einen Skript-Grader; Tool-Aufrufe und Tokenzahlen stammen aus OpenClaws eigener JSON-Ausgabe. Aufgaben-Fixtures, Grader und das Adapter-Skript werden mit den Belegen dieser Seite veröffentlicht. Nicht gemessen: Stromverbrauch, lange Aufgaben, andere Quantisierungen oder kleinere Geräte.