Minha Análise do Opencode: Resultados Honestos, Riscos de Cobrança e Quando Vale a Pena

O que realmente ocorre quando você executa o Ultrawork.

Conteúdo da página

Oh My Opencode promete uma “equipe de desenvolvedores de IA virtual” — Sisyphus orquestrando especialistas, tarefas executando 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 nesta pilha tecnológica:

Este artigo pressupõe que você já está familiarizado com o sistema e deseja saber se ele realmente performa. Para uma visão mais ampla de como o OMO se encaixa na cadeia de ferramentas de codificação de IA, veja a visão geral das ferramentas para desenvolvedores 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 o Sisyphus Ignora a Delegação Sem um Prompt Explícito de Ultrawork

A primeira coisa que encontrei foi que o 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 completamente as fases de pesquisa e planejamento. Nenhuma delegação ao 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 só faça o trabalho direto você mesmo quando a delegação for irrazoável

Depois que fiz isso, o sistema se comportou como anunciado. Mas o comportamento padrão sem esse enquadramento foi 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 submetesse URLs à API IndexNow para indexação de motores de busca. Esta é uma tarefa multifase com escopo razoável: ler a especificação da API, projetar a CLI, implementar e testar.

Com o Oh My Opencode e o 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 padrão da CLI. O agente Bibliotecário puxando a documentação do IndexNow contribuiu com contexto que a execução do modelo puro perdeu.

log de sessão 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 overhead 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 para onde as páginas do site devem 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 os tokens.

Esta é uma tarefa de raciocínio de janela de contexto única. Não há paralelismo para explorar, nenhum conhecimento especialista para puxar de um subagente. A camada de orquestração adicionou overhead 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 o Overhead 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 do que modelos fortes. Claude Opus é resiliente o suficiente para produzir uma boa saída mesmo com uma camada pesada de orquestração ao redor dele. Um modelo menor como Big Pickle beneficia-se mais de um prompt limpo e focado do que de uma configuração multiagente complexa que adiciona ruído ao contexto.

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

Descobertas da Comunidade do Oh My Opencode: Benchmarks, Cobrança e Armadilhas do Mundo Real

Antes de apostar tudo, 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 o OpenCode Puro

Um membro da comunidade executou um benchmark sistemático em 120+ combinações de agente/modelo e publicou os resultados. Com o OMO Ultrawork ativado, a taxa de aprovação em sua avaliação de codificação foi de 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 Opus com mais etapas.” Opus é particularmente resiliente a diferenças de suporte — ele entrega resultados fortes independentemente do que estiver 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 é inútil. Para tarefas grandes de múltiplos arquivos, agentes de fundo paralelos e fluxos de trabalho de engenharia complexos, o overhead 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.

Overhead de Tokens de Início: 15.000–25.000 Tokens Antes de Qualquer Trabalho Começar

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 da configuração da janela de contexto antes que qualquer trabalho real aconteça. O mantenedor está ciente disso e trabalhando no carregamento de ferramentas adiadas, 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 que um usuário fosse cobrado ~$438 em uma única tarde. Três problemas separados se somaram:

  1. Sem disjuntor: O OMO não tinha limite máximo de passos por subagente. Um modelo do Gemini ficou preso em um loop de verificação git diff / read e executou 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 Compose UI 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 no banco de dados SQLite depois do fato.

  3. Exibição de custo incorreta: O snapshot 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 conta 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-readonly.”

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

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

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

Os primeiros usuários descobriram que sem ultrawork, o agente principal frequentemente não delega para subagentes especialistas de todo — ele simplesmente começa a chamar read e grep diretamente. O mantenedor reconheceu isso cedo: “parece difícil alcançar a chamada do 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 o OpenCode puro com uma janela de contexto mais pesada. Isso corresponde ao 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 o overhead completo de orquestração de agentes, o oh-my-opencode-slim é um fork da comunidade que reduz o conjunto de recursos. Alguns usuários também migraram para o oh-my-pi, que foca na execução de tarefas de fundo e ganchos enquanto mantém a superfície do prompt mínima.

Um usuário disse bem: “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. Trabalho de engenharia grande e multifase justifica o OMO completo. Para tarefas diárias mais curtas, um suporte mais leve frequentemente produz melhores resultados com menos custo.

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

Para equilibrar as ressalvas, 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 trabalhadores executam correções simultaneamente
  • App Tauri de 45k linhas convertido para um app web SaaS durante a noite — o modo de entrevista do Prometheus produziu um plano detalhado, Ralph Loop 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 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 e focado seria suficiente recebem pouco benefício do overhead de orquestração.

Oh My Opencode vs OpenCode Puro: Quando Usar Cada Um

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

Use a pilha OMO completa (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, Bibliotecário) 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 o OpenCode puro (ou um suporte mais leve) 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 cobrança previsível sem surpresas de roteamento por categoria

O risco de cobrança é real e subnotificado. Até que o disjuntor seja lançado, trate o OMO com o 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:

Assinar

Receba novos artigos sobre sistemas, infraestrutura e engenharia de IA.