Op My Opencode Review: Resultados honestos, riesgos de facturación y cuándo vale la pena.

¿Qué sucede realmente cuando ejecutas Ultrawork?

Índice

Oh My Opencode promete un “equipo de desarrollo de IA virtual”: Sisyphus orquestando especialistas, tareas ejecutándose en paralelo y la palabra mágica ultrawork activando todo ello.

Esa promesa se cumple para la carga de trabajo adecuada. Para la incorrecta, añade costes y complejidad sin mejorar los resultados. Este artículo cubre qué sucedió realmente en pruebas prácticas y qué ha descubierto la comunidad más amplia tras meses de uso real.

agentes perezosos trabajando en paralelo

Si eres nuevo en el entorno,

Este artículo asume que ya estás familiarizado con el sistema y quieres saber si realmente funciona. Para una visión más amplia de cómo OMO encaja en la cadena de herramientas de codificación de IA, consulta la visión general de herramientas para desarrolladores de IA.

Rendimiento de Oh My Opencode: Resultados de pruebas prácticas

Ejecuté las mismas pruebas que uso para OpenCode en su estado base: las mismas tareas de referencia de LLM que ejecuté contra OpenCode con modelos locales de Ollama y llama.cpp. Esta vez en el modelo Big Pickle (GLM 4.6 a través de OpenCode Zen — la capa gratuita).

La versión corta: resultados mixtos, y el modo de fallo fue instructivo.

Por qué Sisyphus omite la delegación sin un prompt explícito de Ultrawork

Lo primero que encontré fue que Sisyphus no se comportaba como un orquestador sin un prompting explícito. Incluso con el prefijo ulw, comenzó a hacer todo el trabajo él mismo: leyendo archivos directamente, escribiendo código, omitiendo por completo las fases de investigación y planificación. Sin delegación a Oracle, sin ejecuciones paralelas de Explore, sin entrevistas de Prometheus.

Para activar realmente la orquestación, tuve que ser explícito en el prompt:

ulw investiga la base de código primero,
crea un plan detallado,
delega las tareas de implementación,
y realiza trabajo directo solo cuando la delegación no sea razonable

Una vez que hice eso, el sistema se comportó como se anunciaba. Pero el comportamiento predeterminado sin ese encuadre era OpenCode estándar con una ventana de contexto más pesada. La palabra clave ultrawork por sí sola no garantiza la delegación; es un requisito previo para ella.

Prueba 1: Herramienta CLI IndexNow — donde la orquestación de Oh My Opencode rinde frutos

La tarea consistía en construir una herramienta de línea de comandos que enviara URLs a la API IndexNow para la indexación de motores de búsqueda. Esta es una tarea multi-paso con un alcance razonable: leer la especificación de la API, diseñar la CLI, implementar y probar.

Con Oh My Opencode y un prompting explícito de orquestación, el resultado fue notablemente mejor que con OpenCode en su estado base. La herramienta final extraía correctamente las URLs de sitemap.xml y las enviaba en lotes, además de soportar opciones estándar de la CLI. El agente Librarian, al recuperar la documentación de IndexNow, aportó contexto que la ejecución del modelo base pasó por alto.

registro de sesión de Oh My Opencode IndexNow

Este es el tipo de tarea para la que está diseñado OMO: investigación + implementación + algunas decisiones de diseño. El sobrecosto valió la pena aquí.

Prueba 2: Mapeo de migración de páginas — mismo resultado, triple los tokens

La segunda prueba fue una tarea de análisis de documentos: determinar dónde deberían migrarse las páginas del sitio web basándose en sus “slugs” (identificadores de URL) y un documento de política de migración.

El resultado fue idéntico a la ejecución de OpenCode en su estado base: misma precisión, misma estructura, mismas decisiones. Pero la ejecución de OMO consumió aproximadamente tres veces más tokens.

Esta es una tarea de razonamiento de una sola ventana de contexto. No hay paralelismo que explotar, ni conocimiento especializado que extraer de un subagente. La capa de orquestación añadió sobrecarga sin añadir valor. Para este tipo de tareas, OpenCode estándar es la mejor opción.

Selección de modelos: por qué los modelos más débiles luchan con la sobrecarga de orquestación

Ejecutar en Big Pickle (un modelo de capa gratuita) reveló algo que la comunidad también ha notado: los modelos más débiles son más sensibles a la calidad del “arnés” (framework de soporte) que los modelos fuertes. Claude Opus es lo suficientemente resiliente como para producir buenos resultados incluso con una capa pesada de orquestación a su alrededor. Un modelo más pequeño como Big Pickle se beneficia más de un prompt limpio y enfocado que de una configuración multi-agente compleja que añade ruido al contexto.

Si ejecutas OMO en modelos de bajo presupuesto, comienza más simple. Usa la orquestación para tareas intensivas en investigación donde Librarian y Explore aporten información genuinamente. Evítalo para tareas de razonamiento puro donde el modelo solo necesita una entrada clara y espacio para pensar.

Hallazgos de la comunidad de Oh My Opencode: Benchmarks, facturación y advertencias del mundo real

Antes de comprometerte totalmente, vale la pena saber qué ha encontrado la comunidad a través del uso real, tanto los éxitos como los modos de fallo.

Benchmark de Oh My Opencode: 69% vs 73% de tasa de aprobación, 3× más solicitudes que OpenCode estándar

Un miembro de la comunidad ejecutó un benchmark sistemático en más de 120 combinaciones de agente/modelo y publicó los resultados. Con OMO Ultrawork habilitado, la tasa de aprobación en su evaluación de codificación fue del 69.2% — frente al 73.1% para OpenCode plano sin OMO. La ejecución de OMO tardó 10 minutos más (55 vs 45 minutos) e hizo 96 solicitudes en lugar de 27.

Su conclusión: “literalmente es solo Opus con más pasos”. Opus es particularmente resiliente a las diferencias del arnés; ofrece resultados sólidos independientemente de lo que lo rodee. Los modelos más débiles mostraron más sensibilidad al arnés, pero no necesariamente a favor de OMO.

Esto no significa que OMO sea inútil. Para tareas grandes de múltiples archivos, agentes de fondo en paralelo y flujos de trabajo de ingeniería complejos, la sobrecarga vale la pena. Pero para tareas de codificación que caben en una sola ventana de contexto, OpenCode estándar con un buen modelo a menudo igualará o superará a una pila completa de orquestación.

Sobrecarga de tokens de inicio: 15,000–25,000 tokens antes de que comience cualquier trabajo

Una queja recurrente de la comunidad es que OMO inyecta muchas herramientas y MCPs (Model Context Protocol) al inicio. Un simple mensaje de “Hola mundo” puede consumir 15,000–25,000 tokens solo por la configuración de la ventana de contexto antes de que ocurra cualquier trabajo real. El mantenedor es consciente de esto y está trabajando en la carga diferida de herramientas, pero a principios de 2026 es un coste real que hay que tener en cuenta en las estimaciones de precios.

El bucle infinito de Gemini de $350 — y qué hacer al respecto

En marzo de 2026, un bug confirmado (incidencia #2571, etiquetada como will-fix) causó que a un usuario le facturaran ~$438 en una sola tarde. Tres problemas distintos se sumaron:

  1. Sin interruptor de circuito: OMO no tenía un límite máximo de pasos por subagente. Un modelo de Gemini se quedó atascado en un bucle de verificación git diff / read y ejecutó 809 turnos consecutivos durante 3.5 horas sin detenerse.

  2. Enrutamiento de modelo silencioso: La sesión principal del usuario estaba en GPT-5.4. Pero una tarea de Compose UI delegada se enrutaró a Gemini 3.1 Pro a través del enrutamiento por categoría (visual-engineering), un modelo que el usuario nunca seleccionó intencionalmente y del que no tuvo visibilidad hasta investigar en la base de datos SQLite después del hecho.

  3. Visualización de costes incorrecta: La instantánea de precios de OpenCode para gemini-3.1-pro-preview carecía del tramo de precios >200K context. Google cobra el doble para contextos superiores a 200K tokens, pero OpenCode calculó todo a la tasa base. El coste mostrado fue menos de la mitad de la factura real de Google.

Un comentario de la comunidad lo resume: “Gemini constantemente entra en bucles para mí, por lo que rara vez lo uso como modelo que no sea de solo lectura”.

Una corrección (PR #2590) está en progreso — añadiendo un límite de pasos máximo configurable y detección de bucles. Hasta que se lance, protégete:

  • Audita tu configuración de categorías. Si alguna categoría se mapea a Gemini (incluyendo visual-engineering por defecto), cada tarea de fondo en esa categoría usará Gemini — silenciosamente — incluso cuando tu sesión principal esté en un modelo diferente.
  • Establece límites explícitos de providerConcurrency para Gemini en background_task. Mantenerlo en 1 limita el radio de explosión.
  • Verifica tus paneles de facturación reales del proveedor, no solo el coste mostrado por OpenCode, especialmente para Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // límite estricto hasta que se lance el interruptor de circuito
    }
  }
}

La delegación de Ultrawork requiere la palabra clave — no es automática

Los usuarios tempranos descubrieron que sin ultrawork, el agente principal a menudo no delega a subagentes especializados en absoluto; simplemente comienza a llamar directamente a read y grep. El mantenedor reconoció esto temprano: “parece difícil lograr la llamada al agente apropiado únicamente a través de instrucciones del prompt del sistema sin prompts explícitos”.

La palabra clave ultrawork es lo que activa de forma fiable la orquestación. Sin ella, a menudo estás ejecutando OpenCode estándar con una ventana de contexto más pesada. Esto coincide con lo que encontré en mis propias pruebas.

Alternativas más ligeras a OMO: OMO Slim y Oh-My-Pi

Si quieres los ganchos de ejecución de fondo y las mejoras clave de OMO sin la sobrecarga completa de orquestación de agentes, oh-my-opencode-slim es una bifurcación de la comunidad que recorta el conjunto de funciones. Algunos usuarios también se han mudado a oh-my-pi, que se centra en la ejecución de tareas de fondo y ganchos manteniendo la superficie del prompt mínima.

Un usuario lo expresó bien: “Me gusta OMO por sus ganchos y ejecución de tareas de fondo. Creo que OMO slim está intentando optimizar las cosas equivocadas. Los prompts base de OpenCode más trabajadores de fondo y ganchos que auto-promptean al modelo para continuar cuando decide detenerse serían suficientes para mí”.

La elección correcta depende de tu perfil de tareas. El trabajo de ingeniería grande y multi-paso justifica OMO completo. Para tareas diarias más cortas, un arnés más ligero a menudo produce mejores resultados con menos coste.

Cuando Oh My Opencode supera genuinamente: resultados de usuarios reales

Para equilibrar las advertencias, aquí está lo que los usuarios reportan como las victorias más claras de OMO:

  • 8,000 advertencias de ESLint eliminadas en un día — agentes Explore paralelos escaneando la base de código mientras los agentes trabajadores ejecutan las correcciones simultáneamente
  • Aplicación Tauri de 45k líneas convertida a una app web SaaS durante la noche — el modo de entrevista de Prometheus produjo un plan detallado, y Ralph Loop lo ejecutó de principio a fin
  • Características full-stack implementadas de extremo a extremo sin que el usuario tocase el teclado más allá del prompt inicial
  • Revisiones de arquitectura en bases de código heredadas — el rol de asesor de solo lectura de Oracle hace aflorar problemas sin hacer cambios accidentalmente

El hilo conductor: tareas que se benefician del paralelismo y tienen criterios de aceptación claros que Prometheus puede verificar. Las tareas donde un modelo único y enfocado bastaría obtienen poco beneficio de la sobrecarga de orquestación.

Oh My Opencode vs OpenCode estándar: cuándo usar cada uno

Oh My Opencode no es universalmente mejor que OpenCode estándar. Es un multiplicador de fuerza para una clase específica de trabajo — y una sobrecarga para todo lo demás.

Usa la pila completa de OMO (con ultrawork) cuando:

  • La tarea abarca múltiples archivos y capas
  • Necesitas investigación, planificación, implementación y verificación como fases distintas
  • Te beneficias de agentes de fondo paralelos (Explore, Librarian) recopilando contexto mientras los trabajadores ejecutan
  • El alcance es lo suficientemente grande que de otro modo tendrías que vigilar al agente a través de múltiples prompts secuenciales

Usa OpenCode estándar (o un arnés más ligero) cuando:

  • La tarea cabe en una sola ventana de contexto
  • El problema es de razonamiento puro sin investigación externa
  • Estás ejecutando modelos de bajo presupuesto — se benefician más de un prompt limpio y enfocado que de la complejidad de orquestación
  • Quieres una facturación predecible sin sorpresas de enrutamiento por categorías

El riesgo de facturación es real y subreportado. Hasta que se implemente el interruptor de circuito, trata a OMO con Gemini como algo que requiere monitoreo activo, no como un sistema “dispara y olvida”. Para todo lo demás, el sistema es genuinamente impresionante cuando se apunta al problema correcto.

Fuentes

Discusiones e incidencias de la comunidad referenciadas en este artículo: