Claude Fable 5 Benchmarks : Ce que les chiffres révèlent

Lorsqu’Anthropic a lancé Claude Fable 5 le 9 juin 2026, le modèle a été présenté comme à la pointe sur presque tous les benchmarks testés. Point important pour les développeurs : l’annonce publie surtout des classements plutôt que des tableaux de scores numériques complets. Utilisez donc ces résultats comme des signaux directionnels, puis validez Fable 5 sur vos propres prompts, vos contraintes de latence et vos coûts. Pour situer le modèle dans le paysage actuel, vous pouvez aussi lire notre comparaison Opus 4.8 vs GPT-5.5 vs Gemini 3.5.

Essayez Apidog aujourd’hui

Fable 5 est disponible sous l’identifiant de modèle claude-fable-5, avec un prix annoncé de 10 $ par million de tokens d’entrée et 50 $ par million de tokens de sortie. Il se place au-dessus d’Opus 4.8 en capacités et en prix. Anthropic le positionne comme son modèle Claude public le plus puissant pour l’ingénierie logicielle, le travail du savoir, la vision et la recherche scientifique.

En bref

Claude Fable 5 se classe en tête ou au niveau de l’état de l’art sur plusieurs benchmarks rapportés par Anthropic :

• FrontierCode : meilleur classement parmi les modèles de pointe, y compris à effort moyen.
• CursorBench : état de l’art sur des tâches de codage longues et multi-étapes.
• Finance Benchmark de Hebbia : meilleur score rapporté, notamment sur documents, graphiques et tableaux.
• FrontierBench : meilleur classement rapporté sur le raisonnement à long terme.

Ces résultats indiquent surtout une force sur les tâches autonomes longues. Comme les scores publics détaillés restent limités, traitez les classements comme des indicateurs utiles, mais non suffisants pour une décision de production.

Ce que signifie vraiment “à la pointe”

Anthropic décrit Fable 5 comme étant à la pointe de la technologie sur presque tous les benchmarks exécutés, couvrant le code, le travail documentaire, la vision et la science.

Cette formulation ne signifie pas que Fable 5 gagne chaque test avec une large marge. Elle signifie plutôt que le modèle se situe régulièrement dans le haut du classement sur plusieurs familles d’évaluations.

Pour un développeur, c’est cette cohérence multi-domaines qui compte :

• un modèle fort en codage mais faible en analyse documentaire peut être risqué dans un agent complet ;
• un modèle bon sur un benchmark isolé peut échouer sur des workflows longs ;
• un modèle proche du sommet en code, finance, vision et raisonnement long est plus intéressant pour des systèmes agentiques.

Si vous évaluez Fable 5 face à un modèle moins cher, regardez donc moins le slogan “SOTA” que la question suivante : le modèle reste-t-il fiable sur vos tâches longues, multi-fichiers ou multi-documents ?

Pour un aperçu du modèle lui-même, consultez aussi ce qu’est Claude Fable 5.

Benchmarks de codage : FrontierCode et CursorBench

Le codage est le domaine où les résultats rapportés sont les plus concrets.

Sur FrontierCode, une évaluation de codage de Cognition, Anthropic indique que Fable 5 obtient le meilleur classement parmi les modèles de pointe. Le détail important : ce résultat est rapporté à effort moyen.

Dans une évaluation LLM, le niveau d’effort peut changer fortement le résultat. Certains modèles deviennent meilleurs lorsqu’on leur accorde plus de calcul d’inférence, plus de tokens de raisonnement ou plusieurs tentatives. Un modèle qui reste en tête à effort moyen est donc plus pertinent pour un usage quotidien qu’un modèle qui ne gagne qu’à coût maximal.

Sur CursorBench, Anthropic présente Fable 5 comme état de l’art sur des problèmes de codage plus longs. L’intérêt de ce benchmark est qu’il se rapproche davantage du travail réel dans une base de code :

• lecture de plusieurs fichiers ;
• planification d’une modification ;
• édition cohérente ;
• exécution ou prise en compte de tests ;
• itération sur plusieurs étapes.

La lecture pratique est simple : Fable 5 est surtout intéressant si vous utilisez un agent de codage qui doit travailler longtemps, modifier plusieurs fichiers et conserver un plan cohérent. Pour de simples complétions de snippets, l’écart de prix peut être plus difficile à justifier.

Travail documentaire et finance : Finance Benchmark de Hebbia

En dehors du code, le signal le plus clair vient du Finance Benchmark de Hebbia, orienté vers les tâches financières et juridiques riches en documents.

Anthropic rapporte que Fable 5 obtient le meilleur score global sur ce benchmark, avec des gains concentrés sur :

• le raisonnement documentaire ;
• l’interprétation de graphiques ;
• l’extraction depuis des tableaux.

Ces capacités sont importantes parce que les workflows financiers ne consistent pas seulement à répondre à une question textuelle. Ils demandent souvent de :

1. lire un PDF long ;
2. retrouver une valeur sur plusieurs pages ;
3. comparer un tableau avec le texte qui l’explique ;
4. éviter les erreurs de colonne ou d’unité ;
5. produire une réponse vérifiable.

L’aspect vision compte aussi. Les graphiques et tableaux sont parfois présents sous forme d’images ou de mises en page mixtes. Un bon résultat sur ce benchmark suggère donc que Fable 5 peut mieux gérer des documents réels et imparfaits, pas seulement du texte propre.

Pour les développeurs, les cas d’usage à tester sont :

• extraction structurée depuis PDF ;
• analyse de rapports financiers ;
• revue de contrats ;
• synthèse de dossiers avec tableaux ;
• agents internes pour analystes ou équipes juridiques.

Avant toute mise en production, validez sur vos propres documents. Les benchmarks génériques ne remplacent pas un jeu d’évaluation représentatif de vos données.

Raisonnement à long terme : FrontierBench

La deuxième évaluation de Cognition, FrontierBench, met l’accent sur le raisonnement à long terme. Anthropic rapporte que Fable 5 y obtient le meilleur classement.

Le raisonnement long ne se limite pas à répondre correctement à une question difficile. Il mesure plutôt la capacité du modèle à :

• conserver un objectif ;
• maintenir un plan ;
• utiliser un contexte qui grossit ;
• éviter de dériver ;
• terminer une tâche malgré de nombreuses étapes intermédiaires.

C’est exactement le type de capacité recherché dans les agents autonomes. Une tâche longue échoue rarement parce que le modèle ne connaît pas une API. Elle échoue souvent parce qu’il perd le fil, répète une étape, modifie le mauvais fichier ou oublie une contrainte initiale.

Il faut toutefois rester prudent : les benchmarks de raisonnement long sont difficiles à standardiser. La méthodologie, le scoring partiel et la définition de “rester sur la tâche” peuvent varier fortement. Le résultat FrontierBench est donc un signal fort, mais à compléter avec des tests internes.

Signaux réels au-delà des benchmarks

Les benchmarks sont utiles, mais les déploiements réels donnent parfois un meilleur aperçu des capacités d’un modèle.

Anthropic met en avant deux exemples.

Migration de codebase chez Stripe

Anthropic rapporte que Fable 5 a migré une codebase Ruby de 50 millions de lignes pour Stripe en une journée, alors que l’équipe estimait initialement ce travail à deux mois ou plus.

Le point important n’est pas seulement “le modèle sait coder”. Une migration de cette taille exige :

• des modifications répétées mais cohérentes ;
• une compréhension de nombreux fichiers ;
• une faible dérive dans le temps ;
• une capacité à respecter des patterns existants ;
• une gestion des cas particuliers.

Ce type de tâche mesure l’endurance opérationnelle plus que la résolution d’un puzzle isolé.

Test Slay the Spire avec mémoire persistante

Anthropic cite aussi un test sur Slay the Spire, utilisé pour mesurer l’effet d’une mémoire persistante. Avec une mémoire de fichier activée, Fable 5 aurait montré une amélioration de 3x par rapport à Opus 4.8 dans ce contexte.

Le mécanisme est intéressant pour les développeurs d’agents : le modèle écrit des notes, les relit entre les exécutions et accumule une stratégie. Cela suggère que Fable 5 peut mieux bénéficier d’un environnement avec état persistant, au lieu de recommencer chaque session à froid.

Pour vos propres systèmes, cela signifie que le modèle doit être évalué avec les outils réels que vous comptez lui donner :

• fichiers ;
• mémoire longue durée ;
• base vectorielle ;
• historique de tâches ;
• outils de test ;
• accès à une documentation interne.

Un modèle peut être moyen en mode “prompt unique” et nettement meilleur lorsqu’il est intégré dans un agent bien instrumenté.

Comment interpréter les résultats

Voici les points à vérifier avant de tirer une conclusion.

1. Les benchmarks viennent de partenaires

FrontierCode et FrontierBench viennent de Cognition. Le Finance Benchmark vient de Hebbia. Ce sont des organisations crédibles, mais elles font aussi partie du récit de lancement.

Cela ne rend pas les résultats invalides. Cela signifie simplement qu’il faut attendre ou rechercher des reproductions indépendantes avant de considérer ces classements comme définitifs.

Pour comparer plus largement les familles de modèles, vous pouvez aussi consulter notre analyse MiniMax M3 vs Opus 4.7 vs GPT-5.5.

2. Le niveau d’effort change la comparaison

Un score sans information sur l’effort, le nombre de tentatives ou la configuration d’inférence est incomplet.

Lorsque vous comparez deux modèles, vérifiez :

• le niveau d’effort ;
• le nombre de runs ;
• la température ;
• la limite de tokens ;
• les outils autorisés ;
• le contexte fourni ;
• le mode agentique ou non.

Deux modèles testés avec des budgets différents ne sont pas comparés équitablement.

3. Les scores publics restent limités

L’annonce d’Anthropic s’appuie surtout sur des classements, avec plusieurs graphiques publiés sous forme d’images. Cela limite les comparaisons numériques précises.

Si vous voyez des chiffres circuler ailleurs, vérifiez leur source primaire avant de les utiliser pour une décision d’achat ou d’architecture.

4. Le rang ne dit pas la marge

“Meilleur score” indique le classement, pas l’écart. Un modèle peut être premier avec une avance minime ou massive. Sans scores détaillés, l’avantage doit être considéré comme réel mais non quantifié.

Avant de configurer un déploiement, vérifiez toujours les identifiants, prix et limites actuels dans l’aperçu officiel des modèles Claude.

Exécuter votre propre benchmark avec Apidog

Le benchmark le plus utile est celui qui utilise vos prompts, vos contraintes et votre définition de “bon”.

Vous pouvez construire une évaluation légère avec Apidog, en comparant Fable 5 à Opus 4.8 sur trois dimensions :

• qualité de sortie ;
• latence ;
• coût en tokens.

L’objectif est simple : créer une requête API réutilisable, l’exécuter avec claude-fable-5, puis dupliquer la requête avec claude-opus-4-8.

1. Créer la requête Claude Messages

Configurez une requête POST vers l’API Messages de Claude :

POST https://api.anthropic.com/v1/messages
x-api-key: {{ANTHROPIC_API_KEY}}
anthropic-version: 2023-06-01
content-type: application/json

Dans Apidog, stockez votre clé dans une variable d’environnement :

ANTHROPIC_API_KEY=sk-ant-...

2. Utiliser un prompt représentatif

Évitez les prompts jouets. Choisissez une tâche proche de votre production.

Exemple pour un cas de refactoring Ruby :

{
  "model": "claude-fable-5",
  "max_tokens": 2048,
  "messages": [
    {
      "role": "user",
      "content": "Refactorisez cette méthode Ruby pour utiliser des arguments nommés et ajouter des tests RSpec. Ne renvoyez que le code mis à jour :\n\ndef charge(amount, currency, customer_id, idempotency_key)\n  # ...\nend"
    }
  ]
}

Exécutez d’abord la requête avec :

"model": "claude-fable-5"

Puis dupliquez-la et remplacez uniquement le modèle :

"model": "claude-opus-4-8"

Comme le prompt reste identique, les différences viennent du modèle, pas de la requête.

3. Évaluer la qualité

Créez une grille simple avant de regarder quel modèle a répondu.

Par exemple :

Critère	Score
Respect de l’instruction	0-5
Correction du code	0-5
Couverture des cas limites	0-5
Lisibilité	0-5
Facilité d’intégration	0-5

Notez chaque réponse à l’aveugle si possible. Cela réduit le biais lié au nom du modèle.

4. Mesurer la latence

Apidog affiche le temps de réponse de chaque appel. Pour un outil interactif, la latence peut compter autant que la qualité.

Comparez notamment :

• temps de première réponse ;
• durée totale ;
• stabilité entre plusieurs runs ;
• impact du max_tokens.

Un modèle plus précis mais beaucoup plus lent peut être moins adapté à un assistant temps réel.

5. Calculer le coût réel

La réponse Claude inclut un bloc usage :

{
  "usage": {
    "input_tokens": 1234,
    "output_tokens": 567
  }
}

Pour Fable 5, avec les prix annoncés :

coût = (input_tokens / 1_000_000 * 10) + (output_tokens / 1_000_000 * 50)

Exemple rapide :

input_tokens = 10 000
output_tokens = 2 000

coût = (10 000 / 1 000 000 * 10) + (2 000 / 1 000 000 * 50)
     = 0,10 + 0,10
     = 0,20 $

Répétez le calcul pour Opus 4.8 avec ses tarifs publiés, puis comparez le ratio qualité/prix.

6. Tester plusieurs familles de tâches

Ne vous limitez pas à un seul prompt. Créez un petit jeu de 5 à 10 cas représentatifs :

• refactoring ;
• génération de tests ;
• analyse d’erreur ;
• résumé de document ;
• extraction de données depuis tableau ;
• revue de PR ;
• plan de migration ;
• correction d’un bug multi-fichier.

Après quelques runs, vous aurez une réponse plus fiable que n’importe quel classement public : Fable 5 apporte-t-il une amélioration mesurable sur vos tâches, à un coût acceptable ?

Vous pouvez télécharger Apidog et configurer ce test rapidement. Pour approfondir la partie budget, consultez aussi notre guide de tarification de Fable 5.