Maîtriser Fable 5

Les axes sur lesquels il excelle, et qu'il faut savoir solliciter :

• Autonomie longue durée — runs multi-jours, dirigés vers un but, avec une forte rétention des instructions.
• Justesse au premier essai sur des problèmes complexes et bien spécifiés (implémentations « one-shot » qui demandaient des jours d'itération).
• Vision — images techniques denses, captures, apps web ; utilise bash et un outil de recadrage pour gérer les images inclinées, floues ou bruitées.
• Workflows d'entreprise — suit les consignes, reste dans le périmètre, sort de l'analyse financière / tableurs / slides / documents de qualité pro.
• Revue de code & debug — rappel de bugs élevé (hors domaines cyber couverts par les garde-fous), recherche dans le code et l'historique du dépôt.
• Délégation — très fiable pour lancer et piloter des sous-agents parallèles.

Côté requête JSON, deux changements structurants : le thinking et l'effort.

L'effort est le levier n°1

Sur Fable 5, effort arbitre intelligence ↔ latence ↔ coût. La doc recommande :

Baissez l'effort si une tâche réussit mais traîne, ou si vous voulez un style plus interactif.

Le « thinking » adaptatif est toujours actif

L'ancien réflexe de désactiver le thinking ne s'applique plus : il est désormais adaptatif et permanent, restitué uniquement en résumé. Il n'y a plus de budget de thinking étendu à régler — on pilote la profondeur via effort. Si vous avez besoin de visibilité sur le raisonnement, lisez les blocs thinking structurés ; ne demandez pas au modèle de réécrire son raisonnement dans la réponse (voir §9, refus reasoning_extraction).

Les tours sont plus longs par défaut

À effort élevé, une requête sur tâche difficile peut tourner plusieurs minutes ; un run autonome, des heures. C'est l'un des plus gros ajustements à prévoir. Avant de migrer :

• Augmentez les timeouts client.
• Passez en streaming et soignez les indicateurs de progression.
• Restructurez le harnais pour vérifier les runs en asynchrone (jobs planifiés) plutôt qu'en bloquant.

Le suivi d'instructions est assez fort pour qu'une consigne brève pilote la plupart des comportements : inutile d'énumérer chaque cas un par un.

Non-steeré et à effort élevé, Fable a tendance à élaborer : survoler des options, expliquer longuement les causes racines, produire des descriptions de PR sur-structurées, commenter chaque ligne. Une seule consigne de concision suffit :

Définir les bornes (ce qu'il ne doit pas faire)

Fable peut parfois prendre des initiatives non demandées (rédiger un e-mail, créer des branches git « de sauvegarde »). Cadrez explicitement :

Fable 5 brille quand il peut noter les leçons d'un run et les relire. Pas besoin d'infra : un fichier Markdown fait l'affaire.

Pour amorcer la mémoire à partir de l'historique existant :

Le point le plus contre-intuitif du cours, et celui que la doc martèle.

La même logique vaut pour vos fichiers d'instruction projet de type CLAUDE.md (dans Claude Code) ou vos Skills : un empilement de règles pensées pour « tenir la main » d'un modèle plus faible devient du bruit. Fable 5 sait par ailleurs mettre à jour un skill à la volée selon ce qu'il apprend de la tâche.

Le piège à supprimer en priorité

Toute consigne qui demande au modèle d'écho / transcrire / expliquer son raisonnement interne dans le texte de réponse peut déclencher la catégorie de refus reasoning_extraction, et donc faire grimper les fallbacks vers le modèle de repli. Auditez vos system prompts, skills et CLAUDE.md pour retirer les « montre ton raisonnement / pense à voix haute dans la réponse ».

La doc ne « redéfinit » pas le RAG, mais les capacités de Fable 5 changent la stratégie. Voici les implications, dérivées des comportements documentés.

• Laissez-le récupérer lui-même. Sa rétention sur de longs contextes et sa capacité à fouiller un dépôt / un historique rendent souvent inutile un pré-découpage agressif. Donnez-lui les outils (recherche, lecture de fichiers, sous-agents) plutôt que de tout pré-mâcher.
• La mémoire complète le RAG. Le RAG apporte les faits du corpus à l'instant T ; le memory.md (§5) persiste les leçons entre runs. Les deux sont complémentaires, pas concurrents.
• RAG visuel. Fable lit nativement figures, tableaux et graphes imbriqués dans des PDF. Pour des corpus « document-lourds » (finance, juridique, archi), passez les pages en image plutôt que d'en extraire un texte appauvri.
• Sous-agents récupérateurs. Un sous-agent à contexte frais dédié à la recherche, dont le résultat est vérifié, surpasse l'auto-critique d'un agent unique saturé.

C'est là que Fable 5 prend le plus d'avance — et là où le harnais doit le plus évoluer.

Sous-agents parallèles, en asynchrone

Fable dispatche des sous-agents très volontiers. Préférez la communication asynchrone orchestrateur ↔ sous-agents au blocage. Les sous-agents longue durée qui gardent leur contexte économisent temps et coût via les lectures de cache.

Ancrer les rapports de progression

Sur les runs autonomes, demandez-lui d'auditer chaque affirmation contre un résultat d'outil réel. Dans les tests d'Anthropic, cela a quasi éliminé les rapports d'avancement inventés :

Un outil send_to_user (JSON)

Pour les agents longs et asynchrones, donnez-lui un moyen d'afficher un message exactement tel quel sans terminer son tour. Les inputs d'outil ne sont jamais résumés : le contenu arrive intact.

{
  "name": "send_to_user",
  "description": "Affiche un message directement à l'utilisateur.
     À utiliser pour les mises à jour de progression, résultats partiels,
     ou contenu que l'utilisateur doit voir tel quel avant la fin.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": { "type": "string",
                   "description": "Le contenu à afficher." }
    },
    "required": ["message"]
  }
}

Deux réflexes pour les sessions très longues

• Arrêt prématuré. Fable peut parfois finir un tour sur une intention (« je vais lancer X ») sans émettre l'appel d'outil. Un simple « continue » ou « fais-le de bout en bout » relance. Pour les pipelines autonomes, ajoutez un rappel « tu opères en autonomie, l'utilisateur ne répond pas en temps réel ».
• Inquiétude de budget de contexte. En session très longue, il peut proposer de résumer / repartir à neuf — souvent déclenché par un décompte de tokens affiché. Évitez d'afficher ce décompte ; sinon, rassurez : « tu as amplement de contexte, ne t'arrête pas et ne propose pas de nouvelle session ».

Fable performe mieux quand il comprend pourquoi — le contexte lui permet de relier la tâche aux bonnes informations plutôt que de deviner.

Enfin, en conversation agentique très longue (beaucoup d'appels d'outils), demandez-lui d'abandonner le jargon de travail dans son message final : phrases complètes, termes explicités, pas de chaînes à flèches. Son résumé final est souvent le premier regard de l'utilisateur sur tout le travail — il doit se lire comme une remise en contexte, pas comme la suite de son fil interne.

C'est la grande nouveauté opérationnelle de Fable 5. À traiter dès la conception, pas après.

À quoi ressemble un refus

Un refus n'est pas une erreur : c'est une réponse HTTP 200 avec stop_reason: "refusal". Branchez votre logique sur stop_reason, jamais sur stop_details ou content.

{
  "type": "message",
  "model": "claude-fable-5",
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "Décliné : pourrait faciliter un préjudice cyber."
  },
  "usage": { "input_tokens": 412, "output_tokens": 0 }
}

Facturation : un refus avant toute sortie n'est pas facturé (et ne compte pas contre les quotas). Un refus en milieu de flux facture l'entrée et la sortie déjà streamée.

Le fallback en une ligne (server-side, beta)

La config la plus simple : nommez le modèle de repli, l'API gère le retry dans un seul aller-retour.

// header beta exact requis : server-side-fallback-2026-06-01
await client.beta.messages.create({
  model: "claude-fable-5",
  max_tokens: 1024,
  messages,
  betas: ["server-side-fallback-2026-06-01"],
  fallbacks: [{ model: "claude-opus-4-8" }]
});

• Jusqu'à 3 modèles, essayés dans l'ordre ; chacun doit figurer dans allowed_fallback_models du modèle (Models API).
• Seul un refus de classificateur déclenche le fallback — un rate-limit / une surcharge / une erreur serveur vous est renvoyé tel quel.
• Indisponible sur Batches, Bedrock, Vertex AI, Foundry → utilisez le middleware SDK (TS, Python, Go, Java, C#), qui épingle aussi la conversation au modèle qui a accepté via BetaFallbackState.

À cocher avant de mettre Fable 5 en production.

Des recettes concrètes combinant les techniques ci-dessus.