Oh My Opencode-granskning: Ärliga resultat, faktureringsrisker och när det är värt det

Vad som egentligen händer när du kör Ultrawork.

Sidinnehåll

Oh My Opencode lovar om ett “virtuellt AI-utvecklingsteam” — där Sisyphus dirigerar specialister, uppgifter körs parallellt och magiska nyckelordet ultrawork aktiverar allt.

Detta löfte håller för rätt arbetsbelastning. För felaktig arbetsbelastning lägger det till kostnad och komplexitet utan att förbättra resultaten. Denna artikel täcker vad som faktiskt hände vid praktiska tester, och vad den bredare gemenskapen har upptäckt efter månader av verklig användning.

lazy agents working in parallel

Om du är ny till stacken:

Denna artikel förutsätter att du redan är bekant med systemet och vill veta om det faktiskt presterar. För en bredare bild av hur OMO passar in i AI-kodverktygskedjan, se översikt över AI-utvecklarverktyg.

Oh My Opencode-prestation: Resultat från praktiska tester

Jag körde samma tester som jag använder för ren OpenCode — samma LLM-benchtasks jag körde mot OpenCode med lokala Ollama- och llama.cpp-modeller. Denna gång på Big Pickle-modellen (GLM 4.6 via OpenCode Zen — den fria nivån).

Kort versionen: blandade resultat, och misslyckandemotivet var instruktivt.

Varför Sisyphus hoppar över delegering utan en explicit Ultrawork-prompt

Det första jag stötte på var att Sisyphus inte beter sig som en dirigent utan explicit promptning. Även med ulw-prefixet började han göra allt arbete själv — läsa filer direkt, skriva kod, hoppa över forsknings- och planeringsfaserna helt. Inga delegeringar till Oracle, inga parallella utforskande körningar, inget Prometheus-intervju.

För att faktiskt utlösa dirigering fick jag vara explicit i prompten:

ulw undersök kodbasen först,
skapa en detaljerad plan,
delegera implementeringsuppgifter,
och gör bara direkt arbete själv när delegering är orimlig

När jag gjorde så, beter sig systemet som annonserat. Men standardbeteendet utan denna ram var van OpenCode med ett tyngre kontextfönster. Nyckelordet ultrawork i sig är ingen garanti för delegering — det är en förutsättning för det.

Test 1: IndexNow-kommandotolken — Där Oh My Opencode-dirigering betalar sig

Uppgiften var att bygga ett kommandotolksverktyg som skickar URL:er till IndexNow-API:et för sökmotorindexering. Detta är en rimligt avgränsad flerstegsuppgift: läs API-specifikationen, designa kommandotolken, implementera, testa.

Med Oh My Opencode och explicit promptning för dirigering var resultatet märkbart bättre än ren OpenCode. Det slutgiltiga verktyget extraherade korrekt URL:er från sitemap.xml och skickade dem i batchar, utöver att stödja standardalternativ för kommandotolken. Librarian-agenten som hämtade IndexNow-dokumentationen bidrog med kontext som körningen med ren modell missade.

oh my opencode indexnow session log

Detta är den typen av uppgift OMO är byggd för: forskning + implementering + några designbeslut. Överhuvudkostnaden betalade sig här.

Test 2: Sida-migreringsmappning — Samma resultat, tredubbla token

Det andra testet var en dokumentanalysuppgift: sortera ut var websidor ska migreras baserat på deras slugar och ett migrationspolicydokument.

Resultatet var identiskt med körningen med ren OpenCode — samma noggrannhet, samma struktur, samma beslut. Men OMO-körningen förbrukade ungefär tre gånger fler token.

Detta är en uppgift för resonemang i ett enda kontextfönster. Det finns ingen parallelism att utnyttja, ingen specialistkunskap att hämta från en subagent. Dirigeringsskiktet lade till överhuvudskostnad utan att lägga till värde. För denna klass av uppgift är ren OpenCode det bättre valet.

Modellval: Varför svagare modeller har svårt med dirigeringsoverhead

När man kör på Big Pickle (en modell för gratisnivå) avslöjades något som gemenskapen också har noterat: svagare modeller är mer känsliga för kvaliteten på harnesk än starka modeller. Claude Opus är tillräckligt resilient för att producera bra output även med ett tungt dirigeringsskikt kring sig. En mindre modell som Big Pickle gynnas mer av en ren, fokuserad prompt än av en komplex multi-agent-uppsättning som lägger till brus till kontexten.

Om du kör OMO på budgetmodeller, börja enklare. Använd dirigering för forskningsintensiva uppgifter där Librarian och Explore verkligen lägger till information. Undvik det för rena resonemangsuppgifter där modellen bara behöver tydlig input och utrymme att tänka.

Oh My Opencode gemenskapsfynd: Benchmarks, fakturering och verkliga varningar

Innan man går all-in, är det värt att veta vad gemenskapen har upptäckt genom faktisk användning — både vinsterna och misslyckandemotiven.

Oh My Opencode benchmark: 69 % mot 73 % passningsgrad, 3× fler förfrågan än van OpenCode

En communitymedlem körde en systematisk benchmark över 120+ agent/modell-kombinationer och publicerade resultaten. Med OMO Ultrawork aktiverat var passningsgraden på deras kodningseval 69,2 % — mot 73,1 % för ren OpenCode utan OMO. OMO-körningen tog 10 minuter längre (55 mot 45 minuter) och gjorde 96 förfrågan istället för 27.

Deras slutsats: “det är bokstavligen bara Opus med fler steg.” Opus är särskilt resilient mot harnesk-skillnader — det levererar starka resultat oavsett vad som är runt det. Svagare modeller visade mer känslighet för harnesken, men inte nödvändigtvis till OMOs fördel.

Detta betyder inte att OMO är användslös. För stora flerfiluppgifter, parallella bakgrundsgenter och komplexa ingeniörsmässiga arbetsflöden, betalar överhuvudskostnaden sig. Men för koduppgifter som passar i ett enda kontextfönster, kommer ren OpenCode med en bra modell ofta att matcha eller slå en fullständig dirigeringstack.

Start-up token-överhuvud: 15 000–25 000 token innan något arbete påbörjas

En återkommande klagomål från gemenskapen är att OMO injicerar många verktyg och MCP:er vid start. Ett enkelt “Hej världen”-meddelande kan förbruka 15 000–25 000 token bara från kontextfönsterinställningen innan något faktiskt arbete händer. Underhållaren är medveten om detta och arbetar med senareladdning av verktyg, men per början av 2026 är det en verklig kostnad att faktorisera in i prisskattningar.

Den $350 Gemini oändliga loopen — och vad man ska göra åt det

I mars 2026 orsakade ett bekräftat bugg (fråga #2571, märkt will-fix) att en användare fakturerades ~$438 på en enda eftermiddag. Tre separata problem sammanflöt:

  1. Ingen circuit breaker: OMO hade ingen maxstegsgräns per subagent. En Gemini-modell fastnade i en git diff / read-verifieringsloop och körde 809 konsekutiva varv under 3,5 timmar utan att stanna.

  2. Tyst modellroutning: Användarens föräldrasession var på GPT-5.4. Men en delegerad Compose UI-uppgift ruttades till Gemini 3.1 Pro via kategoriroutning (visual-engineering) — en modell användaren aldrig medvetet valde och inte hade syn på förrän efteråt grävde i SQLite-databasen.

  3. Felaktig kostnadsvisning: OpenCode:s prissättningssnapshot för gemini-3.1-pro-preview saknade prissättningsnivån för >200K kontext. Google tar 2× för kontexter över 200K token, men OpenCode beräknade allt till baspriset. Den visade kostnaden var mindre än hälften av den faktiska Google-fakturan.

En kommentar från gemenskapen sammanfattade det: “Gemini snurrar ständigt i looper för mig, därför använder jag sällan den som en icke-läsbar-modell.”

En fix (PR #2590) är under arbete — lägger till en konfigurerbar maxstegsgräns och loopdetektering. Tills den levereras, skydda dig själv:

  • Granska din konfiguration för kategorier. Om någon kategori mappar till Gemini (inklusive visual-engineering som standard), använder varje bakgrundsuppgift i den kategorin Gemini — tyst — även när din framgrundssession är på en annan modell.
  • Sätt explicita providerConcurrency-gränser för Gemini i background_task. Att hålla det på 1 begränsar spridningsradien.
  • Kontrollera dina faktiska leverantörsfaktureringsskyltar, inte bara OpenCode:s visade kostnad, särskilt för Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // hård gräns tills circuit breaker levereras
    }
  }
}

Ultrawork-delegering kräver nyckelordet — det är inte automatiskt

Tidiga användare upptäckte att utan ultrawork, gör huvudagenten ofta inte delegering till specialistsubagenter alls — den börjar bara anropa read och grep direkt. Underhållaren erkände detta tidigt: “det verkar svårt att uppnå anrop av lämplig agent enbart genom systempromptinstruktioner utan explicita promptar.”

Nyckelordet ultrawork är vad som tillförlitligt utlöser dirigering. Utan det kör du ofta ren OpenCode med ett tyngre kontextfönster. Detta matchar vad jag hittade i mina egna tester.

Lättare alternativ till OMO: OMO Slim och Oh-My-Pi

Om du vill ha bakgrundsexekveringskrokarna och nyckel förbättringar från OMO utan den fulla agentdirigeringsöverhuvudskostnaden, är oh-my-opencode-slim ett community-fork som klipper av funktionsmängden. Vissa användare har också bytt till oh-my-pi, som fokuserar på bakgrundsuppgiftsexekvering och krokar medan det håller prompt-ytan minimal.

En användare uttryckte det väl: “Jag gillar OMO för dess krokar och bakgrundsuppgiftsexekvering. Jag tror OMO slim försöker optimera fel saker. De grundläggande OpenCode-promptarna plus bakgrundsgenter och krokar som auto-promptar modellen att fortsätta när den bestämmer att stanna skulle vara tillräckligt för mig.”

Rätt val beror på din uppgiftsprofil. Stora, flerstegsingenjörsarbete motiverar full OMO. För dagliga kortare uppgifter producerar ett lättare harnesk ofta bättre resultat med lägre kostnad.

När Oh My Opencode genuint överpresterar: Verkliga användarresultat

För att balansera varningarna, här är vad användare rapporterar som OMO:s tydligaste vinster:

  • 8 000 ESLint-varningar rensade på en dag — parallella Explore-agenter skannar kodbasen medan arbetareagenter utför fixar samtidigt
  • 45k-raders Tauri-app konverterad till en SaaS-webbapp under natten — Prometheus-intervjumodern producerade en detaljerad plan, Ralph Loop utförde den från start till slut
  • Fullstack-funktioner implementerade från start till slut utan att användaren rörde tangentbordet bortom den initiala prompten
  • Arkitekturgranskningar på ärftliga kodbaser — Oracles roll som endast-läsbar rådgivare framkallar problem utan att råka göra ändringar

Det gemensamma tråden: uppgifter som gynnas av parallelism och har tydliga acceptanskriterier som Prometheus kan verifiera. Uppgifter där en enda fokuserad modell skulle klara sig bra får lite nytta av dirigeringsoverheaden.

Oh My Opencode jämfört med Vanilja OpenCode: När man ska använda varje

Oh My Opencode är inte universellt bättre än vanilja OpenCode. Det är en multiplikator för en specifik klass av arbete — och en överhuvudskostnad för allt annat.

Använd hela OMO-stacken (med ultrawork) när:

  • Uppgiften sträcker sig över flera filer och lager
  • Du behöver forskning, planering, implementering och verifiering som distinkta faser
  • Du gynnas av parallella bakgrundsgenter (Explore, Librarian) som samlar kontext medan arbetare kör
  • Omfånget är stort nog att du annars skulle passa agenten genom flera sekventiella promptar

Använd vanilja OpenCode (eller ett lättare harnesk) när:

  • Uppgiften passar i ett enda kontextfönster
  • Problemet är rent resonemang utan extern forskning
  • Du kör budgetmodeller — de gynnas mer av en ren fokuserad prompt än av dirigeringkomplexitet
  • Du vill ha förutsägbar fakturering utan överraskningar från kategoriroutning

Faktureringrisken är verklig och underanmäld. Tills circuit breaker levereras, behandla OMO med Gemini som att kräva aktiv övervakning — inte som ett “skjut och glöm”-system. För allt annat är systemet genuint imponerande när det pekas mot rätt problem.

Källor

Communitydiskussioner och frågor som refereras i denna artikel: