Recenzja Oh My Opencode: szczere wyniki, ryzyka rozliczeniowe i kiedy się to opłaca

Co tak naprawdę dzieje się, gdy uruchamiasz Ultrawork.

Page content

Oh My Opencode obiecuje „wirtualny zespół deweloperski AI" — Sisyphus koordynuje specjalistów, zadania są wykonywane równolegle, a magiczne słowo kluczowe ultrawork uruchamia całą tę machinę.

To obietnica spełnia się dla odpowiedniego obciążenia. Przy niewłaściwym dodaje jedynie koszt i złożoność bez poprawy wyników. Ten artykuł opisuje, co naprawdę wydarzyło się podczas testów praktycznych, oraz co odkryła szersza społeczność po miesiącach rzeczywistego użytkowania.

leniwi agenci pracujący równolegle

Jeśli jesteś nowy w tej technologii,

Ten artykuł zakłada, że już jesteś zaznajomiony z systemem i chcesz wiedzieć, czy on naprawdę działa. Aby uzyskać szerszy obraz tego, jak OMO pasuje do łańcucha narzędzi AI dla programistów, zobacz przegląd narzędzi dla deweloperów AI.

Wydajność Oh My Opencode: wyniki testów praktycznych

Wykonałem te same testy, co dla czystego OpenCode — te same zadania benchmarkowe LLM, które przeprowadziłem przeciwko OpenCode z lokalnymi modelami Ollama i llama.cpp. Tym razem na modelu Big Pickle (GLM 4.6 przez OpenCode Zen — warstwa darmowa).

Krótka wersja: wyniki mieszane, a tryb błędu był pouczający.

Dlaczego Sisyphus pomija delegowanie bez jawnego promptu Ultrawork

Pierwszą rzeczą, z którą się zderzyłem, było to, że Sisyphus nie zachowywał się jak koordynator bez jawnego promptowania. Nawet z prefiksem ulw, zaczął wykonywać całą pracę samodzielnie — czytać pliki bezpośrednio, pisać kod, całkowicie pomijając fazy badań i planowania. Żadnej delegacji do Oracle, żadnych równoległych uruchomień Explore, żadnego wywiadu z Prometheusem.

Aby faktycznie uruchomić koordynację, musiałem być jawnym w promptcie:

ulw najpierw zbadaj kod źródłowy,
stwórz szczegółowy plan,
deleguj zadania implementacyjne,
i wykonaj pracę bezpośrednio tylko wtedy, gdy delegowanie jest niecelowe

Gdy to zrobiłem, system zachował się zgodnie z reklamą. Ale zachowanie domyślne bez tego ramowania było czystym OpenCode z cięższym oknem kontekstu. Samo słowo kluczowe ultrawork nie jest gwarancją delegowania — jest tylko warunkiem koniecznym.

Test 1: Narzędzie CLI IndexNow — gdzie koordynacja Oh My Opencode przynosi korzyści

Zadaniem było zbudowanie narzędzia linii poleceń, które przesyła URL-e do API IndexNow w celu indeksowania w wyszukiwarkach. Jest to zadanie o rozsądnym zakresie, wieloetapowe: przeczytaj specyfikację API, zaprojektuj CLI, zaimplementuj, przetestuj.

Z Oh My Opencode i jawnym promptowaniem koordynacyjnym wynik był zauważalnie lepszy niż przy czystym OpenCode. Końcowe narzędzie poprawnie wyciągało URL-e z sitemap.xml i wysyłało je partiami, dodatkowo obsługując standardowe opcje CLI. Agent Librarian pobierający dokumentację IndexNow dostarczył kontekst, którego brakowało w uruchomieniu z czystym modelem.

log sesji oh my opencode indexnow

To jest rodzaj zadania, dla którego OMO został zbudowany: badania + implementacja + pewne decyzje projektowe. Tutaj nakład się opłacił.

Test 2: Mapowanie migracji stron — ten sam wynik, trzykrotnie więcej tokenów

Drugim testem było zadanie analizy dokumentu: uporządkowanie, które strony strony internetowej powinny zostać zmigrowane na podstawie ich slugów i dokumentu polityki migracji.

Wynik był identyczny z uruchomieniem czystego OpenCode — ta sama dokładność, ta sama struktura, te same decyzje. Ale uruchomienie OMO zużyło około trzykrotnie więcej tokenów.

Jest to zadanie wymagające rozumowania w jednym oknie kontekstowym. Nie ma tu równoległości do wykorzystania, nie ma specjalistycznej wiedzy do pobrania od podagenta. Warstwa koordynacji dodała nakład bez dodania wartości. Dla tego typu zadań czysty OpenCode jest lepszym wyborem.

Wybór modelu: dlaczego słabsze modele mają trudności z nadmiarem koordynacji

Uruchamianie na Big Pickle (model z warstwy darmowej) ujawniło coś, co zauważyła również społeczność: słabsze modele są bardziej wrażliwe na jakość harnasu niż silne modele. Claude Opus jest wystarczająco odporny, aby generować dobre wyniki nawet przy ciężkiej warstwie koordynacji wokół niego. Mniejszy model, taki jak Big Pickle, korzysta bardziej z czystego, skupionego promptu niż ze złożonego setupu wieloagentowego, który dodaje szum do kontekstu.

Jeśli uruchamiasz OMO na modelach budżetowych, zacznij prościej. Używaj koordynacji dla zadań wymagających badań, gdzie Librarian i Explore naprawdę dodają informacji. Unikaj jej dla czystych zadań rozumowania, gdzie model potrzebuje tylko jasnego wejścia i przestrzeni do myślenia.

Odkrycia społeczności Oh My Opencode: benchmarki, rozliczenia i realne zastrzeżenia

Zanim oddasz się temu całkowicie, warto wiedzieć, co społeczność odkryła dzięki rzeczywistemu użytkowaniu — zarówno sukcesy, jak i tryby awarii.

Benchmark Oh My Opencode: 69% vs 73% wskaźnik poprawności, 3× więcej zapytań niż czysty OpenCode

Jeden z członków społeczności przeprowadził systematyczny benchmark na ponad 120 kombinacjach agent/model i opublikował wyniki. Z włączonym OMO Ultrawork, wskaźnik poprawności w ich ocenie kodu wynosił 69.2% — w porównaniu do 73.1% dla czystego OpenCode bez OMO. Uruchomienie OMO trwało 10 minut dłużej (55 vs 45 minut) i wykonało 96 zapytań zamiast 27.

Ich wniosek: “to dosłownie Opus z większą liczbą kroków”. Opus jest szczególnie odporny na różnice w harnasie — dostarcza silnych wyników niezależnie od tego, co jest wokół niego. Słabsze modele wykazały większą wrażliwość na harnas, ale niekoniecznie na korzyść OMO.

To nie oznacza, że OMO jest bezużyteczny. Dla dużych zadań wieloplikowych, równoległych agentów w tle i złożonych procesów inżynieryjnych, nakład się opłaca. Ale dla zadań kodowania, które mieszczą się w jednym oknie kontekstowym, czysty OpenCode z dobrym modelem często dorównuje lub przebija pełną stos koordynacyjny.

Nadmiar tokenów na starcie: 15 000–25 000 tokenów zanim cokolwiek się stanie

Powracającym zarzutem społeczności jest to, że OMO wstrzykuje wiele narzędzi i MCP podczas startu. Prosta wiadomość „Hello world" może zużyć 15 000–25 000 tokenów tylko z konfiguracji okna kontekstu, zanim cokolwiek się stanie. Maintainer jest tego świadomy i pracuje nad opóźnianym ładowaniem narzędzi, ale na wczesnym etapie 2026 roku jest to realny koszt, który należy uwzględnić w szacunkach cenowych.

Pętla bezkończowa Gemini za 350$ — i co z tym zrobić

W marcu 2026 roku potwierdzona błędem (issue #2571, oznaczony jako will-fix) spowodował, że użytkownik został obciążony fakturą ~438$ w ciągu jednego popołudnia. Trzy osobne problemy się nałożyły:

  1. Brak bezpiecznika: OMO nie miał limitu maksymalnej liczby kroków na podagenta. Model Gemini utknął w pętli weryfikacji git diff / read i działał 809 kolejnych tur przez 3,5 godziny bez zatrzymywania.

  2. Cicha routa modelu: Sesja nadrzędna użytkownika była na GPT-5.4. Ale zadanie delegowane Compose UI zostało skierowane do Gemini 3.1 Pro przez routę kategorii (visual-engineering) — model, którego użytkownik nigdy celowo nie wybrał i nie miał do niego widoczności, dopóki nie wykonał kopania w bazie SQLite po fakcie.

  3. Nieprawidłowy wyświetlany koszt: Przejściowy stan cenowy OpenCode dla gemini-3.1-pro-preview brakuje warstwy cenowej dla kontekstu >200K. Google pobiera 2× za konteksty powyżej 200K tokenów, ale OpenCode wszystko obliczał po stawce bazowej. Wyświetlony koszt był mniejszy niż połowa rzeczywistej faktury Google.

Komentarz społeczności podsumował to: “Gemini stale wpada w pętle u mnie, dlatego rzadko używam go jako modelu nie tylko do odczytu.”

Naprawa (PR #2590) jest w toku — dodanie konfigurowalnego limitu maksymalnej liczby kroków i wykrywania pętli. Do czasu jej wydania, chron się:

  • Zrób audyt konfiguracji kategorii. Jeśli jakakolwiek kategoria mapuje się na Gemini (w tym visual-engineering domyślnie), każde zadanie w tle w tej kategorii używa Gemini — cicho — nawet gdy Twoja sesja na pierwszym planie jest na innym modelu.
  • Ustaw jawnie limity providerConcurrency dla Gemini w background_task. Trzymanie go na 1 ogranicza zasięg wybuchu.
  • Sprawdź rzeczywiste pulpity rozliczeniowe dostawcy, nie tylko wyświetlany koszt OpenCode, zwłaszcza dla Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // twardy limit do czasu wdrożenia bezpiecznika
    }
  }
}

Delegacja Ultrawork wymaga słowa kluczowego — nie jest automatyczna

Wczesni użytkownicy odkryli, że bez ultrawork, główny agent często w ogóle nie deleguje do specjalistycznych podagentów — po prostu zaczyna wywoływać read i grep bezpośrednio. Maintainer przyznał to wczesnym etapem: “wydaje się trudne osiągnięcie wywoływania odpowiedniego agenta wyłącznie przez instrukcje systemowe bez jawnych promptów.”

Słowo kluczowe ultrawork to to, co niezawodnie uruchamia koordynację. Bez niego często uruchamiasz czysty OpenCode z cięższym oknem kontekstu. To zgadza się z tym, co znalazłem we własnych testach.

Lżejsze alternatywy dla OMO: OMO Slim i Oh-My-Pi

Jeśli chcesz haków wykonania w tle i kluczowych ulepszeń OMO bez pełnego nakładu koordynacji agentów, oh-my-opencode-slim to fork społecznościowy, który przycina zestaw funkcji. Niektórzy użytkownicy przesunęli się również do oh-my-pi, który skupia się na wykonaniu zadań w tle i hakach, zachowując powierzchnię promptu minimalną.

Jeden użytkownik to ujął trafnie: “Podoba mi się OMO za haki i wykonanie zadań w tle. Myślę, że OMO slim próbuje optymalizować złe rzeczy. Podstawowe prompty OpenCode plus pracownicy w tle i haki, które automatycznie podpowiadają modelowi, aby kontynuował, gdy zdecyduje się zatrzymać, wystarczyłyby mi.”

Prawidłowy wybór zależy od Twojego profilu zadań. Duże, wieloetapowe prace inżynieryjne uzasadniają pełne OMO. Dla codziennych, krótszych zadań, lżejszy harnas często daje lepsze wyniki przy mniejszym koszcie.

Kiedy Oh My Opencode naprawdę przewyższa: wyniki rzeczywistych użytkowników

Aby zrównoważyć zastrzeżenia, oto co użytkownicy zgłaszają jako najjasniejsze zwycięstwa OMO:

  • 8 000 ostrzeżeń ESLint usuniętych w ciągu dnia — równolegli agenci Explore skanujący kod źródłowy, podczas gdy agenci pracownicy wykonują poprawki jednocześnie
  • Aplikacja Tauri o 45k liniach konwertowana na aplikację SaaS w ciągu nocy — tryb wywiadu Prometheus wygenerował szczegółowy plan, Ralph Loop wykonał go od początku do końca
  • Funkcje pełno-stackowe zaimplementowane od początku do końca bez dotykania klawiatury przez użytkownika poza początkowym promptem
  • Recenzje architektury na dziedziczonych kodach źródłowych — rola doradcza tylko do odczytu Oracle wykrywa problemy bez przypadkowego wprowadzania zmian

Wspólnym wątkiem: zadania, które korzystają z równoległości i mają jasne kryteria akceptacji, które Prometheus może zweryfikować. Zadania, w których pojedynczy, skupiony model poradziłby sobie dobrze, zyskują niewiele z nakładu koordynacji.

Oh My Opencode vs Czysty OpenCode: kiedy używać każdego

Oh My Opencode nie jest uniwersalnie lepszy niż czysty OpenCode. To mnożnik mocy dla specyficznej klasy pracy — i nakład dla wszystkiego innego.

Użyj pełnego stosu OMO (z ultrawork), gdy:

  • zadanie obejmuje wiele plików i warstw
  • potrzebujesz badań, planowania, implementacji i weryfikacji jako odrębnych faz
  • korzystasz z równoległych agentów w tle (Explore, Librarian) zbierających kontekst, podczas gdy pracownicy działają
  • zakres jest wystarczająco duży, że inaczej musiałbyś nadzorować agenta przez wiele sekwencyjnych promptów

Użyj czystego OpenCode (lub lżejszego harnasu), gdy:

  • zadanie mieści się w jednym oknie kontekstowym
  • problem jest czystym rozumowaniem bez zewnętrznych badań
  • uruchamiasz modele budżetowe — one korzystają bardziej z czystego, skupionego promptu niż ze złożoności koordynacji
  • chcesz przewidywalne rozliczenia bez zaskoczeń routy kategorii

Ryzyko rozliczeń jest realne i niedostatecznie raportowane. Do czasu wdrożenia bezpiecznika, traktuj OMO z Gemini jako wymagający aktywnego nadzoru — nie jako system „wystrzel i zapomnij". Dla wszystkiego innego, system jest naprawdę imponujący, gdy skierowany na odpowiedni problem.

Źródła

Dyskusje społeczności i problemy odwołane w tym artykule: