Fable a disparu, mais pas question d'abandonner ── Tenir bon avec OpenRouter Fusion＋LLM chinois＋une couche de revue

1. Fable est mort. Et maintenant, on fait quoi ?

Soyons honnête : on est loin, très loin de Fable.

Au moment où j’écris ces lignes, l’agent de codage IA « Fable » proposé par Anthropic a cessé son service. Cette précision, cette vitesse, cette sensation d’intégration parfaite — rien d’équivalent n’existe pour l’instant pour le remplacer.

Pour autant, impossible de rester les bras croisés. En cherchant des alternatives, voici le paysage :

• Claude Code / Claude Sonnet : intelligent, mais seul il n’atteint pas la précision de Fable, et le coût grimpe vite
• GPT-5 / GPT-5.5 : étonnamment moyen. Il s’essouffle vite face à une base de code longue. Et il est cher
• Cursor / Windsurf : bonne expérience utilisateur, mais tout dépend du modèle en coulisses. Impossible de configurer librement
• LLM locaux (Ollama, etc.) : rapides, mais la précision chute nettement dès qu’on leur confie un vrai dépôt

Après avoir tout essayé, voici où j’ai fini par atterrir : générer le code avec la fonction Fusion d’OpenRouter＋des LLM chinois, puis conclure avec une revue par gpt-5.5-pro ou une revue de PR par Codex. Cela ne rivalise absolument pas avec Fable, mais c’est nettement plus utilisable que gpt-5.5 nu. Ça fait le travail, dans une certaine mesure.

Toutefois, s’agissant de LLM chinois, y confier du code professionnel reste franchement inquiétant. Cette approche est donc pensée exclusivement pour des projets personnels ou de loisir.

2. Qu’est-ce qu’OpenRouter Fusion ?

OpenRouter est une passerelle API qui permet d’appeler plusieurs fournisseurs de LLM via une interface unifiée. Claude, GPT, Gemini, DeepSeek — tout se pilote avec la même interface.

Cet OpenRouter propose une fonctionnalité nommée « Fusion ».

En résumé, il s’agit d’un mécanisme où un même prompt est envoyé à plusieurs modèles, leurs réponses sont analysées, puis un seul modèle en tire la sortie finale. On peut le décrire comme une « délibération collégiale entre modèles ».

Concrètement, le déroulement est le suivant :

1. L’utilisateur saisit un prompt
2. Les modèles listés dans analysis_models répondent simultanément au même prompt
3. Le modèle indiqué dans model compare et analyse ces réponses, en structurant les points d’accord, les contradictions, les manques et les angles morts (= le rôle de juge)
4. Ensuite, ce même modèle rédige la réponse finale en s’appuyant sur cette analyse

Point important : il est impossible d’attribuer des rôles ou des prompts différents à chaque modèle d’analyse. Tous reçoivent le même prompt, répondent indépendamment, et le juge évalue les écarts — un mécanisme simple, sans magie.

L’agent de codage en ligne de commande opencode prend nativement en charge Fusion sous forme de plugin. Il suffit d’écrire la configuration dans opencode.json pour obtenir un agent où plusieurs modèles collaborent pour générer et relire du code.

3. La configuration réelle

Voici le cœur du opencode.json que j’utilise actuellement.

{
  "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’ensemble se compose de cinq modèles d’analyse et d’un modèle d’exécution.

Modèles d’analyse (tous voient le même prompt et répondent simultanément)

Modèle d’exécution (rédige la réponse finale à partir des résultats d’analyse)

• deepseek/deepseek-v4-pro : à partir des réponses des modèles d’analyse, se charge de la génération de code réelle et des modifications de fichiers.

Pourquoi des LLM chinois ?

Tout simplement parce que leur rapport qualité-prix est écrasant.

En 2026, les LLM chinois affichent des tarifs d’API équivalents à 1/5 voire 1/20 de ceux d’Anthropic ou d’OpenAI, pour des performances comparables, voire supérieures. Les capacités de codage de DeepSeek V4 Pro en particulier donnent souvent l’impression, en usage réel, d’égaler ou de dépasser Claude Sonnet et GPT-5.5.

4. Comment ça marche ── pourquoi Fusion seul ne suffit pas

Le flux de Fusion seul se déroule ainsi :

1. L’utilisateur saisit un prompt
2. Les cinq modèles d’analyse génèrent chacun indépendamment une réponse
3. Le modèle d’exécution (DeepSeek V4 Pro) compare et analyse ces réponses, produisant une analyse structurée qui en extrait les points d’accord, les contradictions et les manques
4. En s’appuyant sur cette analyse, ce même modèle d’exécution (DeepSeek V4 Pro) génère le code final

Cela rappelle le fonctionnement d’une équipe humaine : cinq ingénieurs examinent la même spécification et donnent chacun leur avis en revue, puis une seule personne (DeepSeek V4 Pro) analyse et organise le tout avant de l’implémenter.

À propos de la limite de fenêtre de contexte : la fenêtre de contexte de Fusion est de 128K tokens. Cela peut sembler faible au premier abord, et elle se remplit en effet plus vite qu’on ne le pense, car il faut y loger l’historique de conversation en plus des réponses des cinq modèles. Mais pas de panique. Même si l’on dépasse ces 128K et que l’étape de synthèse de Fusion échoue, chaque modèle d’analyse a déjà terminé de traiter le prompt individuellement, avec sa propre fenêtre de contexte, bien plus large (environ 1 million de tokens pour DeepSeek V4 Pro, environ 260 000 pour Kimi K2.7). opencode conserve lui aussi l’historique complet de la session, donc la « mémoire » des modèles n’est pas perdue. Dans la pratique, ce n’est pas un obstacle sérieux, à en juger par mon expérience.

Mais cela seul est encore très loin de Fable. Fable, bien qu’étant un modèle unique, dépassait sans difficulté la précision d’une délibération collégiale entre plusieurs modèles. C’est toute la force d’Anthropic.

On ajoute donc une couche de revue supplémentaire à la sortie de Fusion. Deux options s’offrent alors.

Option A : revue de code par gpt-5.5-pro

1. Générer le code avec la configuration Fusion
2. Soumettre le code généré à gpt-5.5-pro avec la consigne « relis ceci et propose des corrections »
3. Faire appliquer ces corrections par le modèle d’exécution d’origine

gpt-5.5-pro est plutôt faible pour générer du code seul, mais étonnamment doué pour relire du code existant.

Option B : revue de PR par GitHub Codex

1. Générer le code avec la configuration Fusion
2. Soumettre une PR et la faire passer par la revue de PR de GitHub Codex
3. Intégrer les bugs potentiels ou les préoccupations de conception que Codex signale

Codex réalise sa revue en tenant compte du contexte GitHub (issues, PR passées, structure du projet), ce qui lui donne un angle différent d’une revue LLM générique.

L’une des deux options suffit. Fusion (délibération à cinq modèles) → revue (gpt-5.5-pro ou Codex) : une configuration à deux étages. L’idée est la suivante : puisqu’on est loin de rivaliser avec Fable en un seul passage, on compense par le processus.

Les erreurs de version de bibliothèque et l’usage d’API inexistantes, fréquents avec gpt-5.5 nu, ont nettement diminué avec cette configuration.

5. Vitesse et praticité

La vitesse en elle-même ne diffère guère de celle d’un modèle unique. Les cinq modèles tournant en parallèle, le temps de réponse brut reste dans une plage acceptable.

Le problème, c’est la précision. Là où Fable réussirait du premier coup, cette configuration entraîne plusieurs allers-retours. Résultat : le temps de développement total est nettement plus lent qu’avec Fable. Chaque erreur se paie en lenteur.

Cela reste toutefois nettement plus utilisable que gpt-5.5 nu. Le code généré par Fusion＋revue est assez proche de la bonne réponse dès le premier essai — clairement plus rapide que de tomber, avec gpt-5.5 seul, dans la boucle infinie génération → correction → correction → correction.

En ressenti, on pourrait résumer : « la vitesse n’est pas mauvaise. En précision, on est loin de Fable, mais plusieurs crans au-dessus de gpt-5.5 nu. » Un compromis honorable.

6. Bonus : la couche de revue et autres réglages opencode

Couche de revue : gpt-5.5-pro ou revue de PR Codex

La configuration Fusion seule n’inspire pas totalement confiance, donc j’utilise l’une des deux options comme couche de revue.

gpt-5.5-pro : je le désigne comme sous-agent via la fonction task d’opencode, avec la consigne de « relire le code généré et proposer des corrections ». Lui faire écrire du code à partir de rien donne des résultats mitigés, mais il est étonnamment doué pour débusquer les défauts dans le code écrit par d’autres.

GitHub Codex : au moment de soumettre une PR, je lance la revue de PR de Codex. Le fait qu’il tienne compte du contexte global du projet lui donne une saveur différente d’une revue LLM générique.

Le choix entre les deux dépend de l’humeur du jour. Utiliser les deux à la fois serait clairement excessif et bien trop lent.

Autres réglages

Au-delà de Fusion, j’ai ajouté dans opencode.json quelques réglages pratiques supplémentaires.

{
  "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"]
  }
}

Deux points méritent d’être soulignés.

1. Blocage des commandes de suppression

Remove-Item, del, rm, rmdir, rd, erase et git clean sont explicitement refusés. Confier la suppression de fichiers à un agent IA me fait tout simplement peur. Quand une suppression est vraiment nécessaire, je m’en charge moi-même.

2. primary_tools: ["task"]

Cela donne la priorité à l’exploration parallèle via les sous-agents (task). Pour lire ou rechercher simultanément dans plusieurs fichiers d’une grande base de code, passer par task est nettement plus rapide.

7. En résumé

La fin de Fable fait mal. Vraiment mal. Rien de comparable n’existe encore aujourd’hui.

Mais on ne peut pas rester les bras croisés pour autant, alors je tiens bon avec une configuration qui génère le code via OpenRouter Fusion＋LLM chinois, et le finalise avec une revue par gpt-5.5-pro ou une revue de PR Codex.

Les points essentiels de cette configuration :

• Génération de code via la « délibération collégiale » de cinq modèles avec OpenRouter Fusion
• Modèles d’analyse : Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
• Modèle d’exécution : DeepSeek V4 Pro
• Couche de revue finale : gpt-5.5-pro ou revue de PR Codex (l’une des deux)
• Vitesse comparable à celle d’un modèle unique, mais ralentie par les reprises dues à une précision inférieure à Fable
• Nettement plus utilisable que gpt-5.5 nu. Loin de Fable, mais suffisamment fiable pour un usage réel
• Difficilement utilisable pour du code professionnel du fait des LLM chinois. Réservé aux projets personnels et de loisir

Si vous souffrez du manque de Fable dans vos agents de codage IA, ou si vous trouvez gpt-5.5 nu trop peu fiable, cette configuration mérite d’être essayée en solution de repli.

Il suffit d’avoir un compte OpenRouter pour commencer dès aujourd’hui.

Liens de référence

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

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce que la fonctionnalité Fusion d'OpenRouter ?

C'est un mécanisme qui envoie un même prompt à plusieurs modèles simultanément, laisse un modèle (jouant le rôle de juge) comparer et analyser leurs réponses pour structurer les points d'accord, les contradictions et les manques, puis fait écrire la réponse finale par ce même modèle à partir de cette analyse. On peut le voir comme un système de délibération collégiale entre modèles. Il est impossible d'attribuer des rôles ou des prompts différents à chaque modèle d'analyse : tous reçoivent exactement le même prompt. L'agent de codage en ligne de commande opencode prend nativement en charge Fusion sous forme de plugin ; il suffit d'écrire la configuration dans opencode.json pour l'utiliser.

Pourquoi utiliser des LLM chinois ?

Simplement pour leur rapport qualité-prix écrasant. En 2026, les LLM chinois affichent des tarifs d'API équivalents à 1/5 voire 1/20 de ceux d'Anthropic ou d'OpenAI, pour des performances comparables, voire supérieures. Les capacités de codage de DeepSeek V4 Pro en particulier donnent souvent l'impression, en usage réel, d'égaler ou de dépasser Claude Sonnet et GPT-5.5. Cela dit, confier du code professionnel à des LLM chinois comporte un risque réel : cette approche est donc pensée exclusivement pour des projets personnels ou de loisir.

Pourquoi Fusion seul ne suffit-il pas ?

Parce que même la délibération collégiale à cinq modèles n'atteint pas la précision de Fable. On ajoute donc une couche de revue supplémentaire à la sortie de Fusion. Deux options s'offrent alors : faire relire le code généré par gpt-5.5-pro et appliquer ses corrections, ou soumettre une PR passée au crible de la revue de PR de GitHub Codex — l'une des deux suffit. gpt-5.5-pro est plutôt faible pour générer du code seul, mais étonnamment bon pour relire du code existant, tandis que Codex fournit des remarques tenant compte du contexte global du projet.

Quelle est la praticité réelle de cette configuration ?

Comme les cinq modèles tournent en parallèle, la vitesse ne diffère guère de celle d'un modèle unique. La précision, en revanche, reste loin derrière Fable, et les reprises qu'elle entraîne allongent nettement le temps de développement total. Cela reste malgré tout nettement plus rapide que de tomber, avec gpt-5.5 seul, dans une boucle infinie de génération et de correction, et les erreurs de version de bibliothèque ou l'usage d'API inexistantes ont sensiblement diminué. Il suffit d'avoir un compte OpenRouter pour l'essayer immédiatement.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.