Als David Ondrej am 25. April einen Clip postete, in dem "Gemini 3.1 Pro" zehn Nachrichten hintereinander in OpenClaw wiederholte — sich selbst zitierte, nicht aufhören wollte und schließlich stehen blieb — brachte er die Frage auf den Punkt, die jedes Team mit OpenClaw irgendwann stellt: Welches Modell funktioniert in dieser Umgebung wirklich, und welche fallen leise auseinander? Marketing-Benchmarks beantworten diese Frage nicht. Leaderboards auch nicht. Nur der echte Einsatz.
Wir betreiben OpenClaw seit einigen Monaten in Kundenprojekten und tauschen Modelle aus, sobald neue verfügbar sind. Das hier ist der Praxis-Leitfaden, den wir uns zu Beginn gewünscht hätten: welchen Modellen wir in OpenClaw heute vertrauen, welche wir nicht mehr verwenden und wie Sie für Ihren eigenen Workload entscheiden.
Was "am besten" in OpenClaw bedeutet
OpenClaw ist keine Chat-Box. Es ist ein agentisches Framework: Tool-Nutzung, Datei-Bearbeitung, lange Task-Schleifen, persistenter Kontext, Hooks und eine CLI für Cron-artige Automatisierung. Ein Modell mit 90 Punkten im Coding-Benchmark kann trotzdem die falsche Wahl sein, wenn es OpenClaws Hook-Konventionen ignoriert, Tool-Call-Verträge bricht oder das Kontextfenster verbrennt, indem es dieselbe Datei viermal hintereinander liest.
Drei Eigenschaften zählen mehr als Benchmark-Zahlen:
- Tool-Call-Disziplin — ruft es das richtige Tool mit dem richtigen Schema beim ersten Versuch auf?
- Stopp-Disziplin — weiß es, wann der Task fertig ist, oder läuft es in Schleifen?
- Kontext-Ökonomie — liest es noch einmal, was bereits im Kontext steht, oder vertraut es darauf?
Fast alles andere folgt daraus. Wir bewerten jedes Modell in unseren Deployment-Notizen anhand dieser drei Punkte. So sehen die wichtigsten Frontier-Optionen Ende April 2026 aus.
Sonnet 4.6 — der Default, der seinen Platz verdient
Anthropic Claude Sonnet 4.6 ist das Modell, das wir in fast jedem OpenClaw-Deployment als Default setzen — und es hat sich diesen Platz erarbeitet, nicht geschenkt bekommen. Tool-Call-Disziplin: ausgezeichnet. Stopp-Disziplin: Klassenbester — wenn ein Sonnet-4.6-Task fertig ist, hört er auf. Es liest selten Dateien neu, die ihm gerade gezeigt wurden. Das Kosten-pro-Task-Verhältnis für typische Agent-Workflows liegt etwa dort, wo Haiku vor der Preisanpassung lag.
Wo es schwächelt: tiefe Multi-Step-Refactors in unbekannten Codebases brauchen manchmal eine schärfere Klinge. Bei Code-Review, Architekturentscheidungen oder Debugging-Spuren mit langer Ursache-Wirkung-Kette gibt Sonnet 4.6 gelegentlich zu früh auf. Genau dann greifen wir zu Opus.
Eine tiefere Einordnung, warum sich agentische Arbeit hin zu diesem Modell verschoben hat, finden Sie in unserem Beitrag zu dem agentischen Arbeitsmodell, das OpenAI gegen den Claude-Mythos geliefert hat.
Opus 4.7 — wenn Reasoning-Tiefe sich wirklich auszahlt
Opus 4.7 ist das Schwergewicht. Wir setzen es nicht als Default ein, weil die Kosten pro Task schnell summieren — aber es ist unser Eskalationspfad für drei Job-Klassen:
- Komplexes Debugging, bei dem die Ursache-Wirkung-Kette mehrere Dateien umspannt und die Symptome irreführend sind
- Architekturentscheidungen, bei denen das Modell Trade-offs ehrlich abwägen muss, statt die erste plausible Antwort zu wählen
- One-Shot-Aufgaben mit hohem Risiko wie Migrationsskripte, Schema-Änderungen oder alles, was Produktionsdaten berührt
Opus 4.7 ist auch das Modell, dem wir am meisten vertrauen, wenn adaptives Denken zählt — also wenn das Modell Reasoning-Tokens investieren soll, bevor es einen Tool-Call commit. Die Kosten sind real, aber die Erfolgsquote bei harten Aufgaben rechtfertigt sie. Faustregel: Wenn ein Sonnet-Lauf zweimal mit ähnlichen Fehlern scheitert, eskalieren Sie auf Opus statt zu wiederholen.
GPT-5.5 in OpenClaw — starker Coder, falsches Werkzeug für jetzt
GPT-5.5 in OpenClaw ist gleichzeitig interessant und frustrierend. Als reiner Coder ist es stark, und OpenAIs Bestätigung, dass GPT-5.5 = Codex ist (Romain Huet, 25. April), bedeutet, dass es kein "Codex fürs Coden, GPT-5.5 für allgemeine Aufgaben" mehr gibt. Ein Modell, zwei Frameworks.
Aber OpenClaw ist nicht sein Framework. Wir sehen zwei wiederkehrende Fehlermuster, wenn wir GPT-5.5 in OpenClaw einbinden:
- Tool-Call-Schema-Drift — es erfindet gelegentlich Tool-Felder, die nicht existieren, vor allem in längeren Kontexten
- Lockerere Stopp-Disziplin — es produziert häufiger als Sonnet 4.6 Füllertexte vom Typ "Ich arbeite weiter daran"
Für OpenClaw lautet unsere Empfehlung heute: Lassen Sie GPT-5.5 in der Codex-CLI, wo seine Konventionen zu seinem Training passen, und behalten Sie Anthropic-Modelle in OpenClaw. Das kann sich verschieben, sobald sich das Framework um andere Provider weiterentwickelt. Wir testen bei jedem Minor-Release.
DeepSeek V4 — Kostendisruption, die echtes Testing braucht
DeepSeek V4 (1,6 Billionen Parameter, MIT-Lizenz, drastisch günstiger als Opus bei vergleichbaren Aufgaben) ist gerade gelandet. Die Preisimplikationen haben wir ausführlich in unserem DeepSeek-V4-Preisbeben-Beitrag behandelt.
In OpenClaw zeigen unsere ersten Tests, dass DeepSeek V4 Flash 70-80 % typischer Haiku-Workloads zu einem Bruchteil der Kosten erledigt. V4 Pro ist bei isolierten Reasoning-Aufgaben ernsthaft konkurrenzfähig zu Opus, allerdings hinkt die Stopp-Disziplin den Anthropic-Modellen hinterher. Wir sind noch nicht bereit, es als Default in Kundendeployments zu empfehlen — zu früh, um zu wissen, wie es sich in langen Agent-Schleifen verhält, und die Open-Weights-Variante erfordert Self-Hosting-Infrastruktur, die die meisten Teams nicht haben.
Wenn Sie kostensensibel sind und in Evaluierung investieren wollen: Beginnen Sie mit V4 Flash auf risikoarmen OpenClaw-Cron-Jobs (Intel-Scans, Zusammenfassungen, Content-Quality-Checks) und messen Sie Stopp-Disziplin und Tool-Call-Genauigkeit. Setzen Sie es nicht in produktionsnahen Jobs ein, bevor Sie eine Stabilitätshistorie über mehrere Wochen haben.
Modelle, die wir getestet haben und nicht empfehlen
Einige Signale aus den letzten sechs Monaten Deployment-Arbeit:
- Gemini 2.5 Pro und 3.x-Varianten: Inkonsistent in OpenClaw. Der Ondrej-Bericht passt zu unseren eigenen Tests. Das Modell ist stark in seiner eigenen Umgebung (Vertex, AI Studio), respektiert aber OpenClaws Tool-Konventionen nicht zuverlässig. Wir greifen nicht mehr darauf zu.
- Nemotron und Qwen Mid-Tier: Gut als Fallback in unserer Cost-Cascade, aber Timeout-Raten steigen in längeren Kontexten. Nur für Kurzbursts geeignet.
- Ältere Claude-Versionen (3.5, 4.0, 4.5): Überholt. Kein Grund, diese zu nutzen, sofern es nicht aus Kostengründen muss.
Mehr Provider-Kontext finden Sie in unserer Analyse zu agentischer Compute-Pricing.
So wählen Sie aus: Eine Entscheidungsmatrix
So gehen wir vor, wenn ein Kunde fragt: "Welches Modell sollen wir einsetzen?"
| Workload | Default | Eskalation auf | Warum |
|---|---|---|---|
| Tägliche Cron-Jobs (Audit, Scan, Summarize) | Sonnet 4.6 | Opus 4.7 wenn Genauigkeit kritisch | Sonnets Stopp-Disziplin hält Kosten planbar |
| Code-Generierung und -Review | Sonnet 4.6 | Opus 4.7 für harte Bugs | GPT-5.5 in OpenClaw überspringen; in Codex-CLI nutzen |
| One-Shot-Aufgaben mit hohem Risiko (Migrationen, Prod-Fixes) | Opus 4.7 | — | Kosten gerechtfertigt durch Single-Failure-Kosten |
| Kostensensible Bulk-Arbeit | DeepSeek V4 Flash (Test) | Sonnet 4.6 | Stopp-Disziplin validieren vor Skalierung |
| Multimodale Aufgaben (Vision, Audio) | Sonnet 4.6 mit Vision | Opus 4.7 | Konsistentestes Verhalten in OpenClaw |
Der Hebel, den wir am häufigsten ziehen: bei Retry von Sonnet auf Opus eskalieren, niemals umgekehrt. Wenn Sonnet zweimal scheitert, löst Opus es meistens beim ersten Versuch. Wenn Opus scheitert, hilft ein Retry mit Opus selten — der Task braucht wahrscheinlich ein anderes Framing.
FAQ
Q: Kann ich Modelle mitten im Task in OpenClaw wechseln? Ja — OpenClaw unterstützt Modellwechsel per CLI-Flag oder Per-Job-Config. Wir nutzen das in unserer Cron-Fallback-Cascade: Wenn Sonnet zweimal in Timeout läuft, versucht der nächste Lauf automatisch einen anderen Provider. Richten Sie das ein, bevor Sie es brauchen.
Q: Ist "Gemini 3.1 Pro" tatsächlich ein veröffentlichtes Modell? Stand 26. April 2026 finden wir keine offizielle Google-Ankündigung für "Gemini 3.1 Pro". Das Video von David Ondrej könnte sich auf einen internen Namen oder einen stillen Rollout beziehen. Behandeln Sie jede "Gemini 3.x"-Behauptung als unbestätigt, bis Googles Blog sie bestätigt.
Q: Sollte ich "zur Sicherheit" immer das stärkste Modell nutzen? Nein. Opus 4.7 für einen Job, den Sonnet 4.6 gut erledigt, kostet das Fünf- bis Zehnfache für dasselbe Ergebnis, und die längeren Reasoning-Loops können eigene Fehlermuster einbringen. Passen Sie das Modell an den Workload an — eskalieren Sie bei Retry, nicht per Default.
Q: Wie oft sollte ich neu testen, welches Modell am besten passt? Mindestens monatlich, wöchentlich wenn Sie produktive OpenClaw-Deployments betreiben. Modellverhalten verschiebt sich nach jedem Minor-Release, und Framework-Kompatibilität ändert sich schneller, als Benchmark-Werte vermuten lassen.
Fazit
Für die meisten Teams, die OpenClaw in 2026 betreiben, ist der richtige Default Sonnet 4.6 mit Opus 4.7 als Eskalationspfad. GPT-5.5 gehört in die Codex-CLI, nicht in OpenClaw. DeepSeek V4 ist eine Evaluierung wert für kostensensible Workloads, ist aber in diesem Framework noch nicht produktionsreif. Gemini-Varianten bleiben inkonsistent.
Die Benchmark-Werte werden sich weiter verschieben. Was in OpenClaw zählt, ist Tool-Call-Disziplin, Stopp-Disziplin und Kontext-Ökonomie — und auf diesen drei Achsen liegen die Anthropic-Modelle weiter vorne.
Wenn Sie Hilfe beim Aufsetzen der richtigen Modell-Cascade für Ihr OpenClaw-Deployment brauchen — Defaults, Fallbacks, Eskalationsregeln — vereinbaren Sie ein Discovery-Gespräch mit Context Studios. Wir haben das für genug Kunden gemacht, um die Trial-and-Error-Phase zu überspringen.