Anthropic vient de publier le modèle le plus puissant qu'elle ait jamais construit, et le bond dans les benchmarks est presque la partie la moins intéressante.
Claude Fable 5.1 donne moins l'impression d'un meilleur chatbot que d'un nouveau type d'opérateur. Il peut travailler sur un problème pendant des heures, se rétablir quand un plan échoue, coordonner d'autres agents, inspecter sa propre production et continuer d'avancer sans avoir besoin que quelqu'un vienne le sauver toutes les dix minutes.
Les chiffres le confirment. Dans les évaluations publiées par Anthropic, Fable 5.1 a plus que doublé les performances de Fable 5 en recherche scientifique agentique, est passé de 17,1 % à 31,4 % en automatisation d'entreprise et a atteint 73,4 % sur CursorBench. Il a également surpassé Fable 5, Opus 5 et GPT-5.6 Sol dans la plupart des tests de codage, d'automatisation, d'utilisation d'ordinateur et de travail cognitif rapportés par Anthropic.
https://x.com/claudeai/status/2094848581425377479
Dès la sortie de la boîte, il est exceptionnel pour le codage difficile, le travail à long terme, la recherche, la planification, l'utilisation d'ordinateur et la production de livrables complets. Mais l'opportunité la plus grande réside dans ce qui se produit lorsque vous cessez de l'utiliser comme la personne qui effectue chaque tâche et que vous le mettez aux commandes du système qui fait le travail.
C'est ce que couvre ce cours : là où Fable 5.1 est véritablement différent, comment le mettre en position de leader, comment construire les travailleurs en dessous de lui, comment lui donner des instructions sans l'étouffer, comment utiliser les objectifs et les boucles, et les cinq workflows où la différence peut se transformer en argent réel.
Si vous ne vous souciez pas des terminaux, des fichiers d'agents et de l'orchestration et que vous voulez simplement transformer une idée en une application fonctionnelle, c'est pour cela que nous avons construit Shipper.
ce dans quoi ce modèle est vraiment exceptionnel
Avant les méthodes, rencontrez la machine. Voici les cinq capacités qui rendent Fable 5.1 différent des modèles qui l'ont précédé.
il reste cohérent pendant des durées absurdement longues
Donnez-lui un travail qui prend des heures et il est beaucoup moins susceptible de perdre le fil en cours de route.
Un premier testeur a rapporté une session d'apprentissage automatique non supervisée de 38 heures au cours de laquelle Fable a diagnostiqué un mauvais résultat antérieur, l'a corrigé, a lancé six expériences en parallèle et est revenu avec les conclusions et les prochaines étapes. Un autre a dit qu'il tenait ses propres registres, réévaluait les priorités lorsque les conditions changeaient et reprenait là où il s'était arrêté.
La fenêtre de contexte d'un million de tokens aide, mais la taille du contexte n'est pas la véritable amélioration. L'amélioration est que le modèle peut continuer à prendre des décisions utiles dans ce contexte au lieu de simplement se souvenir que l'information existe.
il cherche la cause profonde, pas le correctif le plus rapide
Les agents précédents trouvaient souvent le premier correctif qui faisait disparaître une erreur. Fable 5.1 est plus enclin à continuer à creuser jusqu'à ce qu'il comprenne pourquoi l'erreur existait.
Dans les tests de lancement d'Anthropic, Millennium lui a donné un crash qui se produisait environ une fois sur un million d'exécutions et qui était resté inexpliqué pendant quatre à cinq ans. Fable 5.1 a désassemblé une bibliothèque externe, l'a connectée au vidage mémoire et a retracé le crash jusqu'au bogue réel. Tous les autres modèles qu'ils avaient essayés, y compris Fable 5, l'avaient manqué.
Cela importe bien au-delà du débogage. Le même instinct se manifeste dans la recherche, la stratégie, l'analyse financière et les opérations : n'optimisez pas le symptôme lorsque le système sous-jacent est erroné.
il peut voir, agir et vérifier
Fable 5.1 peut inspecter des captures d'écran, des graphiques, des PDF, des interfaces et des documents, puis utiliser ce qu'il voit pour guider l'action suivante.
Cela signifie qu'il peut reconstruire une interface à partir de références, lire les chiffres enfouis dans un document financier, utiliser un navigateur, comparer son implémentation au design original et détecter les problèmes visuels avant de déclarer le travail terminé.
Son score d'utilisation d'ordinateur OSWorld a dépassé à la fois Fable 5 et Opus 5 dans les tests d'Anthropic. Plus important encore, le modèle est de plus en plus capable d'utiliser la vision dans le cadre d'une boucle de vérification, et pas seulement de décrire l'image que vous lui avez donnée.
il rend le travail, pas un discours sur le travail
Donnez-lui un dossier de documents et demandez-lui une note d'investissement, une présentation, un prototype fonctionnel ou une analyse, et il est beaucoup plus susceptible de vous rendre l'artefact lui-même.
Les premiers testeurs ont rapporté les meilleurs résultats PowerPoint d'Anthropic à ce jour, un meilleur rappel des citations sur les documents financiers, des commentaires de contrats plus concis et une meilleure réalisation de demandes complexes en plusieurs parties. Un ingénieur de MongoDB a décrit un prototype de trois jours où le modèle a recherché les services existants, conçu le système, l'a implémenté par étapes non supervisées et est revenu avec des présentations visuelles prouvant que chaque étape fonctionnait.
La différence pratique est simple : vous passez moins de temps à convertir une réponse en travail utilisable.
il a été construit pour diriger
Fable 5.1 est le plus précieux lorsqu'il décide de ce qui doit se passer ensuite.
Claude Code peut déjà lui donner des sous-agents, des sessions en arrière-plan, des équipes d'agents, des workflows dynamiques, des objectifs, des boucles, des navigateurs, des terminaux et des fichiers de projet. Fable a suffisamment de profondeur de planification et de contexte pour maintenir ces pièces alignées sur une seule ligne d'arrivée beaucoup plus longtemps que les modèles précédents ne le pouvaient.
C'est pourquoi la configuration ci-dessous fonctionne, et pourquoi le cours commence par sortir Fable du siège de travailleur.
le cockpit : toutes les commandes dont vous avez vraiment besoin
Mettez à jour Claude Code avant toute autre chose. Selon la documentation actuelle de configuration du modèle, la version 2.1.255 ou ultérieure fait que l'alias fable se résout en Fable 5.1, et les versions récentes incluent les commandes goal, loop, background-agent et effort utilisées ci-dessous.
Ensuite, sélectionnez le modèle et le niveau d'effort :
/model fable
/effort high
High est le réglage par défaut judicieux pour un travail substantiel. Passez à medium pour des passages moins chers et plus rapides. Passez à xhigh ou max uniquement lorsque le problème est suffisamment difficile pour justifier plus de réflexion. La pensée adaptative de Fable est toujours activée, donc l'effort est la commande qui compte.
Les commandes restantes sont simples :
/plan ou Shift+Tab : laissez-le inspecter et planifier avant de modifier les fichiers
/goal : continuez à travailler à travers les tours jusqu'à ce qu'une condition testable soit remplie
/loop : réexécutez une invite selon un calendrier pendant que la session reste active
/tasks : voyez ce que font les travailleurs en arrière-plan
/context : voyez ce qui consomme la fenêtre de contexte
Voilà le cockpit.
Le reste du cours consiste à savoir quelle commande utiliser, et quand.
l'événement principal : faites de Fable le leader, pas le travailleur
La plus grande amélioration est un changement de rôle.
Arrêtez de donner à Fable chaque tâche au clavier. Faites-lui définir le travail, divisez-le en voies propres, envoyez ces voies à des agents moins chers et jugez ce qui revient.
La configuration ressemble à ceci :
Fable façonne le plan :
mettez-le en mode plan et laissez-le inspecter le projet avant de proposer des modifications. Si la demande est encore vague, utilisez la
collection de compétences de Matt Pocock pour interroger l'idée, transformer la conversation en spécification et diviser la spécification en tickets.
Fable délègue le travail isolé :
l'implémentation va aux sous-agents Opus ou Sonnet, chaque travailleur possédant une voie délimitée. Codex peut être un autre travailleur si vous l'utilisez déjà, mais il doit suivre les mêmes limites de fichiers et règles de preuve.
Un agent séparé vérifie :
le travailleur ne note pas ses propres devoirs. Un nouveau vérificateur lit le plan, inspecte le diff, exécute les vérifications et soit valide l'étape, soit la renvoie avec un échec concret.
Vous dirigez aux points de contrôle :
approuvez le plan, examinez les compromis importants et inspectez les preuves à la fin. Vous n'avez pas besoin de regarder chaque commande.
Pourquoi cela fonctionne : le modèle coûteux dépense ses tokens pour l'architecture, la priorisation, la récupération et le jugement. Les modèles moins chers dépensent les leurs pour l'exécution délimitée.
L'économie ne fonctionne que lorsque les voies sont véritablement indépendantes. Selon la tarification actuelle de l'API d'Anthropic, Fable 5.1 coûte 10 $ par million de tokens d'entrée et 50 $ par million de tokens de sortie, tandis qu'Opus 5 coûte la moitié et Sonnet 5 un cinquième. Fable 5.1 a également réduit les lectures de cache à 0,25 $ par million de tokens, ce qui rend les longues sessions avec un contexte de projet stable beaucoup plus pratiques.
Ne parallélisez pas pour le spectacle. Cinq agents modifiant les mêmes fichiers créeront cinq factures et un problème de fusion. Parallélisez la recherche, les modules isolés, les tests, la documentation et les autres voies qui peuvent se terminer sans attendre les unes les autres.
construisez vos travailleurs
Le leader a besoin d'une petite équipe, et un travailleur personnalisé n'est qu'un fichier Markdown dans .claude/agents/.
Commencez par un travailleur d'implémentation :
name: implementation-worker
description: Implémente une étape isolée d'un plan approuvé. Utilisez uniquement lorsque l'étape possède des fichiers distincts.
model: opus
tools: Read, Grep, Glob, Edit, Write, Bash
maxTurns: 25
Vous ne possédez que l'étape qui vous est assignée.
Avant de modifier, identifiez les fichiers exacts et les critères d'acceptation dans votre voie.
Ne modifiez pas les fichiers appartenant à un autre travailleur.
Implémentez la solution la plus petite et complète, puis exécutez les tests pertinents.
Retournez :
- les fichiers modifiés
- les vérifications effectuées et leur résultat réel
- tout ce qui est encore incertain
Ne déclarez pas le succès sans preuve de cette exécution.
Créez ensuite le travailleur le plus important, le vérificateur :
name: verifier
description: Vérifie indépendamment une étape terminée par rapport à son plan et à ses critères d'acceptation. Utilisez après chaque étape d'implémentation.
model: opus
tools: Read, Grep, Glob, Bash
maxTurns: 15
Traitez le résumé de l'implémentation comme une affirmation non fiable.
Lisez le plan et inspectez le diff réel. Exécutez les tests pertinents vous-même.
Vérifiez l'exactitude, les régressions, la portée et chaque critère d'acceptation.
Retournez RÉUSSI ou ÉCHEC.
Pour chaque échec, incluez la preuve et la plus petite correction requise.
Ne modifiez jamais l'implémentation que vous évaluez.
Un regard neuf voit ce que l'auteur normalise. Une étape vérifiée immédiatement est beaucoup moins chère qu'un défaut découvert après que quatre autres étapes en dépendent.
Quatre règles maintiennent l'équipe rapide :
un travailleur, une voie, avec une propriété explicite des fichiers
travail en parallèle uniquement lorsque les voies ne dépendent pas les unes des autres
Fable reste en position de leader tandis qu'Opus ou Sonnet s'occupe du travail
chaque affirmation d'achèvement est vérifiée par rapport aux fichiers, aux tests ou au résultat en direct
secret 1 : ne prescrivez pas l'itinéraire
La plupart des conseils sur les invites ont été écrits pour empêcher les modèles plus faibles de s'égarer.
Les longues procédures, les listes d'étapes rigides et les grands blocs de règles aidaient lorsque le modèle ne pouvait pas planifier. Avec Fable 5.1, ce même échafaudage peut le forcer à emprunter un chemin pire que celui qu'il aurait trouvé lui-même.
L'astuce est d'être strict sur la destination et souple sur l'itinéraire.
Donnez-lui quatre choses :
le résultat :
ce qui doit exister lorsque le travail est terminé
les contraintes :
ce qu'il ne peut pas casser, dépenser, exposer ou modifier
la raison :
pour qui est-ce et quelle décision ou quel travail le résultat doit soutenir
**la preuve :
quelle preuve observable comptera comme terminé
Cette dernière partie change tout. "Faire fonctionner le paiement" invite à une affirmation plausible. "Effectuer un achat test dans le bac à sable et montrer la ligne de commande résultante" donne au modèle une ligne d'arrivée qu'il ne peut pas contourner en parlant.
Ne demandez pas une performance de chaîne de pensée cachée. Demandez le plan, les décisions importantes, les preuves et l'incertitude restante. La réflexion de Fable est déjà toujours activée. Ce qui compte pour vous, c'est de savoir si le résultat survit à l'inspection.
Et ne lui rappelez pas constamment que le budget disparaît. Mettez plutôt la limite dans le système : plafonnez les tours des travailleurs, définissez les dépenses autorisées et dites-lui quoi faire lorsque la limite est atteinte.
secret 2 : gardez CLAUDE.md léger
CLAUDE.md est chargé au début de chaque session Claude Code. Cela le rend utile, mais cela signifie aussi que chaque ligne non pertinente alourdit chaque tâche future.
Anthropic recommande désormais de garder chaque fichier sous 200 lignes. En pratique, le vôtre peut généralement être beaucoup plus court.
Trois sections couvrent la plupart des projets :
ce qu'est ce projet :
le produit, l'architecture et les limites importantes
comment vérifier le travail :
les commandes pour la construction, le test, le lint et l'aperçu local
ce qu'il se trompe souvent :
les conventions spécifiques au projet et les erreurs récurrentes
Les procédures qui ne sont importantes que parfois appartiennent aux compétences. Les règles qui ne s'appliquent qu'à certains fichiers appartiennent aux règles limitées au chemin. Les notes historiques appartiennent à la documentation, pas à l'invite de chaque session.
Ouvrez votre CLAUDE.md ce soir et contestez chaque ligne : si la supprimer ne causerait pas une véritable erreur, supprimez-la.
Le fichier plus léger est généralement le plus fort.
secret 3 : abusez des objectifs et des boucles
C'est là que Fable cesse d'être une conversation et devient un processus qui peut continuer à avancer pendant que vous faites autre chose.
Objectifs : /goal donne à la session une condition d'achèvement testable. Après chaque tour, un petit modèle séparé vérifie si la condition est satisfaite. Si ce n'est pas le cas, Fable commence un autre tour au lieu de vous rendre la main. L'objectif se termine lorsqu'il réussit, devient impossible, atteint une erreur irrécupérable ou que vous l'annulez.
L'art consiste à écrire une ligne d'arrivée qu'il ne peut pas simuler :
exigez une preuve observable : "tous les tests d'authentification réussissent et la sortie est jointe" est plus fort que "réparer l'authentification"
définissez le chemin d'échec : si un véritable blocage rend l'objectif impossible, signalez le blocage et la preuve au lieu d'inventer des progrès
plafonnez les parties risquées : utilisez maxTurns pour les travailleurs, des limites de dépenses pour les services payants et des limites explicites autour des déploiements ou des données de production
gardez une règle d'honnêteté dans chaque briefing : chaque affirmation de progrès doit pointer vers un résultat produit ou inspecté lors de cette exécution
Exécutez les objectifs en mode automatique uniquement dans des limites que vous êtes à l'aise de laisser sans surveillance. Un agent plus intelligent a un rayon d'explosion plus large lorsque le briefing est erroné.
Boucles : /loop réexécute une invite à un intervalle. Utilisez /loop 15m pour vérifier le déploiement et enquêter sur toute défaillance à une cadence fixe, ou omettez l'intervalle et laissez Claude décider quand vérifier à nouveau.
Les boucles dans Claude Code sont limitées à la session et expirent éventuellement. Utilisez-les pour les constructions, les pull requests, les migrations et la surveillance temporaire. Utilisez une routine persistante ou une tâche planifiée du bureau pour le travail qui doit survivre après la fermeture de la session ou de la machine.
Entre les objectifs et les boucles, vous pouvez garder Fable au travail aussi longtemps que le travail en a vraiment besoin, avec des preuves qui vous attendent à la fin au lieu d'un autre paragraphe confiant.
comment réaliser un vrai projet en un seul coup
Assemblez maintenant le système entier autour d'une seule construction.
L'exemple est une page d'atterrissage avec une liste d'attente fonctionnelle. Remplacez le projet et la même séquence tient.
étape 1, rédigez le briefing
Envoyez un message :
Je lance [produit] pour [public]. Ils ont besoin d'une page d'atterrissage qui fait une promesse claire et capture
des emails. Construisez une page responsive avec un formulaire fonctionnel qui stocke les inscriptions. Contraintes : pas de framework que je dois surveiller, pas de dépendance payante, rapide sur mobile, et pas de déploiement avant que je l'approuve. Terminé signifie que la page s'exécute localement, qu'un e-mail test apparaît dans le stockage, que la mise en page mobile est vérifiée à 390 px et que le résultat est montré avec la sortie des tests et des captures d'écran. Inspectez d'abord le projet et planifiez. Déléguez uniquement les étapes indépendantes. Vérifiez chaque étape terminée.
Le briefing lui donne une destination sans concevoir l'implémentation à sa place.
étape 2, approuvez le plan
Entrez en mode plan avec /plan ou Shift+Tab avant qu'il ne modifie quoi que ce soit.
Si l'idée est sous-spécifiée, installez la collection de Matt Pocock avec /plugin install mattpocock-skills, exécutez /setup-matt-pocock-skills une fois et utilisez /grill-with-docs avant de transformer le résultat en spécification.
Lisez le plan. Supprimez les fonctionnalités dont vous n'avez pas besoin. Assurez-vous que chaque étape a une condition de réussite observable. Approuvez-le ensuite.
étape 3, laissez l'équipe travailler
Fable assigne la première étape isolée au travailleur d'implémentation. Le vérificateur inspecte le diff réel et la sortie des tests. Une étape dépendante ne commence qu'après la réussite de la précédente.
Vous pouvez quitter le terminal. Utilisez /tasks lorsque vous voulez voir ce qui est encore en cours d'exécution.
étape 4, définissez la ligne d'arrivée
Utilisez un objectif qui nomme l'état et la preuve :
/goal la page s'exécute localement, le formulaire stocke une inscription test et la mise en page fonctionne à 390 px, prouvé par la sortie réelle du test, l'enregistrement stocké et une capture d'écran actuelle. Si un véritable blocage rend cela impossible, arrêtez-vous et signalez la preuve au lieu de revendiquer le succès.
Cette condition est beaucoup plus difficile à satisfaire avec des mots seuls.
étape 5, examinez le résultat
Revenez au diff, à la sortie des tests, à l'inscription stockée et aux captures d'écran.
Examinez le produit comme un utilisateur, pas comme le manager du modèle. Demandez les modifications que vous pouvez réellement voir, exécutez un dernier passage de vérification indépendant et expédiez lorsque les preuves correspondent au briefing.
La première exécution semblera élaborée.
La deuxième fois, vous remarquerez que la même séquence fonctionne pour presque tous les projets que vous avez reportés.
les cinq workflows où il génère de l'argent réel
Maintenant, orientez la configuration vers un travail suffisamment précieux pour justifier le modèle.
Voici les cinq workflows où Fable 5.1 peut créer une différence mesurable.
Le travail sur la base de code que personne ne veut : la migration estimée à trois semaines, la rare défaillance de production, le problème de performance réparti sur huit services. Fable cartographie le système, les travailleurs prennent des tranches isolées, le vérificateur inspecte chaque étape et les progrès sont liés aux tests plutôt qu'à l'optimisme.
La recherche de qualité décisionnelle : une question entre, les travailleurs de recherche rassemblent à partir de sources primaires en parallèle, un réviseur sceptique attaque chaque affirmation importante et le leader transforme ce qui survit en note. Cela peut alimenter une acquisition, un lancement, une décision de marché ou une thèse d'investissement.
Les opérations commerciales : donnez-lui accès aux bons outils et laissez-le rapprocher les données, enquêter sur les anomalies, préparer des rapports, surveiller un processus ou travailler sur un backlog opérationnel. Fable 5.1 a presque doublé le score de Fable 5 sur AutomationBench d'Anthropic, qui est l'un des sauts pratiques les plus clairs de la version.
Le travail produit basé sur des références : donnez-lui des captures d'écran de l'expérience que vous voulez, les ressources réelles et l'accès à l'application en cours d'exécution. Il peut implémenter par rapport à la référence, ouvrir le résultat, comparer les deux et continuer jusqu'à ce que l'écart visible se referme. Vous fournissez le goût. Il fournit les yeux, les mains et la patience.
Un système de connaissances cumulatif : orientez-le vers tout ce qui vaut la peine d'être préservé dans votre entreprise et laissez-le transformer des documents dispersés en une source de vérité maintenue et liée. Un rédacteur peut en construire un à partir de grandes pages de vente, une agence à partir de ses études de cas et une entreprise SaaS à partir d'appels clients, de décisions, d'expériences et d'historique de support. Chaque futur agent commence plus intelligent parce que le contexte utile existe déjà.
Chacun de ces éléments était autrefois un projet pour un jour.
Fable 5.1 en fait des projets pour cette semaine, à condition que vous donniez au système une véritable ligne d'arrivée et un moyen de prouver qu'il l'a franchie.
toute la configuration en un seul bloc
exécutez Fable 5.1 en tant que leader : il planifie, délègue, examine et décide
utilisez Opus ou Sonnet pour le travail délimité, avec un travailleur par voie indépendante
donnez-lui le résultat, les contraintes, la raison et la preuve, puis laissez-le choisir l'itinéraire
gardez CLAUDE.md court et déplacez les procédures occasionnelles dans les compétences
utilisez les objectifs pour un achèvement vérifiable et les boucles pour des vérifications planifiées
contrôlez les coûts avec les niveaux d'effort, les travailleurs moins chers, le contexte mis en cache et des limites strictes
orientez le système vers les bases de code, la recherche, les opérations, le travail produit et les connaissances qui s'accumulent
Le modèle est la partie la plus visible de la configuration, mais ce n'est pas tout l'avantage.
L'avantage est de donner à un modèle aussi capable une destination claire, une équipe compétente, un accès à la réalité et aucun moyen de confondre une réponse convaincante avec un travail terminé.
