Oh My Opencode-Review: Ehrliche Ergebnisse, Abrechnungsrisiken und wann es sich lohnt.

Was genau passiert, wenn Sie Ultrawork ausführen?

Inhaltsverzeichnis

Oh My Opencode verspricht ein „virtuelles KI-Entwicklerteam" — Sisyphus dirigiert Spezialisten, Aufgaben werden parallel ausgeführt und das magische Schlüsselwort ultrawork aktiviert alles.

Dieses Versprechen hält stand, wenn die richtige Arbeitslast vorliegt. Bei der falschen Arbeitslast fügt es Kosten und Komplexität hinzu, ohne die Ergebnisse zu verbessern. Dieser Artikel beleuchtet, was bei praktischen Tests tatsächlich passiert ist, und was die breitere Gemeinschaft nach Monaten der echten Nutzung festgestellt hat.

lazy agents working in parallel

Wenn Sie mit dem Stack noch neu sind:

Dieser Artikel geht davon aus, dass Sie mit dem System bereits vertraut sind und wissen möchten, ob es tatsächlich funktioniert. Für den breiteren Überblick, wie OMO in die KI-Entwickler-Toolchain passt, sehen Sie den Übersicht über KI-Entwicklerwerkzeuge.

Oh My Opencode-Leistung: Ergebnisse aus praktischen Tests

Ich führte dieselben Tests durch, die ich für nacktes OpenCode verwende — dieselben LLM-Benchmarkaufgaben, die ich gegen OpenCode mit lokalen Ollama- und llama.cpp-Modellen durchführte. Diesmal auf dem Big Pickle-Modell (GLM 4.6 über OpenCode Zen — die kostenlose Stufe).

Die kurze Version: gemischte Ergebnisse, und das Versagensmuster war belehrend.

Warum Sisyphus die Delegation ohne expliziten Ultrawork-Prompt überspringt

Das erste Problem, auf das ich stieß, war, dass Sisyphus ohne explizite Aufforderung sich nicht wie ein Dirigent verhielt. Selbst mit dem ulw-Präfix begann er, die gesamte Arbeit selbst zu erledigen — er las Dateien direkt, schrieb Code und übersprang die Forschungs- und Planungsphasen vollständig. Keine Delegation an Oracle, keine parallelen Explore-Läufe, kein Prometheus-Interview.

Um die Orchestrierung tatsächlich auszulösen, musste ich im Prompt explizit werden:

ulw recherchiere zuerst den Codebase,
erstelle einen detaillierten Plan,
delegiere Implementierungsaufgaben,
und führe direkte Arbeit nur selbst durch, wenn Delegation unvernünftig ist

Sobald ich das tat, verhielt sich das System wie beworben. Aber das Standardverhalten ohne diese Rahmung war einfach nacktes OpenCode mit einem schwereren Kontextfenster. Das ultrawork-Schlüsselwort allein ist keine Garantie für Delegation — es ist eine Voraussetzung dafür.

Test 1: IndexNow-CLI-Tool — Wo die Oh My Opencode-Orchestrierung ihre Früchte trägt

Die Aufgabe bestand darin, ein Befehlszeilen-Tool zu erstellen, das URLs zur IndexNow-API für die Suchmaschinen-Indizierung einreicht. Dies ist eine vernünftig abgegrenzte mehrstufige Aufgabe: API-Spezifikation lesen, CLI entwerfen, implementieren, testen.

Mit Oh My Opencode und expliziter Orchestrierungs-Aufforderung war das Ergebnis merklich besser als bei nacktem OpenCode. Das finale Tool extrahierte URLs korrekt aus sitemap.xml und sandte sie in Batches, zusätzlich zur Unterstützung standardmäßiger CLI-Optionen. Der Librarian-Agent, der die IndexNow-Dokumentation besorgte, lieferte Kontext, den der Lauf mit dem Basis-Modell verpasste.

oh my opencode indexnow session log

Dies ist die Art von Aufgabe, für die OMO gebaut ist: Forschung + Implementierung + einige Designentscheidungen. Der Overhead hat sich hier gelohnt.

Test 2: Seiten-Migrationszuordnung — Gleiches Ergebnis, dreimal so viele Tokens

Der zweite Test war eine Dokumentanalyse-Aufgabe: Klären, wohin Webseiten basierend auf ihren Slugs und einem Migrationsrichtlinien-Dokument migriert werden sollten.

Das Ergebnis war identisch mit dem nackten OpenCode-Lauf — gleiche Genauigkeit, gleiche Struktur, gleiche Entscheidungen. Aber der OMO-Lauf verbrauchte ungefähr dreimal so viele Tokens.

Dies ist eine Aufgabe mit einem einzigen Kontextfenster für das Reasoning. Es gibt keine Parallelität, die ausgenutzt werden könnte, und kein Spezialwissen, das von einem Subagenten hinzugezogen werden könnte. Die Orchestrierungsschicht fügte Overhead hinzu, ohne Mehrwert zu bieten. Für diese Art von Aufgabe ist nacktes OpenCode die bessere Wahl.

Modellauswahl: Warum schwächere Modelle bei Orchestrierungs-Overhead kämpfen

Das Ausführen auf Big Pickle (ein Modell der kostenlosen Stufe) offenbarte etwas, das die Gemeinschaft ebenfalls bemerkt hat: Schwächere Modelle sind empfindlicher gegenüber der Qualität des Harness als starke Modelle. Claude Opus ist robust genug, um gute Ergebnisse zu liefern, selbst mit einer schweren Orchestrierungsschicht darum herum. Ein kleineres Modell wie Big Pickle profitiert mehr von einem sauberen, fokussierten Prompt als von einer komplexen Multi-Agenten-Konfiguration, die Rauschen in den Kontext bringt.

Wenn Sie OMO mit Budget-Modellen ausführen, beginnen Sie einfacher. Verwenden Sie Orchestrierung für forschungsintensive Aufgaben, bei denen Librarian und Explore genuinely Informationen hinzufügen. Vermeiden Sie sie für reine Reasoning-Aufgaben, bei denen das Modell nur klare Eingaben und Platz zum Denken benötigt.

Oh My Opencode-Gemeinschaftsfindungen: Benchmarks, Abrechnung und reale Einschränkungen

Bevor man alles darauf setzt, ist es wert zu wissen, was die Gemeinschaft durch echte Nutzung gefunden hat — sowohl die Erfolge als auch die Versagensmuster.

Oh My Opencode-Benchmark: 69 % vs. 73 % Durchgangsraten, 3× mehr Anfragen als bei Vanilla OpenCode

Ein Gemeinschaftsmitglied führte einen systematischen Benchmark über 120+ Agenten/Modell-Kombinationen durch und veröffentlichte die Ergebnisse. Mit aktivierter OMO-Ultrawork lag die Durchgangsrate bei ihrer Codierungs-Evaluation bei 69,2 % — gegenüber 73,1 % für plain OpenCode ohne OMO. Der OMO-Lauf dauerte 10 Minuten länger (55 vs. 45 Minuten) und stellte 96 Anfragen anstatt 27.

Ihr Fazit: „Es ist buchstäblich nur Opus mit mehr Schritten." Opus ist besonders widerstandsfähig gegenüber Unterschieden im Harness — es liefert starke Ergebnisse, unabhängig davon, was drumherum ist. Schwächere Modelle zeigten mehr Empfindlichkeit gegenüber dem Harness, aber nicht unbedingt zu OMOs Gunsten.

Das bedeutet nicht, dass OMO nutzlos ist. Für große, mehrstufige Aufgaben, parallele Hintergrund-Agenten und komplexe Ingenieur-Workflows lohnt sich der Overhead. Aber für Codieraufgaben, die in ein einzelnes Kontextfenster passen, wird Vanilla OpenCode mit einem guten Modell oft einen vollständigen Orchestrierungs-Stack übertreffen oder gleichziehen.

Start-Token-Overhead: 15.000–25.000 Tokens, bevor überhaupt Arbeit beginnt

Ein wiederkehrendes Gemeinschaftsbeschwerde ist, dass OMO beim Start viele Tools und MCPs injiziert. Eine einfache „Hello world"-Nachricht kann 15.000–25.000 Tokens nur durch die Kontextfenster-Einrichtung verbrauchen, bevor überhaupt eigentliche Arbeit geleistet wird. Der Maintainer ist sich dessen bewusst und arbeitet an einer verzögerten Tool-Ladung, aber Stand Anfang 2026 ist dies eine reale Kosten, die in Schätzungen berücksichtigt werden muss.

Die 350 $-Gemini-Unendlichschleife — und was man dagegen tun kann

Im März 2026 führte ein bestätigter Fehler (Issue #2571, markiert als will-fix) dazu, dass einem Nutzer an einem Nachmittag etwa 438 $ in Rechnung gestellt wurden. Drei separate Probleme addierten sich:

  1. Keine Sicherheitskupplung: OMO hatte keine Maximalschritt-Grenze pro Subagenten. Ein Gemini-Modell steckte in einer git diff / read-Verifizierungsschleife fest und führte 809 aufeinanderfolgende Runden über 3,5 Stunden ohne Stoppen aus.

  2. Stille Modell-Routing: Die Sitzung des Nutzers war auf GPT-5.4. Aber eine delegierte Compose-UI-Aufgabe wurde über Kategorierouting (visual-engineering) an Gemini 3.1 Pro weitergeleitet — ein Modell, das der Nutzer nie bewusst ausgewählt hatte und das ihm keine Sichtbarkeit bot, bis er nachträglich in der SQLite-Datenbank grub.

  3. Falsche Kostenanzeige: Die Preissnapshot von OpenCode für gemini-3.1-pro-preview fehlte die Preisstufe für >200K Kontext. Google berechnet 2× für Kontexte über 200K Tokens, aber OpenCode berechnete alles zum Basispreis. Die angezeigten Kosten waren weniger als die Hälfte der tatsächlichen Google-Rechnung.

Ein Gemeinschaftskommentar fasste es zusammen: „Gemini gerät bei mir ständig in Schleifen, daher benutze ich es selten als nicht-read-only-Modell."

Eine Lösung (PR #2590) ist in Bearbeitung — Hinzufügen einer konfigurierbaren Maximalschritt-Grenze und Schleifenerkennung. Bis diese veröffentlicht ist, schützen Sie sich selbst:

  • Überprüfen Sie Ihre Kategorie-Konfiguration. Wenn irgendeine Kategorie auf Gemini gemappt ist (einschließlich visual-engineering standardmäßig), verwendet jede Hintergrundaufgabe in dieser Kategorie Gemini — stillschweigend — selbst wenn Ihre Vordergrundssitzung auf einem anderen Modell ist.
  • Setzen Sie explizite providerConcurrency-Grenzen für Gemini in background_task. Wenn Sie es auf 1 halten, begrenzen Sie den Explosionsradius.
  • Überprüfen Sie Ihre tatsächlichen Anbieter-Abrechnungs-Dashboards, nicht nur die von OpenCode angezeigten Kosten, besonders für Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // harte Obergrenze, bis die Sicherheitskupplung erscheint
    }
  }
}

Ultrawork-Delegation erfordert das Schlüsselwort — es ist nicht automatisch

Frühe Nutzer stellten fest, dass ohne ultrawork der Hauptagent oft gar nicht an spezialisierte Subagenten delegiert — er beginnt einfach, read und grep direkt aufzurufen. Der Maintainer gab dies früh zu: „Es scheint schwierig, das Aufrufen des passenden Agenten allein durch System-Prompt-Anweisungen ohne explizite Prompts zu erreichen."

Das ultrawork-Schlüsselwort ist das, was die Orchestrierung zuverlässig auslöst. Ohne es laufen Sie oft einfach nacktes OpenCode mit einem schwereren Kontextfenster. Das stimmt mit dem überein, was ich in meinen eigenen Tests feststellte.

Leichtere Alternativen zu OMO: OMO Slim und Oh-My-Pi

Wenn Sie die Hooks für die Hintergrundausführung und die Schlüsselfunktionen von OMO ohne den vollen Orchestrierungs-Overhead der Agenten wünschen, ist oh-my-opencode-slim ein Community-Fork, der den Funktionsumfang reduziert. Einige Nutzer sind auch zu oh-my-pi gewechselt, das sich auf die Ausführung von Hintergrundaufgaben und Hooks konzentriert, während es die Prompt-Oberfläche minimal hält.

Ein Nutzer fasste es gut zusammen: „Ich mag OMO für seine Hooks und die Ausführung von Hintergrundaufgaben. Ich denke, OMO slim versucht, die falschen Dinge zu optimieren. Die Basis-OpenCode-Prompts plus Hintergrundarbeiter und Hooks, die das Modell automatisch auffordern, fortzufahren, wenn es entscheidet, aufzuhören, wären für mich genug."

Die richtige Wahl hängt von Ihrem Aufgabenprofil ab. Große, mehrstufige Ingenieursarbeit rechtfertigt das volle OMO. Für alltägliche kürzere Aufgaben produziert ein schlankeres Harness oft bessere Ergebnisse bei geringeren Kosten.

Wann Oh My Opencode wirklich überperformt: Ergebnisse echter Nutzer

Um die Einschränkungen auszugleichen, hier ist, was Nutzer als die klarsten Siege von OMO berichten:

  • 8.000 ESLint-Warnungen in einem Tag beseitigt — parallele Explore-Agenten durchsuchen die Codebase, während Worker-Agenten gleichzeitig Korrekturen ausführen
  • 45.000 Zeilen Tauri-App über Nacht in eine SaaS-Web-App umgewandelt — Prometheus-Interview-Modus produzierte einen detaillierten Plan, Ralph Loop führte ihn von Anfang bis Ende aus
  • Full-Stack-Funktionen von Anfang bis Ende implementiert, ohne dass der Nutzer über den anfänglichen Prompt hinaus die Tastatur berühren musste
  • Architektur-Reviews auf übernommene Codebases — Oracles read-only-Beratungsrolle bringt Probleme ans Licht, ohne versehentlich Änderungen vorzunehmen

Der gemeinsame Nenner: Aufgaben, die von Parallelität profitieren und klare Akzeptanzkriterien haben, die Prometheus verifizieren kann. Aufgaben, bei denen ein einzelnes fokussiertes Modell gut abschneiden würde, profitieren wenig vom Orchestrierungs-Overhead.

Oh My Opencode vs. Vanilla OpenCode: Wann man welches verwendet

Oh My Opencode ist nicht universell besser als Vanilla OpenCode. Es ist ein Leistungsmultiplikator für eine bestimmte Klasse von Arbeit — und Overhead für alles andere.

Verwenden Sie den vollständigen OMO-Stack (mit ultrawork), wenn:

  • Die Aufgabe sich über mehrere Dateien und Ebenen erstreckt
  • Sie Forschung, Planung, Implementierung und Verifizierung als separate Phasen benötigen
  • Sie von parallelen Hintergrund-Agenten (Explore, Librarian) profitieren, die Kontext sammeln, während Worker laufen
  • Der Umfang groß genug ist, dass Sie sonst den Agenten durch mehrere sequenzielle Prompts babysitten müssten

Verwenden Sie Vanilla OpenCode (oder ein schlankeres Harness), wenn:

  • Die Aufgabe in ein einzelnes Kontextfenster passt
  • Das Problem reines Reasoning ohne externe Recherche ist
  • Sie Budget-Modelle ausführen — sie profitieren mehr von einem sauberen, fokussierten Prompt als von Orchestrierungskomplexität
  • Sie vorhersehbare Abrechnung ohne Überraschungen durch Kategorierouting wünschen

Das Abrechnungsrisiko ist real und unterberichtet. Bis die Sicherheitskupplung landet, behandeln Sie OMO mit Gemini als eine Sache, die aktive Überwachung erfordert — nicht als ein „Abschießen und Vergessen"-System. Für alles andere ist das System wirklich beeindruckend, wenn es auf das richtige Problem ausgerichtet ist.

Quellen

Gemeinschaftsdiskussionen und Issues, die in diesem Artikel referenziert werden: