Oh My Opencode: Multi-Agent-Setup für OpenCode erklärt

Robin, Pexon Consulting | 10 Min. Lesezeit | 22.07.2026

TL;DR

Oh My Opencode ist ein Community-Plugin, das den Open-Source-Coding-Agenten OpenCode in ein Multi-Agent-System verwandelt: Der Orchestrator Sisyphus koordiniert elf spezialisierte Agenten, jeder mit eigenem Modell je nach Aufgabe. Pexon überträgt genau dieses Muster, Orchestrierung plus Model-Routing, auf produktive Enterprise-Agenten, als 6-Wochen-Pilot.

Was ist Oh My Opencode?

Oh My Opencode (kurz „omo“, teils auch oh-my-openagent) ist ein Community-Plugin, das den Open-Source-Coding-Agenten OpenCode zu einem vollständigen Multi-Agent-Engineering-System ausbaut. OpenCode selbst ist der aktuell meistgenutzte quelloffene Coding-Agent im Terminal, gebaut von Anomaly unter MIT-Lizenz, mit über 180.000 GitHub-Sternen (Stand Juni 2026) und Unterstützung für mehr als 75 Modell-Anbieter samt lokaler Modelle über Ollama.

Das Plugin legt darüber eine Orchestrierungs-Schicht. Im Zentrum steht Sisyphus, benannt nach der Figur, die den Felsen ewig den Berg hochrollt: ein Orchestrator, der Aufgaben plant, an Spezial-Agenten delegiert und über aggressive Parallelausführung zu Ende treibt. Dazu kommen elf spezialisierte Agenten mit eigenen Rollen, expliziten Tool-Rechten und Prompts, die pro Modellfamilie getunt sind, plus IDE-taugliches Refactoring über LSP und AST-Grep und vorkonfigurierte MCP-Server für Websuche, Doku-Lookup und GitHub-Suche.

Für IT-Leiter ist das mehr als ein Entwickler-Spielzeug. Es ist ein sauber gebautes Anschauungsobjekt dafür, wie ein produktives Agenten-System aussieht: getrennte Verantwortung für Orchestrierung, Planung, Ausführung und Recherche.

Warum jeder Agent ein anderes Modell bekommt

Die zentrale Designidee ist unbequem, aber richtig: Verschiedene Modelle denken verschieden, und jeder Agenten-Prompt ist für genau eine Denkweise geschrieben. Claude folgt mechanik-getriebenen Prompts, also detaillierten Checklisten und Schritt-für-Schritt-Vorgaben. Mehr Regeln bedeuten hier mehr Befolgung. GPT dagegen folgt prinzipien-getriebenen Prompts, also knappen Leitsätzen mit klaren Entscheidungskriterien. Gibt man GPT einen 1.100-Zeilen-Claude-Prompt, widerspricht es sich selbst. Gibt man Claude einen kompakten GPT-Prompt, driftet es ab.

Das ist kein Bug, den man wegkonfiguriert, sondern das Systemdesign. Die praktische Konsequenz: Wer bei einem Agenten das Modell wechselt, wechselt implizit die passende Prompt-Strategie mit. Manche Agenten erkennen die Modellfamilie zur Laufzeit und schalten den Prompt automatisch um. Andere haben nur einen Prompt für eine Familie, und ein Wechsel auf die falsche Seite verschlechtert das Ergebnis spürbar.

Unsere klare Position: Genau diese Prompt-pro-Modell-Disziplin ist der Unterschied zwischen einem Agenten-System, das in Produktion trägt, und einem, das im Demo funktioniert und danach zerfällt.

Die Agenten-Crew in vier Gruppen

Die elf Agenten lassen sich in vier Gruppen nach ihrer Aufgabe und ihrem Modellbedarf sortieren.

• Orchestratoren: Sisyphus (Team-Lead, koordiniert über die ganze Codebasis) und Atlas (Todo-Listen-Treiber). Sie brauchen Modelle, die komplexe Anweisungen über dutzende Tool-Aufrufe zuverlässig befolgen.
• Planer: Prometheus (interviewt wie ein echter Engineer, bevor eine Zeile Code entsteht), Metis (Lücken-Analyse: „Was haben wir übersehen?“) und Momus (gnadenloser Plan-Reviewer). Die Planungs-Schicht erzwingt Denken vor Handeln.
• Worker: Hephaestus (autonomer Deep-Worker, bekommt ein Ziel statt eines Rezepts) und Sisyphus-Junior (dynamisch gespawnter Ausführer, erbt sein Modell aus der Kategorie).
• Utility-Runner: Explore (schnelle Codebasis-Suche), Librarian (Doku-Recherche) und Multimodal Looker (Bild- und Diagramm-Analyse). Bewusst auf den schnellsten, günstigsten Modellen.

Ein Satz aus der Community bringt die Logik auf den Punkt: Explore auf ein Top-Modell hochzustufen ist, als ließe man einen Senior-Engineer die Ablage machen. Recherche und Grep brauchen Geschwindigkeit, nicht Reasoning-Tiefe. Genau diese Utility-Agenten sind auch die besten Kandidaten, um sie durch lokale Modelle zu ersetzen.

Model Routing per Kategorie und lokale Modelle

Wenn Sisyphus delegiert, wählt es keine Modell-ID, sondern eine Kategorie, etwa „deep“ für komplexe Logik oder „writing“ für Text. Die Kategorie mappt automatisch auf das passende Modell mit einer Fallback-Kette. Das ist auch die richtige Abstraktion fürs Self-Hosting: Mappt man eine Kategorie auf ein lokales Modell, nutzt jede Aufgabe dieser Kategorie automatisch das lokale Modell.

Praktisch braucht es zwei Schichten. Erstens muss OpenCode den lokalen Anbieter kennen:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": {
        "qwen2.5-coder:7b":  { "name": "qwen2.5-coder:7b" },
        "qwen2.5-coder:32b": { "name": "qwen2.5-coder:32b" }
      }
    }
  }
}

Zweitens sagt man Oh My Opencode, welcher Agent welches Modell nutzt, denn die meisten Agenten ignorieren das im UI gewählte Modell bewusst:

{
  "agents": {
    // Utility-Agenten: schnelles lokales Modell reicht voellig
    "explore":   { "model": "ollama/qwen2.5-coder:7b", "temperature": 0.1 },
    "librarian": { "model": "ollama/qwen2.5-coder:7b", "temperature": 0.1 }
  },
  "categories": {
    // Einfache Aufgaben lokal, schweres Reasoning in der Cloud
    "quick": { "model": "ollama/qwen2.5-coder:7b" }
  }
}

Ein Hinweis aus der Praxis: OpenCode braucht für die Orchestrierungs-Agenten mindestens ein 64k-Kontextfenster, sonst gibt es mitten im Workflow Abschneide-Fehler. Utility-Agenten wie Explore und Librarian laufen dagegen schon auf einem kleinen lokalen Coder-Modell gut. Wer das Prinzip vertiefen will, findet in unserem Beitrag zum LLM Model Routing die Kostenlogik dahinter. Den souveränen Unterbau für die lokalen Modelle behandeln wir separat (siehe Verwandte Themen).

Was das für Enterprise-Agenten heißt

Oh My Opencode ist ein Entwickler-Werkzeug, aber die Architektur dahinter ist genau das, was ein produktives Agenten-System braucht: getrennte Rollen, das passende Modell pro Aufgabe, Parallelität mit Grenzen und eingebautes Kontext-Management. Der Sprung vom coolen Terminal-Setup zum belastbaren Unternehmens-System liegt nicht in der Idee, sondern im Betrieb.

Ein Dev-Plugin muss nicht DSGVO-konform sein, keine Rollen und Audit-Logs mitbringen, nicht ausfallsicher laufen und nicht messbar zuverlässig sein. Ein Enterprise-Agent schon. Genau diese Schicht, also Orchestrierung sauber gebaut, Model-Routing eval-gestützt, Governance und Betrieb inklusive, ist unser Thema (siehe Verwandte Themen). Wie sich so ein System in einen Gesamt-Stack fügt, beschreiben wir im AI Engineering Stack.

Häufig gestellte Fragen

Was ist der Unterschied zwischen OpenCode und Oh My Opencode?

OpenCode ist der quelloffene Coding-Agent im Terminal, ein Einzel-Agent mit einem Modell. Oh My Opencode ist ein Plugin darauf, das aus diesem Einzel-Agenten ein koordiniertes Team aus elf spezialisierten Agenten mit dem Orchestrator Sisyphus macht, jeder mit eigenem Modell und eigenen Rechten.

Warum nutzt Oh My Opencode nicht einfach ein Modell für alles?

Weil Prompts pro Modellfamilie geschrieben sind. Claude braucht mechanik-getriebene, detaillierte Anweisungen, GPT prinzipien-getriebene, knappe. Ein Modell für alles würde bedeuten, dass die Hälfte der Agenten mit dem falschen Prompt-Stil läuft und schlechter arbeitet. Die Trennung ist Absicht.

Kann ich Oh My Opencode mit lokalen Modellen betreiben?

Teilweise ja. Utility-Agenten wie Explore und Librarian laufen problemlos auf einem lokalen Coder-Modell über Ollama. Orchestrierung und komplexes Reasoning brauchen dagegen starke Modelle mit mindestens 64k Kontext, hier ist ein hybrider Betrieb (Utility lokal, Reasoning in der Cloud) der pragmatische Weg.

Ist das für Unternehmen einsetzbar oder nur für einzelne Entwickler?

Als Werkzeug ist es auf einzelne Entwickler zugeschnitten. Die Architektur ist übertragbar, aber ein produktives Unternehmens-Agenten-System braucht zusätzlich DSGVO-Konformität, SSO, Audit-Logs, Ausfallsicherheit und Monitoring. Das ist der Sprung, den wir mit Kunden gehen.

Was kostet der Betrieb eines Multi-Agent-Setups?

Das hängt am Modell-Mix. Wer alle Agenten auf Frontier-Modelle setzt, zahlt drauf. Der Trick ist das kategoriebasierte Routing: Utility- und Standardaufgaben auf günstige oder lokale Modelle, nur komplexes Reasoning auf Frontier. So bleibt der Löwenanteil der Aufrufe günstig.

Nächster Schritt

Sie sehen bei Oh My Opencode, wie ein Multi-Agent-System aufgebaut ist, und fragen sich, wie so etwas produktiv in Ihrem Unternehmen aussieht? Wir klären in einem kurzen Gespräch, welcher Anwendungsfall bei Ihnen ein orchestriertes Agenten-System trägt.

Verwandte Themen