Обзор Opencode: честные результаты, риски биллинга и когда это того стоит

Что происходит на самом деле при запуске Ultrawork.

Содержимое страницы

Oh My Opencode обещает «виртуальную команду AI-разработчиков» — Сизиф координирует специалистов, задачи выполняются параллельно, а волшебное ключевое слово ultrawork активирует всё это.

Это обещание оправдывается для правильного типа нагрузки. Для неподходящих задач оно лишь добавляет стоимость и сложность, не улучшая результатов. В этой статье рассматриваются реальные результаты ручного тестирования и то, что обнаружило сообщество после нескольких месяцев практического использования.

ленивые агенты работают параллельно

Если вы только знакомитесь со стеком,

В этой статье предполагается, что вы уже знакомы с системой и хотите узнать, насколько она эффективна на практике. Для общей картины того, как OMO вписывается в цепочку инструментов для AI-разработки, см. обзор инструментов для разработчиков с ИИ.

Производительность Oh My Opencode: результаты ручного тестирования

Я провел те же тесты, что и для чистого OpenCode — те же задачи бенчмарка LLM, которые я выполнял с OpenCode, используя локальные модели Ollama и llama.cpp. На этот раз использовалась модель Big Pickle (GLM 4.6 через OpenCode Zen — бесплатный тариф).

Краткая версия: результаты смешанные, а режим сбоя оказался поучительным.

Почему Сизиф пропускает делегирование без явного промпта Ultrawork

Первой проблемой стало то, что Сизиф не вел себя как оркестратор без явного промпта. Даже с префиксом ulw он начал делать всю работу сам — читал файлы напрямую, писал код, полностью пропуская фазы исследования и планирования. Никакого делегирования Оракулу, никаких параллельных запусков Explore, никаких интервью с Прометеем.

Чтобы реально запустить оркестрацию, мне пришлось быть явным в промпте:

ulw сначала исследуйте кодовую базу,
создайте подробный план,
делегирование задач на реализацию,
и выполняйте работу напрямую только тогда, когда делегирование неразумно

После этого система заработала как заявлено. Но поведение по умолчанию без такой рамки было просто обычным OpenCode с более тяжелым контекстным окном. Ключевое слово ultrawork само по себе не гарантирует делегирование — это лишь предпосылка для него.

Тест 1: CLI-инструмент IndexNow — где оркестрация Oh My Opencode окупается

Задача заключалась в создании командной утилиты для отправки URL в API IndexNow для индексации поисковыми системами. Это задача с разумным охватом и несколькими шагами: прочитать спецификацию API, спроектировать CLI, реализовать, протестировать.

С Oh My Opencode и явным промптом оркестрации результат оказался заметно лучше, чем у чистого OpenCode. Финальный инструмент корректно извлекал URL из sitemap.xml и отправлял их партиями, дополнительно поддерживая стандартные опции CLI. Агент Librarian, получивший документацию IndexNow, предоставил контекст, который пропущен в запуске с базовой моделью.

лог сессии oh my opencode indexnow

Это тот тип задач, для которых создан OMO: исследование + реализация + некоторые решения по проектированию. Здесь окупилась переплата за накладные расходы.

Тест 2: Картирование миграции страниц — тот же результат, тройное количество токенов

Второй тест был задачей анализа документов: определить, куда следует мигрировать страницы сайта, основываясь на их слагах (slugs) и документе политики миграции.

Результат оказался идентичным запуску чистого OpenCode — та же точность, та же структура, те же решения. Но запуск OMO потребовал примерно в три раза больше токенов.

Это задача логического вывода в пределах одного контекстного окна. Здесь нет параллелизма для использования, нет специализированных знаний, которые можно было бы привлечь от подагента. Слой оркестрации добавил накладные расходы без добавления ценности. Для этого класса задач чистый OpenCode — лучший выбор.

Выбор модели: почему более слабые модели хуже справляются с накладными расходами оркестрации

Запуск на Big Pickle (модель бесплатного тарифа) выявил то, что заметило и сообщество: более слабые модели более чувствительны к качеству «обвязки», чем сильные. Claude Opus достаточно устойчив, чтобы выдавать хороший результат даже при наличии тяжелой оркестрационной обвязки. Более маленькая модель, такая как Big Pickle, выигрывает от чистого, сфокусированного промпта больше, чем от сложной мультиагентной настройки, которая добавляет шум в контекст.

Если вы запускаете OMO на бюджетных моделях, начинайте с более простых сценариев. Используйте оркестрацию для задач, требующих исследований, где Librarian и Explore действительно добавляют информацию. Избегайте её для задач чистого логического вывода, где модели просто нужны четкий ввод и пространство для размышлений.

Выводы сообщества Oh My Opencode: бенчмарки, биллинг и реальные подводные камни

Прежде чем делать ставку на OMO, стоит узнать, что обнаружило сообщество в реальной эксплуатации — как успехи, так и режимы сбоев.

Бенчмарк Oh My Opencode: 69% против 73% успешных задач, в 3 раза больше запросов, чем у чистого OpenCode

Один из участников сообщества провел систематический бенчмарк на более чем 120 комбинациях агентов и моделей и опубликовал результаты. С включенным OMO Ultrawork процент успешных задач на их тесте по кодингу составил 69,2% — против 73,1% у обычного OpenCode без OMO. Запуск OMO занял на 10 минут больше (55 против 45 минут) и потребовал 96 запросов вместо 27.

Их вывод: «это буквально просто Opus с дополнительными шагами». Opus особенно устойчив к различиям в обвязке — он выдает сильные результаты независимо от того, что его окружает. Более слабые модели показали большую чувствительность к обвязке, но не обязательно в пользу OMO.

Это не значит, что OMO бесполезен. Для крупных задач с множеством файлов, параллельных фоновых агентов и сложных инженерных рабочих процессов накладные расходы окупаются. Но для задач кодинга, которые помещаются в одно контекстное окно, чистый OpenCode с хорошей моделью часто соответствует или превосходит полную оркестрационную стопку.

Накладные расходы на токены при старте: 15 000–25 000 токенов до начала любой работы

Повторяющаяся жалоба сообщества заключается в том, что OMO загружает множество инструментов и MCP при старте. Простое сообщение «Hello world» может потреблять 15 000–25 000 токенов только на настройку контекстного окна до начала фактической работы. Поддерживающий разработчик знает об этом и работает над отложенной загрузкой инструментов, но по состоянию на начало 2026 года это реальная стоимость, которую нужно учитывать при оценке цен.

Бесконечный цикл Gemini на $350 — и что с этим делать

В марте 2026 года подтвержденный баг (issue #2571, помеченный как will-fix) привел к тому, что пользователю выставили счет примерно на $438 за один полдень. Три отдельные проблемы усугубили ситуацию:

  1. Отсутствие аварийного выключателя: у OMO не было ограничения на максимальное количество шагов для подагента. Модель Gemini застряла в цикле верификации git diff / read и выполняла 809 последовательных ходов в течение 3,5 часов, не останавливаясь.

  2. Бесшумная маршрутизация модели: родительская сессия пользователя была на GPT-5.4. Но делегированная задача Compose UI была направлена на Gemini 3.1 Pro через категориальную маршрутизацию (visual-engineering) — модель, которую пользователь никогда не выбирал намеренно и о которой не знал, пока не копался в базе данных SQLite постфактум.

  3. Некорректное отображение стоимости: моментальный снимок цен OpenCode для gemini-3.1-pro-preview не включал тарифный план >200K context. Google взимает плату в 2 раза выше для контекстов более 200K токенов, но OpenCode рассчитывал всё по базовой ставке. Отображенная стоимость была меньше половины реальной bills Google.

Комментарий из сообщества подытожил ситуацию: «Gemini постоянно заходит в циклы для меня, поэтому я редко использую его как модель, не являющуюся только для чтения».

Исправление (PR #2590) находится в разработке — добавление настраиваемого лимита максимального количества шагов и обнаружения циклов. До его выпуска защитите себя:

  • Проверьте конфигурацию категорий. Если какая-либо категория отображается на Gemini (включая visual-engineering по умолчанию), каждая фоновая задача в этой категории будет использовать Gemini — бесшумно — даже когда ваша фоновая сессия использует другую модель.
  • Установите явные лимиты providerConcurrency для Gemini в background_task. Оставив значение 1, вы ограничите радиус поражения.
  • Проверяйте реальные панели биллинга провайдера, а не только отображаемую стоимость в OpenCode, особенно для Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // жесткий лимит до выхода аварийного выключателя
    }
  }
}

Делегирование Ultrawork требует ключевое слово — оно не автоматическое

Ранние пользователи обнаружили, что без ultrawork основной агент часто вообще не делегирует задачи специализированным подагентам — он просто начинает напрямую вызывать read и grep. Поддерживающий разработчик признал это на раннем этапе: «казалось бы, трудно добиться вызова подходящего агента только через инструкции системного промпта без явных промптов».

Ключевое слово ultrawork — это то, что надежно запускает оркестрацию. Без него вы часто запускаете чистый OpenCode с более тяжелым контекстным окном. Это соответствует тому, что я обнаружил в своих собственных тестах.

Более легкие альтернативы OMO: OMO Slim и Oh-My-Pi

Если вам нужны хуки фоновой выполнения и ключевые улучшения OMO без полной накладной стоимости оркестрации агентов, oh-my-opencode-slim — это форк сообщества, который обрезает набор функций. Некоторые пользователи также перешли на oh-my-pi, который фокусируется на выполнении фоновых задач и хуках, сохраняя поверхность промптов минимальной.

Один пользователь выразился удачно: «Мне нравится OMO за его хуки и выполнение фоновых задач. Я думаю, что OMO slim пытается оптимизировать неверные вещи. Базовые промпты OpenCode плюс фоновые рабочие процессы и хуки, которые автоматически промптят модель продолжать, когда она решит остановиться, было бы достаточно для меня».

Правильный выбор зависит от вашего профиля задач. Крупные многоступенчатые инженерные работы оправдывают полный OMO. Для повседневных коротких задач более легкая обвязка часто дает лучшие результаты при меньших затратах.

Когда Oh My Opencode действительно превосходит: результаты реальных пользователей

Чтобы сбалансировать предупреждения, вот что пользователи сообщают как самые очевидные победы OMO:

  • 8 000 предупреждений ESLint устранено за день — параллельные агенты Explore сканируют кодовую базу, в то время как рабочие агенты одновременно выполняют исправления
  • Приложение Tauri на 45 тысяч строк конвертировано в SaaS веб-приложение за ночь — режим интервью Прометея составил подробный план, Ralph Loop выполнил его от начала до конца
  • Полнофункциональные фичи реализованы от начала до конца без того, чтобы пользователь касался клавиатуры после начального промпта
  • Обзоры архитектуры унаследованных кодовых баз — роль только для чтения Оракула выявляет проблемы, не внося случайных изменений

Общее звено: задачи, которые выигрывают от параллелизма и имеют четкие критерии приемки, которые Прометей может проверить. Задачи, с которыми справится одна сфокусированная модель, получают мало пользы от накладных расходов оркестрации.

Oh My Opencode против чистого OpenCode: когда использовать каждый

Oh My Opencode не универсально лучше чистого OpenCode. Это мультипликатор мощности для определенного класса работ — и накладные расходы для всего остального.

Используйте полный стек OMO (с ultrawork), когда:

  • Задача охватывает несколько файлов и слоев
  • Вам нужны исследование, планирование, реализация и верификация как отдельные фазы
  • Вы выигрываете от параллельных фоновых агентов (Explore, Librarian), собирающих контекст, пока работают рабочие агенты
  • Объем достаточно велик, чтобы вы иначе вели бы агента через несколько последовательных промптов

Используйте чистый OpenCode (или более легкую обвязку), когда:

  • Задача помещается в одно контекстное окно
  • Проблема является чистым логическим выводом без внешнего исследования
  • Вы используете бюджетные модели — они выигрывают от чистого сфокусированного промпта больше, чем от сложности оркестрации
  • Вы хотите предсказуемый биллинг без сюрпризов категориальной маршрутизации

Риск биллинга реален и недооценен. До появления аварийного выключателя относитесь к OMO с Gemini как к системе, требующей активного мониторинга — а не как к системе «стрельнул и забыл». Для всего остального система действительно впечатляет, если направить её на правильную проблему.

Источники

Обсуждения сообщества и проблемы, упомянутые в этой статье:

  • r/opencodeCLI — Oh my opencode vs GSD vs others vs Claude CLI vs Kilo — сравнение пользователями инструментов оркестрации и реальным ощущением OMO по сравнению с альтернативами
  • r/opencodeCLI — I tested Opencode on 9 MCP tools, Firecrawl Skills + CLI and Oh My Opencode — систематический бенчмарк 120+ комбинаций агентов и моделей, включая данные о проценте успешных задач 69,2% против 73,1%
  • GitHub issue #2571 — Subagent burned $350 in 3.5 hours with ZERO safeguard — подробный отчет об инциденте: бесшумная маршрутизация модели, бесконечный цикл Gemini, отображение стоимости, показывающее половину реальной суммы
  • GitHub issue #37 — Share your opinion — тема обратной связи, открытая разработчиком, проблемы делегирования на раннем этапе, сценарии использования сообщества
  • GitHub issue #74 — Memory system opinions — обсуждение накладных расходов токенов, паттерны workflows AGENTS.md, предложения сообщества по системам памяти
  • oh-my-opencode-slim — форк сообщества с обрезанным набором функций для более легких случаев использования
  • oh-my-pi — альтернативная обвязка, фокусирующаяся на фоновом выполнении и хуках с минимальной поверхностью промптов