Resenha do Opencode: Resultados Honestos, Riscos de Cobrança e Quando Vale a Pena

O que realmente acontece quando você executa o Ultrawork.

Conteúdo da página

Oh My Opencode promete uma “equipe de desenvolvimento virtual com IA” — Sisyphus orquestrando especialistas, tarefas rodando em paralelo e a mágica palavra-chave ultrawork ativando tudo isso.

Essa promessa se sustenta para a carga de trabalho certa. Para a errada, ela adiciona custo e complexidade sem melhorar os resultados. Este artigo cobre o que realmente aconteceu em testes práticos e o que a comunidade mais ampla descobriu após meses de uso real.

agentes preguiçosos trabalhando em paralelo

Se você é novo na pilha tecnológica,

Este artigo pressupõe que você já está familiarizado com o sistema e quer saber se ele realmente performa. Para uma visão mais ampla de como o OMO se encaixa na cadeia de ferramentas de codificação com IA, veja a visão geral das ferramentas de desenvolvimento de IA.

Desempenho do Oh My Opencode: Resultados de Testes Práticos

Executei os mesmos testes que uso para o OpenCode puro — as mesmas tarefas de benchmark de LLM que executei contra o OpenCode com modelos locais Ollama e llama.cpp. Desta vez, no modelo Big Pickle (GLM 4.6 via OpenCode Zen — a camada gratuita).

A versão curta: resultados mistos, e o modo de falha foi instrutivo.

Por que Sisyphus Ignora a Delegação Sem um Prompt Explícito de Ultrawork

O primeiro problema que encontrei foi que Sisyphus não se comportava como um orquestrador sem um prompt explícito. Mesmo com o prefixo ulw, ele começou a fazer todo o trabalho sozinho — lendo arquivos diretamente, escrevendo código, pulando inteiramente as fases de pesquisa e planejamento. Nenhuma delegação para Oracle, nenhuma execução paralela de Explore, nenhuma entrevista com Prometheus.

Para realmente acionar a orquestração, tive que ser explícito no prompt:

ulw pesquise a base de código primeiro,
crie um plano detalhado,
delegue tarefas de implementação
e faça trabalho direto apenas quando a delegação não for razoável

Depois que fiz isso, o sistema se comportou conforme anunciado. Mas o comportamento padrão sem esse enquadramento era o OpenCode puro com uma janela de contexto mais pesada. A palavra-chave ultrawork sozinha não é uma garantia de delegação — é um pré-requisito para ela.

Teste 1: Ferramenta CLI IndexNow — Onde a Orquestração do Oh My Opencode Vale a Pena

A tarefa era construir uma ferramenta de linha de comando que enviasse URLs para a API IndexNow para indexação de motores de busca. Esta é uma tarefa multietapa com escopo razoável: ler a especificação da API, projetar a CLI, implementar e testar.

Com Oh My Opencode e prompt explícito de orquestração, o resultado foi notavelmente melhor que o OpenCode puro. A ferramenta final extraiu corretamente as URLs do sitemap.xml e as enviou em lotes, além de suportar opções de CLI padrão. O agente Librarian, ao buscar a documentação do IndexNow, contribuiu com contexto que a execução do modelo puro perdeu.

log de sessão do oh my opencode indexnow

Este é o tipo de tarefa para a qual o OMO foi construído: pesquisa + implementação + algumas decisões de design. O custo operacional valeu a pena aqui.

Teste 2: Mapeamento de Migração de Páginas — Mesmo Resultado, Triplo de Tokens

O segundo teste foi uma tarefa de análise de documentos: organizar onde as páginas do site deveriam ser migradas com base em seus slugs e um documento de política de migração.

O resultado foi idêntico à execução do OpenCode puro — mesma precisão, mesma estrutura, mesmas decisões. Mas a execução do OMO consumiu aproximadamente três vezes mais tokens.

Esta é uma tarefa de raciocínio de janela de contexto única. Não há paralelismo para explorar, nem conhecimento especializado para obter de um subagente. A camada de orquestração adicionou sobrecarga sem adicionar valor. Para esta classe de tarefa, o OpenCode puro é a melhor escolha.

Seleção de Modelo: Por que Modelos Mais Fracos Lutam com a Sobrecarga de Orquestração

Executar no Big Pickle (um modelo de camada gratuita) expôs algo que a comunidade também notou: modelos mais fracos são mais sensíveis à qualidade do suporte (harness) do que modelos fortes. Claude Opus é resiliente o suficiente para produzir boa saída mesmo com uma camada pesada de orquestração ao redor dele. Um modelo menor como Big Pickle se beneficia mais de um prompt limpo e focado do que de uma configuração complexa de múltiplos agentes que adiciona ruído ao contexto.

Se você estiver executando OMO em modelos de orçamento, comece mais simples. Use orquestração para tarefas pesadas de pesquisa onde Librarian e Explore realmente adicionam informações. Evite para tarefas puras de raciocínio onde o modelo apenas precisa de entrada clara e espaço para pensar.

Descobertas da Comunidade do Oh My Opencode: Benchmarks, Faturamento e Advertências do Mundo Real

Antes de se comprometer totalmente, vale a pena saber o que a comunidade descobriu através do uso real — tanto as vitórias quanto os modos de falha.

Benchmark do Oh My Opencode: 69% vs 73% de Taxa de Aprovação, 3× Mais Requisições que OpenCode Puro

Um membro da comunidade executou um benchmark sistemático em 120+ combinações de agente/modelo e publicou os resultados. Com OMO Ultrawork ativado, a taxa de aprovação em sua avaliação de codificação foi 69,2% — contra 73,1% para o OpenCode puro sem OMO. A execução do OMO levou 10 minutos a mais (55 vs 45 minutos) e fez 96 requisições em vez de 27.

Sua conclusão: “é literalmente apenas o Opus com mais etapas”. Opus é particularmente resiliente a diferenças de suporte — ele entrega resultados fortes independentemente do que está ao redor. Modelos mais fracos mostraram mais sensibilidade ao suporte, mas não necessariamente a favor do OMO.

Isso não significa que o OMO seja inútil. Para tarefas grandes de múltiplos arquivos, agentes de fundo paralelos e fluxos de trabalho de engenharia complexos, a sobrecarga vale a pena. Mas para tarefas de codificação que cabem em uma única janela de contexto, o OpenCode puro com um bom modelo frequentemente iguala ou supera uma pilha completa de orquestração.

Sobrecarga de Tokens de Inicialização: 15.000–25.000 Tokens Antes que Qualquer Trabalho Comece

Uma reclamação recorrente da comunidade é que o OMO injeta muitas ferramentas e MCPs na inicialização. Uma mensagem simples de “Hello world” pode consumir 15.000–25.000 tokens apenas com a configuração da janela de contexto antes que qualquer trabalho real aconteça. O mantenedor está ciente disso e trabalhando no carregamento de ferramentas diferido, mas até o início de 2026, é um custo real a ser considerado nas estimativas de preços.

O Loop Infinito de $350 do Gemini — e o que fazer a respeito

Em março de 2026, um bug confirmado (questão #2571, rotulada will-fix) causou um faturamento de ~$438 para um usuário em uma única tarde. Três problemas separados se somaram:

  1. Sem disjuntor (circuit breaker): O OMO não tinha limite máximo de etapas por subagente. Um modelo Gemini ficou preso em um loop de verificação git diff / read e rodou 809 turnos consecutivos em 3,5 horas sem parar.

  2. Roteamento de modelo silencioso: A sessão pai do usuário estava no GPT-5.4. Mas uma tarefa de UI Compose delegada foi roteada para o Gemini 3.1 Pro via roteamento por categoria (visual-engineering) — um modelo que o usuário nunca selecionou intencionalmente e não tinha visibilidade até investigar o banco de dados SQLite depois do fato.

  3. Exibição de custo incorreta: O instantâneo de preços do OpenCode para gemini-3.1-pro-preview estava faltando a faixa de preços >200K context. O Google cobra 2× para contextos acima de 200K tokens, mas o OpenCode calculou tudo na taxa base. O custo exibido foi menos da metade da fatura real do Google.

Um comentário da comunidade resumiu: “O Gemini constantemente entra em loops para mim, por isso raramente o uso como modelo não-apenas-leitura.”

Uma correção (PR #2590) está em andamento — adicionando um limite de etapas máximas configurável e detecção de loops. Até que seja lançado, proteja-se:

  • Audit sua configuração de categoria. Se qualquer categoria mapear para Gemini (incluindo visual-engineering por padrão), cada tarefa de fundo nessa categoria usa Gemini — silenciosamente — mesmo quando sua sessão em primeiro plano estiver em um modelo diferente.
  • Defina limites explícitos de providerConcurrency para Gemini em background_task. Manter em 1 limita o raio de explosão.
  • Verifique seus painéis de faturamento do provedor real, não apenas o custo exibido pelo OpenCode, especialmente para Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // limite rígido até que o disjuntor seja lançado
    }
  }
}

Delegação Ultrawork Requer a Palavra-chave — Não é Automática

Usuários iniciais descobriram que sem ultrawork, o agente principal frequentemente não delega para subagentes especializados de todo — ele apenas começa a chamar read e grep diretamente. O mantenedor reconheceu isso cedo: “parece difícil chamar o agente apropriado apenas através de instruções de prompt de sistema sem prompts explícitos.”

A palavra-chave ultrawork é o que aciona a orquestração de forma confiável. Sem ela, você frequentemente está executando OpenCode puro com uma janela de contexto mais pesada. Isso combina com o que encontrei em meus próprios testes.

Alternativas Mais Leves ao OMO: OMO Slim e Oh-My-Pi

Se você quer os ganchos de execução de fundo e as melhorias-chave do OMO sem a sobrecarga completa de orquestração de agentes, oh-my-opencode-slim é um fork da comunidade que reduz o conjunto de recursos. Alguns usuários também migraram para oh-my-pi, que se concentra na execução de tarefas de fundo e ganchos mantendo a superfície de prompt mínima.

Um usuário disse bem: “Eu gosto do OMO por seus ganchos e execução de tarefas de fundo. Acho que o OMO slim está tentando otimizar as coisas erradas. Os prompts base do OpenCode mais trabalhadores de fundo e ganchos que auto-promptam o modelo para continuar quando ele decidir parar seriam suficientes para mim.”

A escolha certa depende do seu perfil de tarefa. Trabalhos de engenharia grandes e multi-etapas justificam o OMO completo. Para tarefas diárias mais curtas, um suporte mais esguio frequentemente produz melhores resultados com menos custo.

Quando Oh My Opencode Supera Genuinamente: Resultados Reais de Usuários

Para equilibrar as advertências, aqui está o que os usuários relatam como as vitórias mais claras do OMO:

  • 8.000 avisos do ESLint limpos em um dia — agentes Explore paralelos varrendo a base de código enquanto agentes de trabalho executam correções simultaneamente
  • App Tauri de 45k linhas convertido para um app web SaaS durante a noite — modo de entrevista do Prometheus produziu um plano detalhado, Ralph Loop o executou do início ao fim
  • Recursos full-stack implementados de ponta a ponta sem o usuário tocar no teclado além do prompt inicial
  • Revisões de arquitetura em bases de código herdadas — o papel consultivo de apenas leitura do Oracle revela problemas sem fazer mudanças acidentais

O fio condutor: tarefas que se beneficiam do paralelismo e têm critérios de aceitação claros que o Prometheus pode verificar. Tarefas onde um modelo único focado faria bem recebem pouco benefício da sobrecarga de orquestração.

Oh My Opencode vs OpenCode Puro: Quando Usar Cada Um

Oh My Opencode não é universalmente melhor que OpenCode puro. É um multiplicador de poder para uma classe específica de trabalho — e sobrecarga para tudo o mais.

Use a pilha completa do OMO (com ultrawork) quando:

  • A tarefa abrange múltiplos arquivos e camadas
  • Você precisa de pesquisa, planejamento, implementação e verificação como fases distintas
  • Você se beneficia de agentes de fundo paralelos (Explore, Librarian) reunindo contexto enquanto trabalhadores executam
  • O escopo é grande o suficiente que você teria que cuidar do agente através de múltiplos prompts sequenciais

Use OpenCode puro (ou um suporte mais esguio) quando:

  • A tarefa cabe em uma única janela de contexto
  • O problema é raciocínio puro sem pesquisa externa
  • Você está executando modelos de orçamento — eles se beneficiam mais de um prompt limpo e focado do que da complexidade de orquestração
  • Você quer faturamento previsível sem surpresas de roteamento por categoria

O risco de faturamento é real e subnotificado. Até que o disjuntor chegue, trate o OMO com Gemini como exigindo monitoramento ativo — não como um sistema “disparar e esquecer”. Para tudo o mais, o sistema é genuinamente impressionante quando apontado para o problema certo.

Fontes

Discussões e questões da comunidade referenciadas neste artigo: