Oh My Opencode Beoordeling: Eerlijke Resultaten, Factureringsrisico's en Wanneer het de Loon waard is

Wat gebeurt er eigenlijk als je Ultrawork uitvoert?

Inhoud

Oh My Opencode belooft een “virtueel AI-ontwikkelteam” — Sisyphus die specialisten coördineert, taken die parallel worden uitgevoerd en het magische ultrawork-sleutelwoord dat alles activeert.

Die belofte komt waar voor de juiste werklast. Voor de verkeerde werklast voegt het kosten en complexiteit toe zonder de resultaten te verbeteren. Dit artikel behandelt wat er in de praktijk gebeurde tijdens hands-on testen en wat de bredere gemeenschap heeft ontdekt na maanden van daadwerkelijk gebruik.

lazy agents working in parallel

Als u nieuw bent met de stack,

Dit artikel gaat ervan uit dat u al bekend bent met het systeem en wilt weten of het daadwerkelijk presteert. Voor het bredere beeld van hoe OMO past in de AI-coderings-toolchain, zie het overzicht van AI-ontwikkeltools.

Oh My Opencode-prestaties: Resultaten van hands-on testen

Ik voerde dezelfde tests uit die ik gebruik voor OpenCode zonder toevoegingen — dezelfde LLM-benchmarktaken die ik uitvoerde tegen OpenCode met lokale Ollama- en llama.cpp-modellen. Deze keer op het Big Pickle-model (GLM 4.6 via OpenCode Zen — het gratis tier).

De korte versie: gemengde resultaten, en het failure-modus was instructief.

Waarom Sisyphus delegatie overslaat zonder een expliciete Ultrawork-prompt

Het eerste waar ik tegenaan liep, was dat Sisyphus zich niet gedroeg als een orchestrator zonder expliciete prompting. Zelfs met het ulw-prefix begon hij al het werk zelf te doen — bestanden direct lezen, code schrijven en de fasen voor onderzoek en planning volledig overslaan. Geen delegatie aan Oracle, geen parallelle Explore-uitvoeringen, geen Prometheus-interview.

Om orchestration daadwerkelijk te triggeren, moest ik expliciet zijn in de prompt:

ulw onderzoek eerst de codebase,
maak een gedetailleerd plan,
delegeer implementatietaken,
en doe alleen zelf direct werk wanneer delegatie onredelijk is

Zodra ik dat deed, gedroeg het systeem zich zoals geadverteerd. Maar het standaardgedrag zonder dat kader was gewoon OpenCode met een zwaardere contextvenster. Het ultrawork-sleutelwoord alleen is geen garantie voor delegatie — het is een vereiste daarvoor.

Test 1: IndexNow CLI-tool — waar Oh My Opencode-orchestratie oplevert

De taak was het bouwen van een command-line tool die URL’s indient bij de IndexNow-API voor indexering door zoekmachines. Dit is een redelijk omvangrijke meervoudige taak: lees de API-specificatie, ontwerp de CLI, implementeer, test.

Met Oh My Opencode en expliciete orchestratie-prompting was het resultaat merkbare beter dan OpenCode zonder toevoegingen. De finale tool extraherde correct URL’s uit sitemap.xml en stuurde ze in batches, naast het ondersteunen van standaard CLI-opties. De Librarian-agent die de IndexNow-documentatie ophaalde, leverde context die de run met het blote model miste.

oh my opencode indexnow session log

Dit is het soort taak waarvoor OMO gebouwd is: onderzoek + implementatie + enkele ontwerpbeslissingen. De overhead betaalde zich hier terug.

Test 2: Pagina-migratie mapping — hetzelfde resultaat, drie keer zoveel tokens

De tweede test was een documentanalyse-taak: sorteren waar website-pagina’s moeten worden gemigreerd op basis van hun slugs en een migratiebeleidsdocument.

Het resultaat was identiek aan de run met OpenCode zonder toevoegingen — dezelfde nauwkeurigheid, dezelfde structuur, dezelfde beslissingen. Maar de OMO-run verbruikte ongeveer drie keer zoveel tokens.

Dit is een redeneertaak binnen één contextvenster. Er is geen parallelisme te benutten, geen specialistische kennis om op te halen van een subagent. De orchestration-laag voegde overhead toe zonder waarde toe te voegen. Voor dit type taak is OpenCode zonder toevoegingen de betere keuze.

Modelselectie: waarom zwakke modellen worstelen met orchestration-overhead

Het uitvoeren op Big Pickle (een gratis-tier model) bracht iets aan het licht dat de gemeenschap ook heeft opgemerkt: zwakke modellen zijn gevoeliger voor de kwaliteit van het harnas dan sterke modellen. Claude Opus is veerkrachtig genoeg om goede output te produceren, zelfs met een zware orchestration-laag eromheen. Een kleiner model zoals Big Pickle profiteert meer van een schone, gefocuste prompt dan van een complexe multi-agent-opstelling die ruis toevoegt aan de context.

Als u OMO uitvoert op budget-modellen, begin dan simpeler. Gebruik orchestration voor onderzoek-intensieve taken waar Librarian en Explore echt informatie toevoegen. Vermijd het voor pure redeneertaken waar het model alleen duidelijke input en ruimte nodig heeft om na te denken.

Oh My Opencode-gemeenschapsbevindingen: benchmarks, facturering en real-world valkuilen

Voordat u volledig ingaat, is het de moeite waard om te weten wat de gemeenschap heeft gevonden door daadwerkelijk gebruik — zowel de successen als de failure-modi.

Oh My Opencode-benchmark: 69% vs 73% slaagkans, 3× meer requests dan vanilla OpenCode

Een gemeenschapslid voerde een systematische benchmark uit over 120+ agent/model-combinaties en publiceerde de resultaten. Met OMO Ultrawork ingeschakeld was de slaagkans op hun coderingsevaluatie 69,2% — tegenover 73,1% voor gewoon OpenCode zonder OMO. De OMO-run duurde 10 minuten langer (55 vs 45 minuten) en maakte 96 requests in plaats van 27.

Hun conclusie: “het is letterlijk gewoon Opus met meer stappen.” Opus is bijzonder veerkrachtig tegen verschillen in het harnas — het levert sterke resultaten ongeacht wat er omheen zit. Zwakke modellen toonden meer gevoeligheid voor het harnas, maar niet noodzakelijk ten gunste van OMO.

Dit betekent niet dat OMO nutteloos is. Voor grote taken met meerdere bestanden, parallelle achtergrondagents en complexe engineering-workflows betaalt de overhead zich terug. Maar voor coderingstaken die in één contextvenster passen, zal gewoon OpenCode met een goed model vaak even goed zijn of beter dan een volledige orchestration-stack.

Startup-token-overhead: 15.000–25.000 tokens voordat er werk begint

Een terugkerende gemeenschapsklacht is dat OMO bij het opstarten veel tools en MCP’s injecteert. Een simpele “Hello world”-boodschap kan 15.000–25.000 tokens verbruiken alleen al door de contextvenster-instelling voordat er daadwerkelijk werk gebeurt. De maintainer is zich hiervan bewust en werkt aan uitgestelde tool-lading, maar per begin 2026 is het een echte kostenpost om mee te nemen in prijsinschattingen.

De $350 Gemini oneindige lus — en wat u eraan kunt doen

In maart 2026 veroorzaakte een bevestigde bug (issue #2571, gelabeld will-fix) dat een gebruiker in een middag werd gefactureerd voor ongeveer $438. Drie aparte problemen cumuleerden:

  1. Geen circuit breaker: OMO had geen maximum-stappenlimiet per subagent. Een Gemini-model raakte vast in een git diff / read-verificatielus en voerde 809 opeenvolgende beurten uit gedurende 3,5 uur zonder te stoppen.

  2. Stille model-routing: De sessie van de gebruiker was op GPT-5.4. Maar een gedelegeerde Compose UI-taak werd gerouteerd naar Gemini 3.1 Pro via category-routing (visual-engineering) — een model dat de gebruiker nooit intentioneel selecteerde en geen zicht op had totdat hij achteraf door de SQLite-database zocht.

  3. Onjuiste kostenweergave: OpenCode’s prijssnapshot voor gemini-3.1-pro-preview miste de prijsklasse voor >200K context. Google rekent 2× voor contexten boven de 200K tokens, maar OpenCode berekende alles tegen de basisprijs. De weergegeven kosten waren minder dan de helft van de werkelijke Google-rekening.

Een gemeenschapsopmerking samenvatte het: “Gemini draait constant in lussen voor mij, daarom gebruik ik het zelden als niet-read-only model.”

Een fix (PR #2590) is in uitvoering — het toevoegen van een configureerbare maximum-stappenlimiet en lusdetectie. Tot het wordt uitgebracht, bescherm uzelf:

  • Audit uw category-configuratie. Als elke category naar Gemini mapt (inclusief visual-engineering als standaard), gebruikt elke achtergronddaak in die category Gemini — stilzwijgend — zelfs wanneer uw voorgronssessie op een ander model staat.
  • Stel expliciete providerConcurrency-limieten in voor Gemini in background_task. Het houden op 1 beperkt de blast-radius.
  • Controleer uw daadwerkelijke provider-facturatie-dashboards, niet alleen de door OpenCode weergegeven kosten, vooral voor Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // harde limiet totdat de circuit breaker wordt uitgebracht
    }
  }
}

Ultrawork-delegatie vereist het sleutelwoord — het is niet automatisch

Vroege gebruikers ontdekten dat zonder ultrawork de hoofdagent vaak helemaal geen delegatie doet aan specialistische subagents — hij begint gewoon direct read en grep aan te roepen. De maintainer erkende dit vroeg: “het lijkt moeilijk om alleen door systeem-prompt-instructies het juiste agent aan te roepen zonder expliciete prompts.”

Het ultrawork-sleutelwoord is wat betrouwbaar orchestration triggert. Zonder het draait u vaak gewoon OpenCode met een zwaardere contextvenster. Dit komt overeen met wat ik in mijn eigen testen vond.

Lichtere alternatieven voor OMO: OMO Slim en Oh-My-Pi

Als u de achtergrond-executie hooks en belangrijke OMO-verbeteringen wilt zonder de volledige agent-orchestratie-overhead, is oh-my-opencode-slim een gemeenschapsfork die de functieset inkrimpt. Sommige gebruikers zijn ook overgegaan naar oh-my-pi, dat zich richt op achtergronddaak-executie en hooks terwijl het prompt-oppervlak minimaal blijft.

Een gebruiker zette het goed op een rij: “Ik vind OMO leuk vanwege zijn hooks en achtergronddaak-executie. Ik denk dat OMO slim de verkeerde dingen probeert te optimaliseren. De basis OpenCode-prompts plus achtergrondwerkers en hooks die het model automatisch prompten om door te gaan wanneer het besluit te stoppen, zouden voor mij genoeg zijn.”

De juiste keuze hangt af van uw taakprofiel. Grote, meervoudige engineering-werkzaamheden rechtvaardigen volledige OMO. Voor dagelijks kortere taken levert een slanker harnas vaak betere resultaten op met minder kosten.

Wanneer Oh My Opencode echt beter presteert: resultaten van echte gebruikers

Om de valkuilen in evenwicht te brengen, hier is wat gebruikers rapporteren als de duidelijkste overwinningen van OMO:

  • 8.000 ESLint-waarschuwingen in één dag opgehelderd — parallelle Explore-agents die de codebase scannen terwijl werker-agents tegelijkertijd reparaties uitvoeren
  • Tauri-app van 45k regels geconverteerd naar een SaaS web-app in één nacht — Prometheus-interviewmodus produceerde een gedetailleerd plan, Ralph Loop voerde het van begin tot eind uit
  • Full-stack-functies geïmplementeerd van begin tot eind zonder dat de gebruiker aan het toetsenbord raakte na de initiële prompt
  • Architectuurbesprekingen op geërfd codebases — Oracle’s read-only adviserende rol bracht problemen aan het licht zonder onbedoeld veranderingen aan te brengen

De rode draad: taken die profiteren van parallelisme en duidelijke acceptatiecriteria hebben die Prometheus kan verifiëren. Taken waarbij een enkel, gefocust model het goed doet, krijgen weinig voordeel van de orchestration-overhead.

Oh My Opencode vs Vanilla OpenCode: wanneer u elk moet gebruiken

Oh My Opencode is niet universeel beter dan vanilla OpenCode. Het is een vermenigvuldigingsfactor voor een specifieke klasse van werk — en overhead voor alles andere.

Gebruik de volledige OMO-stack (met ultrawork) wanneer:

  • De taak meerdere bestanden en lagen overspant
  • U onderzoek, planning, implementatie en verificatie nodig hebt als afzonderlijke fasen
  • U profiteert van parallelle achtergrondagents (Explore, Librarian) die context verzamelen terwijl werkers draaien
  • De scope groot genoeg is dat u anders de agent zou moeten oppassen door meerdere sequentiële prompts heen

Gebruik vanilla OpenCode (of een slanker harnas) wanneer:

  • De taak in één contextvenster past
  • Het probleem pure redenering is zonder extern onderzoek
  • U budget-modellen uitvoert — ze profiteren meer van een schone, gefocuste prompt dan van orchestration-complexiteit
  • U voorspelbare facturering wilt zonder verrassingen door category-routing

Het facturatiarisico is echt en ondergerapporteerd. Tot de circuit breaker landt, behandel OMO met Gemini alsof het actief toezicht vereist — niet als een “fire and forget”-systeem. Voor alles andere is het systeem werkelijk indrukwekkend als het op het juiste probleem wordt gericht.

Bronnen

Gemeenschapsdiscussies en issues die in dit artikel worden genoemd: