Claude Opus 5 vs Claude Fable 5 : benchmark API réel en 7 tâches et recommandations de routage en production

Claude Opus 5 vs Claude Fable 5 : 7 tests API réels et recommandations de routage en production#

Comment choisir entre Claude Opus 5 et Claude Fable 5 ? Si l’on ne regarde qu’une seule réponse réussie, les deux modèles savent produire de très belles démonstrations mathématiques. En production, l’expérience dépend surtout de trois autres facteurs : la capacité à livrer la tâche de manière stable, la latence adaptée à l’interaction, et la possibilité de récupérer automatiquement après un échec.

Le 25 juillet 2026, nous avons testé les deux modèles sur 7 types de tâches, via la même API OpenAI-compatible, avec les mêmes prompts et les mêmes paramètres. Les résultats ne confirment pas le récit simpliste selon lequel « le plus gros modèle est forcément meilleur » :

• claude-fable-5 a été plus rapide et plus concis sur les tâches réussies par les deux modèles ;
• claude-opus-5 a finalement couvert les 7 types de tâches ;
• Fable 5 a déclenché à répétition content_filter sur un prompt ordinaire de revue de code et sur un prompt JSON d’incident ;
• sur la tâche de physique, Opus 5 a renvoyé deux fois une salutation sans rapport malgré un HTTP 200, avant de répondre correctement à la 3e tentative.

Cela signifie qu’un choix de modèle en production ne devrait pas se résumer à un seul model ID. L’approche la plus robuste consiste à choisir d’abord un modèle principal selon le type de tâche, puis à encapsuler les anomalies avec une validation de contenu, des retries et un fallback de modèle.

Tester Opus 5 et Fable 5 avec la même API

Conclusions rapides#

Si vos types d’entrée sont imprévisibles, ou si vous devez minimiser le risque que des prompts métier ordinaires soient filtrés, privilégiez Opus 5. Si la structure des tâches est fixe, déjà couverte par des tests de régression, et que la vitesse d’interaction ainsi que la longueur des réponses comptent davantage, Fable 5 est plus adapté comme premier saut.

Méthodologie de test#

Avant les tests, nous avons appelé l’endpoint de liste des modèles pour confirmer que les deux model IDs exacts étaient visibles :

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
claude-fable-5

Toutes les requêtes formelles sont passées par le même endpoint :

POST https://cn.crazyrouter.com/v1/chat/completions

Conditions communes :

Même system prompt
Même user prompt
temperature = 1
Même max_tokens pour chaque question
stream = true
Aucun outil ni accès web activé

Le system prompt unifié demande uniquement de répondre avec exactitude et de respecter le format de sortie, sans rôle ou cadrage favorisant un modèle :

Answer the user's task accurately. Follow every requested output format and length constraint exactly. Do not use external tools.

Nous n’avons pas seulement enregistré le texte final, mais aussi :

• le statut HTTP et finish_reason ;
• le response ID et le returned model ;
• le délai jusqu’au premier token visible et la latence totale ;
• les completion tokens et reasoning tokens ;
• la conformité de la réponse visible aux critères d’acceptation de la tâche ;
• la possibilité de récupérer une requête anormale via un retry avec les mêmes paramètres.

Il s’agit d’un test de bout en bout via la passerelle Crazyrouter, et non d’une expérience ciblant un canal upstream unique. Les résultats reflètent donc à la fois le comportement des modèles, le filtrage upstream, le routage de la passerelle et l’état des canaux au moment du test. Ils permettent de répondre à la question « que rencontrera réellement un utilisateur via cette API », mais ne doivent pas être présentés comme un classement pur des capacités hors ligne de la famille Claude.

Pour comprendre pourquoi les tests de modèles doivent enregistrer finish_reason et le budget de sortie, vous pouvez aussi lire le retest max_tokens de Claude Fable 5 vs GPT-5.5.

Tableau récapitulatif des 7 résultats#

Taux de livraison au test principal :

Claude Opus 5: 6 / 7 = 85.7%
Claude Fable 5: 5 / 7 = 71.4%

Après ajout des retries :

Claude Opus 5: 7 / 7
Claude Fable 5: 5 / 7

Ici, « livraison » ne signifie pas que la requête a réussi techniquement, mais que le métier reçoit une réponse visible conforme à l’énoncé. Même si HTTP 200, le nom du modèle et le token usage sont présents, un corps vide, filtré ou limité à une salutation reste un échec de tâche.

Mathématiques, contraintes et statistiques : les deux modèles sont fiables#

La tâche mathématique utilisait une chaîne de Markov à trois états et demandait de calculer le temps d’attente avant la première arrivée à l’état 3 en partant de l’état 1 :

E1[τ]
E1[τ²]
Var1(τ)

Les deux modèles ont donné :

E1[τ] = 5
E1[τ²] = 43
Var1(τ) = 18

Ils ont également écrit la matrice transitoire Q ainsi que les équations des moments d’ordre 1 et 2. Sur cette tâche, nous n’avons pas observé de cas où les nombres finaux seraient corrects mais la dérivation incohérente.

La recherche sous contraintes demandait de placer cinq conférences A, B, C, D et E dans cinq créneaux, en respectant des contraintes d’adjacence immédiate, d’ordre, d’écart et de non-adjacence. Les deux modèles ont trouvé l’ordre unique :

A, C, E, B, D

La tâche de correction statistique introduisait volontairement une conclusion fausse : « la moyenne vaut 10, la variance vaut 4, donc P(X≥14)=0.5 ». Les deux modèles ont expliqué que les deux premiers moments ne suffisent pas à déterminer de manière unique la probabilité de queue, puis ont utilisé l’inégalité unilatérale de Chebyshev/Cantelli pour obtenir :

P(X >= 14) <= 0.2

Ces trois catégories montrent que l’avantage de vitesse de Fable 5 ne vient pas d’un sacrifice de la justesse du raisonnement de base. Sur des tâches mathématiques et logiques claires, courtes et vérifiables, il peut tout à fait servir de premier saut plus léger.

Les précédents tests Claude Fable 5 vs Claude Sonnet 5 via API et GLM-5.2 vs Fable 5 sur le budget de sortie montrent également qu’évaluer l’adéquation d’un modèle à production impose de considérer ensemble la justesse, le budget de sortie et la forme de livraison.

Physique : Fable réussit au premier essai, Opus récupère à la troisième tentative#

La tâche de physique portait sur un oscillateur à deux degrés de liberté avec amortissement à la masse et amortissement de couplage. Elle demandait de calculer les deux fréquences propres non amorties ainsi que la réponse fréquentielle complexe des deux masses à ω=8 rad/s.

Les valeurs de référence étaient :

ω1 = 10.0204 rad/s
ω2 = 16.2149 rad/s
|X1| = 0.14929 m, phase = -12.15°
|X2| = 0.07174 m, phase = -13.90°

Fable 5 a fourni tous les résultats corrects dès la première tentative. Les deux premiers appels à Opus 5 ont en revanche présenté une anomalie particulièrement importante pour les équipes production : l’interface a renvoyé HTTP 200 et finish_reason=stop, mais le corps ne contenait que :

Hi! How can I help you today?

Pour ces deux réponses, les prompt tokens n’étaient que 10, ce qui ne correspondait clairement pas à l’entrée réelle. À la 3e exécution de la même requête, Opus 5 a répondu complètement après 34.901 secondes, et les six valeurs numériques ont toutes passé la vérification.

Cette anomalie ne doit donc pas être classée comme une « erreur de calcul en physique », mais comme un cas où « le contexte de requête n’a pas été traité normalement ». La défense la plus simple n’est pas de faire lire les logs à un humain, mais de mettre en place côté appelant une validation au niveau tâche : la réponse doit contenir ω1, ω2, X1 et X2 ; si l’un de ces champs manque, on retry.

Code et JSON strict : le filtrage de Fable est le principal écart de cette série#

La tâche de code demandait au modèle de relire un détecteur de cycles DFS en Python. Le bug était très ordinaire : une fois le DFS d’un nœud terminé, celui-ci n’était pas retiré de l’ensemble visiting, ce qui faisait considérer à tort un nœud déjà terminé comme encore présent dans la pile de récursion, produisant ainsi de faux cycles sur un DAG.

Opus 5 a correctement indiqué le correctif minimal :

visiting.discard(node)
visited.add(node)
return False

Fable 5 n’a pas renvoyé d’analyse de code : finish_reason=content_filter, corps vide. Pour exclure un biais du system prompt ou un routage accidentel, nous avons effectué trois séries : test original, retest avec system prompt nettoyé, puis retry indépendant sur la seule question. Le résultat a été content_filter à chaque fois.

La tâche JSON strict ne contenait pas non plus de contenu dangereux. L’entrée ne donnait que le nombre total de requêtes sur 15 minutes, le nombre d’échecs, l’attribution par canal, le nombre de récupérations par retry et les actions de remédiation ; la consigne demandait de produire un objet JSON. Le JSON renvoyé par Opus 5 était directement parsable ; Fable 5 a de nouveau été filtré 3 fois de suite.

Ces deux échecs montrent que le filtrage de sécurité fait lui aussi partie des capacités production d’une API de modèles. Si un modèle déclenche de manière stable de faux positifs sur de la revue de code normale ou sur du texte de post-mortem d’incident, il ne peut pas reprendre directement tout le trafic métier, même s’il est plus rapide sur les tâches mathématiques.

response ID des deux retries indépendants :

Revue de code : gen-1784915384-vGI1PtuNXZG0IJ2YiaCz
JSON d’incident : gen-1784915390-buOWZQSnqjgHeJ6nUogF

Latence et longueur de sortie#

Pour éviter de comptabiliser les temps très courts des requêtes échouées comme un « avantage de vitesse », nous ne comparons ici que les quatre tâches réussies par les deux modèles : mathématiques, recherche sous contraintes, correction statistique et conception expérimentale.

Dans ce petit échantillon, la latence totale P50 de Fable 5 est inférieure d’environ 24 %, le délai jusqu’au premier token visible d’environ 17 %, et les réponses sont environ 43 % plus courtes. Pour le chat, les résumés en lot et les tâches structurées à haute fréquence, ces écarts influencent directement le temps d’attente utilisateur et le volume de traitement en aval.

Mais il ne faut pas transformer la médiane de 4 questions en SLA. La charge upstream, le cache, le routage et le rate limiting peuvent modifier la latence. Avant une mise en production, il faut répéter 20 à 50 fois avec vos propres prompts métier, puis calculer P50, P95, P99 et le coût réel par résultat accepté.

Les réponses du test principal de Fable 5 fournissaient un champ cost, pour un total d’environ $0.24596 sur 7 appels. Le usage d’Opus 5 ne fournissait pas de champ cost au même format ; cet article ne tranche donc pas le coût en dollars entre les deux modèles. L’absence du champ ne signifie pas que l’usage est gratuit, et il ne faut pas compléter ce coût avec des prix non vérifiés.

Stratégie de routage recommandée en production#

L’appel à un seul modèle est le plus simple à implémenter, mais il expose directement l’utilisateur final à tous les comportements occasionnels du modèle. Pour les deux modèles de cette série, la répartition la plus raisonnable est la suivante.

Fable 5 comme premier saut#

Adapté à :

• des tâches mathématiques, de raisonnement sous contraintes et de résumé court déjà validées par régression ;
• des interactions sensibles au premier token et à la latence globale ;
• des tâches où l’on souhaite contrôler la longueur des réponses et réduire la charge de post-traitement.

La condition préalable est que la famille de tâches ait déjà fait l’objet de tests de filtrage, et que le client vérifie content_filter, les corps vides et les champs manquants.

Opus 5 comme fallback à large couverture#

Adapté à :

• des types d’entrée imprévisibles ;
• des scénarios nécessitant une couverture plus large, comme la revue de code, le JSON strict ou la physique complexe ;
• des cas où il faut récupérer automatiquement la requête utilisateur après un filtrage par Fable 5.

Opus 5 ne doit pas non plus être dispensé de contrôle. L’anomalie de salutation observée dans cette série prouve qu’un HTTP 200 avec stop peut encore ne pas contenir de réponse métier.

Exemple Python OpenAI-compatible#

L’exemple ci-dessous appelle d’abord Fable 5, puis bascule vers Opus 5 en cas de filtrage, de corps vide ou d’échec de validation ; si Opus renvoie encore seulement une salutation, il retry une fois.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://cn.crazyrouter.com/v1",
)


def valid_answer(text: str, required_terms: tuple[str, ...]) -> bool:
    normalized = (text or "").strip()
    if not normalized:
        return False
    if normalized.lower().startswith("hi! how can i help"):
        return False
    return all(term in normalized for term in required_terms)


def call_model(model: str, prompt: str) -> tuple[str, str | None]:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=1,
        max_tokens=3000,
    )
    choice = response.choices[0]
    return choice.message.content or "", choice.finish_reason


def routed_completion(prompt: str, required_terms: tuple[str, ...] = ()) -> str:
    for model, attempts in (("claude-fable-5", 1), ("claude-opus-5", 2)):
        for _ in range(attempts):
            text, finish_reason = call_model(model, prompt)
            if finish_reason == "content_filter":
                break
            if valid_answer(text, required_terms):
                return text
    raise RuntimeError("No model produced a valid business answer")


answer = routed_completion(
    "Return a JSON incident summary with keys total, failed, recovered.",
    required_terms=('"total"', '"failed"', '"recovered"'),
)
print(answer)

En production, il faut aussi journaliser le model, le response ID, finish_reason, la latence totale et la raison d’échec de validation. C’est ainsi que vous pourrez distinguer une erreur de calcul du modèle, une sortie tronquée, un filtrage de contenu et une perte d’entrée au routage, au lieu de tout ranger dans une catégorie vague de « modèle en échec ».

Si vous planifiez une infrastructure multi-modèles, vous pouvez consulter les différences entre AI API Gateway, agrégateur et API de modèle directe, ainsi que le test en sept dimensions de Kimi K3 vs Opus 4.8.

Recommandation finale#

La conclusion la plus utile de cette série n’est pas de savoir qui obtient le meilleur score, mais de constater que les deux modèles échouent différemment :

• L’avantage de Fable 5 est d’être plus rapide et plus court sur les tâches communes ; son risque est de filtrer de manière stable certains prompts métier ordinaires.
• L’avantage d’Opus 5 est de couvrir toutes les tâches après retry ; son risque est de renvoyer occasionnellement une salutation sans rapport avec l’entrée réelle.

Nous recommandons donc de placer Fable 5 en amont des tâches fréquentes déjà validées, d’utiliser Opus 5 comme fallback à couverture plus large, et d’appliquer une validation de contenu sur les deux chemins. C’est ainsi qu’un comparatif de modèles devient de la fiabilité réelle, plutôt qu’un simple classement.

Créer une API Key et reproduire ce routage à deux modèles

FAQ#

Claude Opus 5 est-il forcément plus puissant que Claude Fable 5 ?#

On ne peut pas conclure à partir de ce petit échantillon qu’il est « plus puissant sur toutes les tâches ». Les deux modèles réussissent les mathématiques, les contraintes, la correction statistique et la conception expérimentale ; Fable 5 est plus rapide et plus concis, tandis qu’Opus 5 couvre davantage de tâches. Le choix doit se fonder sur le taux de réussite par tâche concrète, pas sur le nom du modèle.

Claude Fable 5 convient-il à la production ?#

Oui, pour les tâches ayant passé des tests de régression. Dans cette série, il est correct et rapide sur plusieurs tâches de raisonnement, mais il déclenche des filtres à répétition sur la revue de code et le JSON d’incident. Avant la mise en ligne, il faut mesurer le taux de filtrage avec de vrais prompts et configurer Opus 5 ou un autre modèle en fallback.

Pourquoi HTTP 200 peut-il quand même compter comme un échec ?#

HTTP 200 indique seulement que l’interface a terminé sa réponse. Un corps vide, finish_reason=content_filter, une sortie tronquée ou une simple salutation ne remplissent pas la tâche métier. Les métriques de production doivent mesurer le « taux d’acceptation après validation », et pas seulement le taux de succès HTTP.

Pourquoi le returned model est-il anthropic/claude-fable-5 ?#

La requête utilise claude-fable-5, tandis que le returned model dans la réponse est stable sous la forme préfixée par le provider, anthropic/claude-fable-5. On peut le considérer comme un alias normalisé ; le seul changement de préfixe ne suffit pas à prouver qu’un remplacement de modèle a eu lieu.

Peut-on comparer directement le coût en dollars des deux modèles ?#

Pas dans cette série. Les réponses de Fable 5 fournissaient un champ cost, alors qu’Opus 5 ne fournissait pas le même champ dans un format comparable. Une comparaison rigoureuse des coûts doit s’appuyer sur des logs de facturation unifiés et utiliser comme métrique le « coût par résultat accepté ».

Combien de répétitions faut-il avant de décider une mise en production ?#

Nous recommandons au moins 20 à 50 répétitions par famille de tâches critique, en couvrant les entrées normales, les cas limites, les entrées longues et les entrées susceptibles de déclencher un filtrage. Il faut au minimum enregistrer le taux de réussite de tâche, le taux de filtrage, le taux de corps vide, le taux de troncature, les latences P50/P95/P99 et le coût.

Comment commencer les tests ?#

Utilisez https://cn.crazyrouter.com/v1 comme base URL OpenAI-compatible, puis appelez séparément claude-opus-5 et claude-fable-5. Fixez les prompts et les paramètres, sauvegardez les réponses brutes, puis utilisez des assertions locales ou une validation structurée pour déterminer si la tâche est réellement terminée.

Commencer votre test Claude à deux modèles