Fable non si può più usare, ma non è il caso di arrendersi ── Andare avanti con OpenRouter Fusion＋LLM cinesi＋uno strato di revisione

1. Fable è morto. E adesso?

Diciamolo onestamente: siamo lontanissimi da Fable.

Al momento in cui scrivo, l’agente di coding IA “Fable” offerto da Anthropic ha cessato il servizio. Quella precisione, quella velocità, quella sensazione di integrazione perfetta: al momento non esiste nulla di equivalente in grado di sostituirlo.

Detto questo, non ci si può limitare a stare a guardare. Cercando alternative, il quadro è questo:

• Claude Code / Claude Sonnet: intelligente, ma da solo non arriva alla precisione di Fable, e i costi salgono
• GPT-5 / GPT-5.5: sorprendentemente scarso. Con codebase lunghe va rapidamente in affanno. Ed è anche caro
• Cursor / Windsurf: buona esperienza d’uso, ma dipende dal modello dietro le quinte. Non consente una configurazione libera
• LLM locali (Ollama, ecc.): veloci, ma la precisione crolla non appena si affida loro un repository reale

Dopo aver provato di tutto, ecco dove sono arrivato: generare codice con la funzione Fusion di OpenRouter＋LLM cinesi, e completare il tutto con una revisione di gpt-5.5-pro o una PR review di Codex. Non regge minimamente il confronto con Fable, ma è decisamente più utilizzabile del semplice gpt-5.5. Se la cava, entro certi limiti.

Tuttavia, trattandosi di LLM cinesi, dargli in pasto codice di lavoro fa comunque un po’ paura. Questo approccio è pensato esclusivamente per progetti personali o hobbistici.

2. Che cos’è OpenRouter Fusion?

OpenRouter è un gateway API che permette di richiamare in modo unificato più provider di LLM. Claude, GPT, Gemini, DeepSeek: tutti utilizzabili con la stessa interfaccia.

Questo OpenRouter dispone di una funzione chiamata “Fusion”.

In breve, è un meccanismo che invia un unico prompt a più modelli, ne analizza le risposte e fa sì che un solo modello ne ricavi l’output finale. Lo si può descrivere come un “collegio deliberante fra modelli”.

Nel concreto, il flusso è il seguente:

1. L’utente inserisce un prompt
2. I modelli indicati in analysis_models rispondono contemporaneamente allo stesso prompt
3. Il modello indicato in model confronta e analizza queste risposte, strutturando punti di accordo, contraddizioni, lacune e punti ciechi (= il ruolo di giudice)
4. A quel punto, lo stesso modello scrive la risposta finale basandosi su questa analisi

Un punto importante: non è possibile assegnare ruoli o prompt diversi ai singoli modelli di analisi. Tutti ricevono lo stesso prompt, rispondono in modo indipendente, e il giudice ne valuta le differenze: un meccanismo semplice, senza trucchi.

L’agente di coding da riga di comando opencode supporta Fusion in modo nativo come plugin. Basta scrivere la configurazione in opencode.json per ottenere un agente in cui più modelli collaborano nella generazione e revisione del codice.

3. La configurazione effettiva

Di seguito il nucleo del opencode.json che uso attualmente.

{
  "model": "openrouter/openrouter/fusion",
  "provider": {
    "openrouter": {
      "models": {
        "openrouter/fusion": {
          "name": "OpenRouter Fusion (Custom DeepSeek V4 Pro)",
          "options": {
            "plugins": [
              {
                "id": "fusion",
                "analysis_models": [
                  "xiaomi/mimo-v2.5-pro",
                  "z-ai/glm-5.1",
                  "deepseek/deepseek-v4-pro",
                  "moonshotai/kimi-k2.7-code",
                  "minimax/minimax-m3"
                ],
                "model": "deepseek/deepseek-v4-pro",
                "max_tool_calls": 8
              }
            ]
          }
        }
      }
    }
  }
}

L’insieme è composto da cinque modelli di analisi e un modello di esecuzione.

Modelli di analisi (tutti vedono lo stesso prompt e rispondono contemporaneamente)

Modello di esecuzione (scrive la risposta finale sulla base dei risultati dell’analisi)

• deepseek/deepseek-v4-pro: partendo dalle risposte dei modelli di analisi, si occupa della generazione effettiva del codice e della modifica dei file.

Perché LLM cinesi?

Semplicemente perché il rapporto qualità-prezzo è travolgente.

Nel 2026 gli LLM cinesi hanno prezzi API pari a 1/5-1/20 di quelli di Anthropic o OpenAI, a fronte di prestazioni equivalenti o superiori. In particolare le capacità di coding di DeepSeek V4 Pro danno spesso, nell’uso reale, la sensazione di essere alla pari o addirittura superiori a Claude Sonnet e GPT-5.5.

4. Come funziona ── perché Fusion da solo non basta

Il flusso con il solo Fusion è questo:

1. L’utente inserisce un prompt
2. I cinque modelli di analisi generano ciascuno in modo indipendente una risposta
3. Il modello di esecuzione (DeepSeek V4 Pro) confronta e analizza queste risposte, producendo un’analisi strutturata che estrae punti di accordo, contraddizioni e lacune
4. Sulla base di questa analisi, lo stesso modello di esecuzione (DeepSeek V4 Pro) genera il codice finale

Il tutto ricorda il lavoro di squadra umano: cinque ingegneri esaminano la stessa specifica e forniscono ciascuno il proprio commento di revisione, mentre una sola persona (DeepSeek V4 Pro) analizza e organizza il tutto prima di implementarlo.

Sul limite della finestra di contesto: la finestra di contesto di Fusion è di 128K token. A prima vista può sembrare poco, e in effetti si riempie più in fretta del previsto, perché oltre alla cronologia della conversazione deve contenere anche le risposte di tutti e cinque i modelli. Ma non è il caso di allarmarsi. Anche se si superano i 128K e il passaggio di sintesi di Fusion fallisce, ciascun modello di analisi ha già terminato individualmente l’elaborazione del prompt, con la propria finestra di contesto molto più ampia (DeepSeek V4 Pro a un milione di token, Kimi K2.7 a circa 260.000, ad esempio). Anche opencode conserva la cronologia dell’intera sessione, quindi la “memoria” dei modelli non va persa. Nella pratica, per come lo vivo io, non rappresenta un ostacolo serio.

Ma con questo soltanto si resta ancora molto lontani da Fable. Fable, pur essendo un modello singolo, superava con facilità la precisione di un collegio deliberante fra più modelli. È la vera forza di Anthropic.

Per questo si aggiunge un ulteriore strato di revisione all’output di Fusion. Le opzioni sono due.

Opzione A: revisione del codice tramite gpt-5.5-pro

1. Generare il codice con la configurazione Fusion
2. Sottoporre il codice generato a gpt-5.5-pro con l’istruzione “revisiona questo e proponi correzioni”
3. Far applicare tali correzioni al modello di esecuzione originale

gpt-5.5-pro è piuttosto debole nel generare codice da solo, ma sorprendentemente bravo nel revisionare codice già esistente.

Opzione B: PR review tramite GitHub Codex

1. Generare il codice con la configurazione Fusion
2. Aprire una PR e farla passare attraverso la PR review di GitHub Codex
3. Recepire i possibili bug o le perplessità di design segnalati da Codex

Codex effettua la revisione tenendo conto del contesto GitHub (issue, PR precedenti, struttura del progetto), il che gli offre una prospettiva diversa rispetto a una revisione generica basata su LLM.

Una sola delle due opzioni è sufficiente. Fusion (collegio di cinque modelli) → revisione (gpt-5.5-pro o Codex): una configurazione a due livelli. L’idea di fondo è: poiché non si arriva minimamente al livello di Fable in un solo passaggio, si compensa con il processo.

Gli errori di versione delle librerie e l’uso di API inesistenti, frequenti con il solo gpt-5.5, sono diminuiti sensibilmente con questa configurazione.

5. Velocità e praticità

La velocità in sé non differisce molto da quella di un singolo modello. Poiché i cinque modelli girano in parallelo, il tempo di risposta effettivo resta entro un margine accettabile.

Il problema è la precisione. Dove Fable riuscirebbe al primo colpo, questa configurazione comporta diversi rilavori. Il risultato è che il tempo di sviluppo complessivo è chiaramente più lento rispetto a Fable. Ogni errore si paga in lentezza.

Ciò nonostante, è decisamente più utilizzabile del semplice gpt-5.5. Il codice generato con Fusion＋revisione è già piuttosto vicino alla soluzione corretta fin dal primo tentativo: decisamente più veloce che finire, con il solo gpt-5.5, nel ciclo infinito genera → correggi → correggi → correggi.

La sensazione complessiva è: “la velocità non è male. In termini di precisione siamo lontani da Fable, ma diversi gradini sopra il semplice gpt-5.5”. Un compromesso ragionevole.

6. Bonus: lo strato di revisione e altre impostazioni di opencode

Strato di revisione: gpt-5.5-pro oppure PR review di Codex

La configurazione Fusion da sola non ispira piena fiducia, quindi uso una delle due opzioni come strato di revisione.

gpt-5.5-pro: lo designo come sub-agente tramite la funzione task di opencode, con l’istruzione di “revisionare il codice generato e proporre correzioni”. Se gli si fa scrivere codice da zero il risultato è discreto, ma è stranamente bravo a scovare i difetti nel codice scritto da altri.

GitHub Codex: al momento di aprire una PR, eseguo la PR review di Codex. Il fatto che tenga conto del contesto complessivo del progetto le conferisce un sapore diverso rispetto a una revisione generica basata su LLM.

Quale delle due usare dipende dall’umore del momento. Usarle entrambe sarebbe decisamente eccessivo e troppo lento.

Altre impostazioni

Oltre a Fusion, in opencode.json ho inserito alcune impostazioni pratiche aggiuntive.

{
  "permission": {
    "read": "allow",
    "glob": "allow",
    "grep": "allow",
    "task": "allow",
    "webfetch": "allow",
    "websearch": "allow",
    "lsp": "allow",
    "edit": "allow",
    "bash": {
      "*": "allow",
      "Remove-Item *": "deny",
      "del *": "deny",
      "rm *": "deny",
      "rmdir *": "deny",
      "rd *": "deny",
      "erase *": "deny",
      "git clean *": "deny"
    }
  },
  "experimental": {
    "primary_tools": ["task"]
  }
}

Due i punti principali.

1. Blocco dei comandi di eliminazione

Remove-Item, del, rm, rmdir, rd, erase e git clean sono esplicitamente negati. Affidare l’eliminazione dei file a un agente IA mi fa semplicemente paura. Quando serve davvero eliminare qualcosa, lo faccio di persona.

2. primary_tools: ["task"]

Con questo si dà priorità all’esplorazione parallela tramite sub-agenti (task). Quando si leggono o cercano più file contemporaneamente in una codebase di grandi dimensioni, passare per task è decisamente più veloce.

7. In sintesi

La fine di Fable fa male. Fa davvero male. Al momento non esiste nulla che lo superi.

Ma non ci si può limitare a stare a guardare, quindi vado avanti con una configurazione che genera codice con OpenRouter Fusion＋LLM cinesi e lo completa con una revisione di gpt-5.5-pro o una PR review di Codex.

I punti chiave di questa configurazione:

• Generazione di codice tramite il “collegio deliberante” di cinque modelli con OpenRouter Fusion
• Modelli di analisi: Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
• Modello di esecuzione: DeepSeek V4 Pro
• Strato di revisione finale: gpt-5.5-pro o PR review di Codex (una sola delle due)
• Velocità paragonabile a quella di un singolo modello, ma rallentata dai rilavori dovuti a una precisione inferiore a Fable
• Decisamente più utilizzabile del semplice gpt-5.5. Lontano da Fable, ma sufficiente per un uso pratico
• Trattandosi di LLM cinesi, difficile da usare con codice di lavoro. Limitato a progetti personali e hobbistici

Se soffrite la mancanza di Fable con gli agenti di coding IA, o se trovate il semplice gpt-5.5 troppo poco affidabile, questa configurazione merita di essere provata come soluzione temporanea.

Basta avere un account OpenRouter per iniziare a usarla da subito.

Link di riferimento

• OpenRouter: Fusion plugin
• OpenRouter: Fusion Router
• OpenRouter: OpenCode integration
• opencode: Config
• GitHub Codex: PR review
• Anthropic: Claude Fable 5 and Claude Mythos 5

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Che cos'è la funzione Fusion di OpenRouter?

È un meccanismo che invia lo stesso prompt a più modelli contemporaneamente, fa in modo che uno di essi (nel ruolo di giudice) confronti e analizzi le risposte per strutturare punti di accordo, contraddizioni e lacune, e infine fa scrivere la risposta finale a quello stesso modello sulla base di tale analisi. Si può considerare una sorta di collegio deliberante fra modelli. Non è possibile assegnare ruoli o prompt diversi ai singoli modelli di analisi: tutti ricevono esattamente lo stesso prompt. L'agente di coding da riga di comando opencode supporta Fusion in modo nativo come plugin: basta scrivere la configurazione in opencode.json per usarlo.

Perché usare LLM cinesi?

Semplicemente per il loro rapporto qualità-prezzo travolgente. Nel 2026 gli LLM cinesi hanno prezzi API pari a circa 1/5-1/20 di quelli di Anthropic o OpenAI, a fronte di prestazioni equivalenti o superiori. In particolare le capacità di coding di DeepSeek V4 Pro danno spesso, nell'uso reale, la sensazione di essere alla pari o addirittura superiori a Claude Sonnet e GPT-5.5. Va detto però che affidare codice di lavoro a LLM cinesi comporta un rischio concreto, quindi questo approccio è pensato esclusivamente per progetti personali o hobbistici.

Perché Fusion da solo non basta?

Perché nemmeno il collegio deliberante di cinque modelli raggiunge la precisione di Fable. Per questo si aggiunge un ulteriore strato di revisione all'output di Fusion. Le opzioni sono due: far revisionare il codice generato da gpt-5.5-pro e applicarne le correzioni proposte, oppure aprire una PR e farla passare attraverso la PR review di GitHub Codex; una sola delle due è sufficiente. gpt-5.5-pro è piuttosto debole nel generare codice da solo, ma sorprendentemente bravo nel revisionare codice già esistente, mentre Codex fornisce osservazioni che tengono conto del contesto complessivo del progetto.

Quanto è pratica questa configurazione?

Poiché i cinque modelli girano in parallelo, la velocità non si discosta molto da quella di un singolo modello. La precisione, invece, resta ben lontana da Fable, e i rilavori che ne derivano allungano chiaramente il tempo di sviluppo complessivo. Ciò nonostante, è decisamente più veloce che finire, con il solo gpt-5.5, in un ciclo infinito di generazione e correzione, e gli errori di versione delle librerie o l'uso di API inesistenti sono diminuiti sensibilmente. Basta avere un account OpenRouter per provarlo subito.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.