Claude Fable 5.2 vs Opus 5.5 : code et tâches d'agent

Sur ces quatre petites tâches de code et d'outils, le surcoût de Fable 5.2 ne se justifie pas : Claude Fable 5.2 et Claude Opus 5.5 ont tous deux réussi les 29 vérifications de code, et l'estimation au tarif standard atteignait $0,031 pour Opus sur l'ensemble, contre $0,146 pour Fable. Envisagez Fable pour un raisonnement plus difficile ou de longues exécutions d'agent quand Opus avec un effort plus élevé ne suffit pas.

Fable 5.2 et Opus 5.5 en un coup d'œil

Fable 5.2 est plus récent, mais les deux modèles partagent la même fenêtre de contexte de 1M tokens et la même sortie de 128K tokens. La différence pratique de ce test portait sur la consommation de tokens, pas sur l'exactitude du code.

Les pages modèle d'Anthropic pour Fable 5.2 et Opus 5.5 les listent tous deux comme actifs, avec entrée texte et image. Fable est sorti le 9 novembre 2026 ; Opus, le 22 septembre 2026. Leurs niveaux d'effort par défaut diffèrent : réglez medium sur les deux quand vous les comparez.

La vue d'ensemble des modèles d'Anthropic recommande Opus 5.5 pour la plupart des tâches. Elle positionne Fable 5.2 pour le raisonnement exigeant et le travail d'agent de longue haleine, ou pour les cas où les évaluations d'Opus 5.5 à effort plus élevé restent insuffisantes. C'est le positionnement de l'éditeur ; ce test couvre quatre petites tâches.

Pour les changements de version, lisez ce qui a changé dans Fable 5.2. Pour une analyse d'un seul modèle, voir la critique d'Opus 5.5.

Combien coûtent les quatre tâches

La page tarifs officielle d'Anthropic indique $8 en entrée et $40 en sortie par million de tokens pour Fable 5.2, contre $4 et $20 pour Opus 5.5 (vérifiée le 12 nov. 2026). Batch divise les deux paires par deux ; le mode fast les double.

Sur les quatre tâches notées, Fable a consommé 3 439 tokens d'entrée et 2 954 de sortie. Opus en a consommé 2 421 et 1 065. Au tarif standard, cela donne :

• Fable : (3 439 × $8 + 2 954 × $40) ÷ 1 000 000 = $0,1457
• Opus : (2 421 × $4 + 1 065 × $20) ÷ 1 000 000 = $0,0310

Ce sont des estimations au tarif standard calculées à partir des tokens observés, pas des factures ni des montants OmniaKey. La réponse d'Opus annonçait la vitesse fast, celle de Fable standard ; Anthropic affiche l'entrée et la sortie en fast au double du tarif standard. Nous ramenons ici les deux au tarif standard, donc ces chiffres ne constituent pas une comparaison contrôlée de temps ni de facturation.

Estimations au tarif standard, en dollars américains :

En moyenne sur les quatre tâches testées, Fable coûtait $0,0364 et Opus $0,0077 ; l'estimation au tarif standard de Fable dépassait celle d'Opus de $0,1147 sur l'ensemble. La règle pratique est le coût par tâche exploitable : dépense API plus temps de nouvelle tentative et de relecture. Montez en gamme quand des cas réels échoués justifient cette dépense supplémentaire ; ces quatre petites tâches ne le font pas.

Les totaux en temps réel étaient de 27,8 s pour Fable et 43,6 s pour Opus. Les réponses de Fable annonçaient la vitesse standard, celles d'Opus fast, et nous n'avons fixé ni l'une ni l'autre ; lisez-les comme des observations, pas comme un classement de vitesse.

Deux correctifs Python : 22/22 vérifications pour les deux

Les deux correctifs sont courts, et les deux modèles ont rendu des fonctions qui marchent. Les échecs méritent d'être réutilisés parce qu'ils testent la gestion des révisions et les cas limites de pagination, pas la connaissance d'une bibliothèque.

Totaux d'usage : un échec plus récent doit effacer un succès plus ancien

L'ancienne fonction additionnait tous les événements complete. Elle ignorait revision et status, si bien qu'une nouvelle tentative comptait les tokens deux fois et qu'une révision failed récente ne pouvait pas annuler une complete plus ancienne.

La règle centrale du prompt :

Keep only the highest revision for each event_id, and on equal revisions keep the last occurrence in the input. A newer failed revision supersedes an older complete one and contributes nothing.

La plus petite reproduction est l'événement x en révision 1, complete, 10 tokens, suivi de x en révision 2, failed, 10 tokens. Le total correct est zéro ; l'ancienne fonction renvoie 10.

Les deux modèles ont gardé la révision la plus haute, utilisé l'ordre d'entrée pour les révisions égales, sauté les gagnants failed, conservé les utilisateurs à zéro token et laissé l'entrée inchangée. Résultat : 8/8 vérifications chacun, avec des fonctions équivalentes.

Pagination par curseur : les égalités ne doivent ni répéter ni sauter

L'ancienne version triait seulement par ts, découpait la première page avant d'appliquer le curseur, acceptait les horodatages égaux avec <=, ne validait jamais limit et renvoyait toujours un curseur suivant. Avec deux lignes à ts=4, cela répète ou saute un ID.

Les règles centrales du prompt :

Sort descending by (ts,id). Select rows strictly LESS than the cursor tuple, so tied timestamps neither repeat nor skip IDs. Return next_cursor only if MORE eligible rows remain. Raise ValueError unless limit is an integer from 1 through 100; bool is invalid.

Les deux ont tout corrigé : tri par tuple, strictement inférieur, filtrage de la liste complète avant le découpage, curseur suivant seulement s'il reste des lignes, et validation qui rejette True, False, 0, 101, 1.5, '2' et None. Résultat : 14/14 vérifications chacun, dont un parcours d'une ligne sur des horodatages égaux.

Le registre asynchrone : mêmes chiffres, JSON différent

Les deux modèles ont réussi le rapprochement : $0,93 net réservé, t3 en attente, t1 et t5 terminées, et poll_existing pour t3.

Le fixture synthétique fourni utilise des montants illustratifs, pas les prix d'OmniaKey. Ses lignes clés :

POST key=a => 201 task=t1 quote=0.40

POST key=a, identical body => 200 task=t1

GET t1 => SUCCEEDED

POST key=b => 201 task=t2 quote=0.40

GET t2 => FAILED

POST key=c => 201 task=t3 quote=0.13

Client stopped polling t3 after 120 seconds; last status PROCESSING

POST key=d => 201 task=t4 quote=0.13

GET t4 => CANCELED

POST key=e => 201 task=t5 quote=0.40

GET t5 => SUCCEEDED

L'arithmétique est 0,40 + 0,13 + 0,40 = 0,93. t2 et t4 sont remboursées ; t1 et t5 consomment ; t3 garde sa réservation parce que le client a cessé d'interroger, pas parce que la tâche a échoué.

En ne comptant que les tâches dont le dernier état observé est SUCCEEDED, les deux ont renvoyé les mêmes valeurs. Fable a renvoyé du JSON brut. Opus a enveloppé le JSON dans un bloc de code JSON. Le prompt disait "Return ONLY JSON", donc un json.loads strict sur la réponse d'Opus échoue tant que le bloc n'est pas retiré. C'est un écart de format seulement : la demande portait sur du texte JSON simple, sans schéma JSON ni mode de sortie structurée. Résultat : les valeurs passent dans les deux cas ; pour l'automatisation, validez la réponse brute avec un parseur strict ou passez à la sortie structurée. C'était un écart observé, pas un schéma général.

La tâche fichier en deux tours : une lecture, un patch

L'ancien remaining_quota du fixture soustrayait les units de chaque événement. Il ignorait le dernier état de chaque id et le plancher max(0, ...), donc les tâches failed ou canceled consommaient quand même du quota, et les événements répétés étaient débités deux fois.

La tâche :

Use read_file once to inspect quota.py, then return one Python code block containing only a corrected remaining_quota(limit, events) function.

Les deux modèles ont fait exactement un appel read_file pour quota.py. Une fois le fixture revenu, les deux ont renvoyé la même logique de patch : garder le dernier événement par id, additionner les units seulement pour reserved ou succeeded, et renvoyer max(0, limit - consumed). Résultat : 7/7 vérifications chacun, y compris les cas failed puis reserved et dépassement de limite.

Ce sont deux tours et un fixture. Cela montre que les modèles demandent le bon fichier et le corrigent ; cela ne couvre pas une longue exécution d'agent.

Comment nous avons testé

Le 12 nov. 2026, nous avons envoyé quatre tâches à claude-fable-5-2 et claude-opus-5-5 via le point d'accès Messages d'OmniaKey. Chaque paire modèle/tâche utilisait une conversation neuve et un cache froid, avec effort medium, max_tokens 4096 par requête, sans system prompt, sans temperature ni top_p, et un seul essai. Nous avons alterné le modèle qui passait en premier selon la tâche.

La tâche d'agent utilisait un outil read_file strict avec tool_choice: auto ; tout le reste était un seul message utilisateur. Le correcteur filtrait chaque réponse Python par AST, puis l'exécutait dans un processus isolé avec un délai de 3 secondes sur 8 cas d'usage, 14 de curseur et 7 d'agent : 29 cas de code par modèle. Chaque requête a été exécutée une fois.

Le premier prompt du registre laissait ouvert le point de savoir si les tâches FAILED/CANCELED appartiennent à completed_task_ids. Nous avons remplacé cette manche ambiguë par une relance clarifiée par modèle, en ne comptant que les tâches dont le dernier état observé est SUCCEEDED ; les sorties d'origine sont exclues des totaux des quatre tâches notées.

Les 12 requêtes ont renvoyé HTTP 200 avec l'ID de modèle demandé et se sont terminées par end_turn, ou tool_use puis end_turn, sans troncature. Les deux annonçaient service tier standard. Fable annonçait la vitesse standard et des comptes de tokens de thinking séparés ; Opus annonçait la vitesse fast et omettait le champ des tokens de thinking. Nous n'avons pas fixé la vitesse, et les tokens de sortie incluent déjà le thinking facturé, donc le champ absent d'Opus ne dit rien d'un thinking nul.

La même chaîne d'effort est un réglage, pas un budget de calcul aligné. Cette exécution maintient l'effort à medium ; pour votre propre travail, parcourez les niveaux d'effort dont votre tâche a besoin. C'est un test sur un petit fixture, pas un benchmark sur un dépôt complet ni sur un agent de longue durée. Il ne prédit pas les taux de réussite sur d'autres tâches. OmniaKey vend l'accès aux deux modèles ; les prix ci-dessus sont les tarifs catalogue officiels d'Anthropic.

Quand évaluer Fable

Commencez par Opus 5.5 pour un travail court et bien spécifié. Il a égalé Fable sur les 29 vérifications de code, et l'estimation au tarif standard de Fable valait 4,7 fois celle d'Opus.

Traitez Fable 5.2 comme le candidat suivant pour un raisonnement exigeant ou de longues boucles d'outils, après qu'Opus à effort plus élevé a échoué sur vos cas réels. C'est le positionnement d'Anthropic ; cette exécution ne couvre que les quatre petites tâches. Testez 10 à 20 échecs réels avant de changer.

Le billet de lancement de Fable 5.2 d'Anthropic ajoute un chiffre rapporté par l'éditeur : Fable 5.2 en High a obtenu 45,3 % sur FrontierCode 2.0 contre 45,5 % pour Opus 5.5 en Max, pour environ la moitié du coût par tâche. Le billet indique aussi que Fable 5.2 en Xhigh atteint 49,1 %, le meilleur score de tous les modèles publiés testés. Cela associe Fable High à Opus Max, une comparaison différente de notre test à effort medium identique.

Pour un vrai projet, comparez la dépense API avec le temps de nouvelle tentative et de relecture par tâche exploitable. Sur un travail petit et déjà réussi, Opus est le choix par défaut le moins cher.

Pour utiliser l'un ou l'autre modèle dans Claude Code, le guide de configuration de Claude Code donne l'URL de base et les réglages de clé. Pages modèle : Claude Fable 5.2 et Claude Opus 5.5.

Questions fréquentes

Fable 5.2 vaut-il son prix plus élevé face à Opus 5.5 ?

Envisagez Fable après qu'Opus à effort plus élevé a échoué sur vos propres cas, puis vérifiez que Fable les améliore ; cette exécution ne tranche pas sur les tâches difficiles. Sur nos quatre petites tâches, les deux ont réussi 29/29 vérifications de code ; l'estimation au tarif standard de Fable était de $0,1457 contre $0,0310 pour Opus.

Fable 5.2 et Opus 5.5 ont-ils réussi les mêmes tests de code ?

Oui. Les deux ont réussi 8/8 cas d'usage, 14/14 cas de curseur et 7/7 cas de patch de fichier. La réponse du registre était aussi correcte chez les deux, avec une différence de format : Opus a ajouté un bloc de code JSON.

Lequel coûte le moins cher pour coder, Fable 5.2 ou Opus 5.5 ?

Aux tarifs catalogue standard d'Anthropic, Opus 5.5 : $4 en entrée et $20 en sortie par million de tokens, contre $8 et $40. Nos tokens placent l'estimation au tarif standard de Fable à 4,7 fois celle d'Opus : $0,1457 contre $0,0310 sur quatre tâches.

Fable 5.2 est-il plus rapide qu'Opus 5.5 ?

Notre exécution laisse la question ouverte. Les totaux observés étaient de 27,8 s pour Fable et 43,6 s pour Opus, mais les réponses de Fable annonçaient la vitesse standard et celles d'Opus fast, et nous n'avons pas fixé la vitesse. Comparez-les à nouveau avec le même réglage de vitesse.

Puis-je utiliser les deux modèles dans Claude Code via OmniaKey ?

Oui. Dans cette exécution, nous avons appelé les deux ID de modèle via OmniaKey, et le guide de configuration de Claude Code montre l'URL de base et la clé. Vérifiez le nom du modèle dans votre client après la connexion.

Sources vérifiées

• Anthropic : Présentation du modèle Claude Fable 5.2
• Anthropic : Introducing Claude Fable 5.2 and Mythos 5.2
• Anthropic : Présentation du modèle Claude Opus 5.5
• Anthropic : Vue d'ensemble des modèles
• Anthropic : Tarifs

Toutes vérifiées le 12 nov. 2026.