Recensione di Oh My Opencode: Risultati onesti, rischi di fatturazione e quando ne vale la pena

Cosa accade effettivamente quando esegui Ultrawork.

Indice

Oh My Opencode promette un “team virtuale di sviluppatori AI” — Sisyphus che orchestra specialisti, compiti eseguiti in parallelo e la magica parola chiave ultrawork che attiva tutto.

Questa promessa regge per il carico di lavoro giusto. Per quello sbagliato, aggiunge costi e complessità senza migliorare i risultati. Questo articolo illustra cosa è realmente accaduto durante i test pratici e cosa ha scoperto la comunità più ampia dopo mesi di utilizzo reale.

agenti pigri che lavorano in parallelo

Se sei nuovo nello stack,

Questo articolo presuppone che tu sia già familiare con il sistema e voglia sapere se funziona davvero. Per una visione più ampia di come OMO si inserisce nella catena di strumenti per lo sviluppo AI, consulta la panoramica degli strumenti per sviluppatori AI.

Prestazioni di Oh My Opencode: Risultati dei Test Pratici

Ho eseguito gli stessi test che uso per OpenCode “nudo” — gli stessi compiti di benchmark LLM eseguiti su OpenCode con modelli locali Ollama e llama.cpp. Questa volta sul modello Big Pickle (GLM 4.6 tramite OpenCode Zen — il piano gratuito).

La versione breve: risultati misti, e il modo in cui falliva è stato istruttivo.

Perché Sisyphus Salta la Delega Senza un Prompt Esplicito per Ultrawork

La prima cosa che ho riscontrato è che Sisyphus non si comportava come un orchestratore senza un prompting esplicito. Anche con il prefisso ulw, ha iniziato a fare tutto il lavoro da solo — leggendo file direttamente, scrivendo codice, saltando completamente le fasi di ricerca e pianificazione. Nessuna delega a Oracle, nessuna esecuzione parallela di Explore, nessun colloquio con Prometheus.

Per attivare effettivamente l’orchestrazione, ho dovuto essere esplicito nel prompt:

ulw ricerca prima la codebase,
crea un piano dettagliato,
delega i compiti di implementazione,
e fai lavoro diretto solo quando la delega non è ragionevole

Una volta fatto questo, il sistema si è comportato come pubblicizzato. Ma il comportamento predefinito senza quel contesto era quello di OpenCode standard con una finestra di contesto più pesante. La parola chiave ultrawork da sola non è una garanzia di delega — è un prerequisito per essa.

Test 1: Strumento CLI IndexNow — Dove l’Orchestrazione di Oh My Opencode Paga il Gioco

Il compito era costruire uno strumento da riga di comando che invia URL all’API IndexNow per l’indicizzazione nei motori di ricerca. Si tratta di un compito a più fasi con un ambito ragionevole: leggere le specifiche API, progettare la CLI, implementare, testare.

Con Oh My Opencode e un prompting esplicito per l’orchestrazione, il risultato è stato visibilmente migliore rispetto al solo OpenCode. Lo strumento finale estraeva correttamente gli URL da sitemap.xml e li inviava in batch, oltre a supportare le opzioni CLI standard. L’agente Librarian che recuperava la documentazione di IndexNow ha fornito un contesto che l’esecuzione del modello base aveva perso.

log di sessione oh my opencode indexnow

Questo è il tipo di compito per cui OMO è stato costruito: ricerca + implementazione + alcune decisioni di progettazione. Qui il sovraccarico ha pagato.

Test 2: Mappatura delle Migrazioni delle Pagine — Stesso Risultato, Tripla dei Token

Il secondo test era un compito di analisi documentale: stabilire dove le pagine del sito web dovevano essere migrate in base ai loro slug e a un documento di politica di migrazione.

Il risultato è stato identico all’esecuzione di OpenCode standard — stessa accuratezza, stessa struttura, stesse decisioni. Ma l’esecuzione OMO ha consumato circa tre volte i token.

Questo è un compito di ragionamento con una singola finestra di contesto. Non c’è parallelismo da sfruttare, né conoscenze specialistiche da recuperare da un subagente. Lo strato di orchestrazione ha aggiunto sovraccarico senza aggiungere valore. Per questa classe di compiti, OpenCode standard è la scelta migliore.

Selezione del Modello: Perché i Modelli Più Deboli Lottano con il Sovraccarico di Orchestrazione

L’esecuzione su Big Pickle (un modello del piano gratuito) ha evidenziato qualcosa che anche la comunità ha notato: i modelli più deboli sono più sensibili alla qualità dell’arnese rispetto ai modelli forti. Claude Opus è abbastanza resiliente da produrre un buon output anche con un pesante strato di orchestrazione intorno a sé. Un modello più piccolo come Big Pickle trae più beneficio da un prompt pulito e mirato che da una configurazione multi-agente complessa che aggiunge rumore al contesto.

Se esegui OMO su modelli economici, inizia più semplice. Usa l’orchestrazione per compiti pesanti nella ricerca dove Librarian e Explore aggiungono genuinamente informazioni. Evitala per compiti di puro ragionamento dove il modello ha solo bisogno di un input chiaro e spazio per pensare.

Scoperte della Comunità su Oh My Opencode: Benchmark, Fatturazione e Avvertenze del Mondo Reale

Prima di tuffarsi nel lavoro, vale la pena sapere cosa la comunità ha scoperto attraverso l’uso reale — sia i successi che i modi di fallimento.

Benchmark Oh My Opencode: 69% vs 73% di Tasso di Passaggio, 3× Più Richieste rispetto a OpenCode Vanilla

Un membro della comunità ha eseguito un benchmark sistematico su oltre 120 combinazioni agente/modello e ha pubblicato i risultati. Con OMO Ultrawork abilitato, il tasso di passaggio nella loro valutazione di codifica è stato del 69,2% — contro il 73,1% per OpenCode puro senza OMO. L’esecuzione OMO ha richiesto 10 minuti in più (55 contro 45 minuti) e ha effettuato 96 richieste invece di 27.

La loro conclusione: “è letteralmente solo Opus con più passaggi”. Opus è particolarmente resiliente alle differenze di arnese — fornisce risultati forti indipendentemente da ciò che lo circonda. I modelli più deboli hanno mostrato più sensibilità all’arnese, ma non necessariamente a favore di OMO.

Questo non significa che OMO sia inutile. Per compiti grandi che coinvolgono più file, agenti di background paralleli e flussi di lavoro ingegneristici complessi, il sovraccarico paga il gioco. Ma per compiti di codifica che rientrano in una singola finestra di contesto, OpenCode standard con un buon modello spesso eguaglia o supera un intero stack di orchestrazione.

Sovraccarico dei Token all’Avvio: 15.000–25.000 Token Prima di Iniziare Qualsiasi Lavoro

Una lamentela ricorrente nella comunità è che OMO inietta molti strumenti e MCP all’avvio. Un semplice messaggio “Hello world” può consumare 15.000–25.000 token solo per la configurazione della finestra di contesto prima che inizi qualsiasi lavoro effettivo. Il manutentore è a conoscenza di questo e sta lavorando sul caricamento differito degli strumenti, ma a inizio 2026 è un costo reale da tenere in considerazione nelle stime di prezzo.

Il loop infinito Gemini da $350 — e cosa fare al riguardo

Nel marzo 2026, un bug confermato (issue #2571, etichettato come will-fix) ha causato a un utente di essere addebitato ~$438 in un solo pomeriggio. Tre problemi distinti si sono sommati:

  1. Nessun interruttore di sicurezza: OMO non aveva un limite massimo di passaggi per subagente. Un modello Gemini si è bloccato in un loop di verifica git diff / read ed ha eseguito 809 turni consecutivi in 3,5 ore senza fermarsi.

  2. Instradamento del modello silenzioso: La sessione genitore dell’utente era su GPT-5.4. Ma un compito Compose UI delegato è stato instradato su Gemini 3.1 Pro tramite instradamento per categoria (visual-engineering) — un modello che l’utente non ha selezionato intenzionalmente e di cui non aveva visibilità fino a quando non ha scavato nel database SQLite dopo il fatto.

  3. Visualizzazione del costo errata: Lo snapshot dei prezzi di OpenCode per gemini-3.1-pro-preview mancava la fascia di prezzo per il contesto >200K. Google addebita il doppio per contesti superiori a 200K token, ma OpenCode ha calcolato tutto al tasso base. Il costo visualizzato era meno della metà del fattura reale di Google.

Un commento della comunità ha riassunto bene: “Gemini entra costantemente in loop per me, quindi lo uso raramente come modello non solo lettura.”

Una correzione (PR #2590) è in corso — aggiungendo un limite massimo di passaggi configurabile e un rilevamento dei loop. Finché non viene rilasciato, proteggiti:

  • Controlla la tua configurazione delle categorie. Se qualsiasi categoria è mappata su Gemini (incluso visual-engineering di default), ogni task di background in quella categoria usa Gemini — in silenzio — anche quando la tua sessione in primo piano è su un modello diverso.
  • Imposta limiti espliciti providerConcurrency per Gemini in background_task. Tenendolo a 1 limita il raggio d’azione del danno.
  • Controlla i tuoi dashboard di fatturazione reali del provider, non solo il costo visualizzato da OpenCode, specialmente per Gemini.
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // limite rigido finché non viene rilasciato l'interruttore di sicurezza
    }
  }
}

La Delega Ultrawork Richiede la Parola Chiave — Non è Automatica

Gli utenti precoci hanno scoperto che senza ultrawork, l’agente principale spesso non delega affatto ai subagenti specialisti — inizia semplicemente a chiamare read e grep direttamente. Il manutentore ha riconosciuto questo fin dall’inizio: “sembra difficile riuscire a chiamare l’agente appropriato solo attraverso istruzioni del prompt di sistema senza prompt espliciti.”

La parola chiave ultrawork è ciò che innesca affidabilmente l’orchestrazione. Senza di essa, spesso stai eseguendo OpenCode standard con una finestra di contesto più pesante. Questo corrisponde a ciò che ho trovato nei miei test personali.

Alternative Leggere a OMO: OMO Slim e Oh-My-Pi

Se vuoi gli ganci di esecuzione in background e i miglioramenti chiave di OMO senza il sovraccarico completo dell’orchestrazione degli agenti, oh-my-opencode-slim è un fork della comunità che riduce l’insieme delle funzionalità. Alcuni utenti si sono anche spostati su oh-my-pi, che si concentra sull’esecuzione dei task in background e sui ganci mantenendo la superficie del prompt minima.

Un utente lo ha espresso bene: “Mi piace OMO per i suoi ganci e l’esecuzione dei task in background. Penso che OMO slim stia cercando di ottimizzare le cose sbagliate. I prompt base di OpenCode più i lavoratori in background e i ganci che auto-promptano il modello per continuare quando decide di fermarsi sarebbero sufficienti per me.”

La scelta giusta dipende dal tuo profilo di task. Un lavoro ingegneristico grande e a più fasi giustifica OMO completo. Per i task quotidiani più brevi, un arnese più snello spesso produce risultati migliori con meno costi.

Quando Oh My Opencode Supera Genuinamente: Risultati Reali degli Utenti

Per bilanciare le avvertenze, ecco ciò che gli utenti riportano come i punti di forza più chiari di OMO:

  • 8.000 avvisi ESLint risolti in un giorno — agenti Explore paralleli che scansionano la codebase mentre gli agenti worker eseguono le correzioni simultaneamente
  • App Tauri da 45k righe convertita in un’app web SaaS overnight — la modalità intervista di Prometheus ha prodotto un piano dettagliato, Ralph Loop l’ha eseguito dall’inizio alla fine
  • Funzionalità full-stack implementate end-to-end senza che l’utente toccasse la tastiera oltre al prompt iniziale
  • Revisioni architetturali su codebase ereditati — il ruolo di consulenza solo lettura di Oracle evidenzia problemi senza apportare accidentalmente modifiche

Il filo comune: compiti che traggono beneficio dal parallelismo e hanno criteri di accettazione chiari che Prometheus può verificare. I compiti in cui un modello singolo e focalizzato andrebbe bene ottengono poco beneficio dal sovraccarico di orchestrazione.

Oh My Opencode vs OpenCode Standard: Quando Usare Ciascuno

Oh My Opencode non è universalmente migliore di OpenCode standard. È un moltiplicatore di forza per una specifica classe di lavoro — e un sovraccarico per tutto il resto.

Usa lo stack completo OMO (con ultrawork) quando:

  • Il compito si estende su più file e livelli
  • Hai bisogno di ricerca, pianificazione, implementazione e verifica come fasi distinte
  • Trai beneficio da agenti di background paralleli (Explore, Librarian) che raccolgono contesto mentre i worker lavorano
  • L’ambito è abbastanza grande che altrimenti dovresti “babysitter” l’agente attraverso più prompt sequenziali

Usa OpenCode standard (o un arnese più snello) quando:

  • Il compito rientra in una singola finestra di contesto
  • Il problema è di puro ragionamento senza ricerca esterna
  • Stai eseguendo modelli economici — traggono più beneficio da un prompt pulito e mirato che dalla complessità dell’orchestrazione
  • Vuoi una fatturazione prevedibile senza sorprese legate all’instradamento per categoria

Il rischio di fatturazione è reale e sottovalutato. Finché l’interruttore di sicurezza non viene implementato, tratta OMO con Gemini come richiedente un monitoraggio attivo — non come un sistema “lancia e dimentica”. Per tutto il resto, il sistema è genuinamente impressionante quando puntato al problema giusto.

Fonti

Discussioni e issue della comunità citate in questo articolo: