L'API Claude pour les développeurs

L'API Messages

L'API Messages est le point d'entrée HTTP central qui permet à n'importe quel programme de communiquer avec Claude. Plutôt que d'ouvrir une fenêtre de chat, votre code envoie une requête JSON structurée et reçoit une réponse JSON structurée. JSON (JavaScript Object Notation) est un format texte standard pour l'échange de données.

Chaque requête doit inclure trois éléments : l'identifiant du modèle (quelle version de Claude utiliser), max_tokens (le nombre maximum de tokens, ou fragments de mots, que Claude peut générer dans la réponse), et un tableau messages (l'historique de la conversation sous forme de paires rôle/contenu).

Le SDK Anthropic (kit de développement logiciel) officiel pour Node.js enveloppe cet appel HTTP dans une simple fonction JavaScript. Installez-le avec npm, puis écrivez quelques lignes :

• Définissez votre clé API comme variable d'environnement sous le nom ANTHROPIC_API_KEY.
• Créez un client : const Anthropic = require("@anthropic-ai/sdk"); const client = new Anthropic();
• Appelez client.messages.create({ ... }) avec votre modèle, max_tokens et vos messages.
• Lisez la réponse depuis response.content[0].text.

Les identifiants de modèles pour juin 2026 sont claude-opus-4-8 (le plus puissant), claude-sonnet-4-6 (équilibre) et claude-haiku-4-5 (le plus rapide). Commencez par Haiku pendant l'apprentissage : il est peu coûteux et instantané.

System, user, assistant via l'API

Chaque appel à l'API Claude est construit à partir d'une séquence de messages, chacun porte un rôle. Les trois rôles sont system, user et assistant. Le rôle system est un paramètre spécial de premier niveau (pas dans le tableau messages) qui définit des instructions persistantes pour toute la conversation. Pensez-y comme au briefing que vous donnez à Claude avant que la conversation commence.

Le tableau messages alterne ensuite entre user (le tour humain) et assistant (la réponse de Claude). Vous pouvez pré-remplir ce tableau avec des tours passés pour simuler une conversation multi-tours, ou injecter un début de tour assistant pour guider le tout premier mot de la réponse.

Pourquoi l'ordre des rôles est-il important ? Claude est entraîné à respecter la hiérarchie : les instructions system ont le poids le plus élevé, puis vient l'historique de la conversation. Si un message user contredit le system prompt, Claude suit le system prompt. Cela fait du paramètre system l'endroit idéal pour les règles, les personas, les formats de sortie et les garde-fous de sécurité.

• system : chaîne de caractères de premier niveau, définie une fois par requête, jamais affichée comme bulle de message.
• user : un tour humain, obligatoire au moins une fois en tant que dernier message.
• assistant : les réponses précédentes de Claude, ou une chaîne de pré-remplissage pour contraindre la prochaine réponse.
• Les messages doivent alterner user/assistant ; deux tours user consécutifs sont rejetés par l'API.

Utilisation des outils via l'API

L'API Claude vous permet de fournir au modèle une liste d'outils (aussi appelés définitions de fonctions) qu'il peut invoquer. Chaque outil est un objet JSON décrivant un nom, une description et un schéma d'entrée (un objet JSON Schema qui indique à Claude quels paramètres l'outil accepte). Claude n'exécute jamais l'outil lui-même ; il renvoie un bloc structuré tool_use que votre code doit traiter.

Un cycle typique fonctionne ainsi :

1. Vous envoyez une requête messages qui inclut un tableau tools.
2. Si Claude décide d'appeler un outil, le stop_reason de la réponse est "tool_use" et le contenu contient un bloc tool_use avec un id, le name de l'outil et l'objet input.
3. Votre code exécute l'action réelle (requête en base de données, appel API, calcul), puis ajoute un bloc tool_result à la conversation en utilisant le même tool_use_id.
4. Vous renvoyez la conversation mise à jour à Claude, qui lit le résultat et produit sa réponse finale.

Deux choix de conception clés affectent la fiabilité. Premièrement, rédigez la description de l'outil comme si vous expliquiez la fonction à un collègue débutant : Claude s'en sert pour décider si et quand appeler l'outil. Deuxièmement, rendez votre schéma d'entrée strict : marquez les champs obligatoires, utilisez enum quand les valeurs sont fixes, et évitez les champs string vagues quand un nombre ou un booléen est plus adapté. Des schémas vagues produisent des entrées vagues.

Quand vous souhaitez que Claude appelle exactement un outil précis, définissez tool_choice à {"type": "tool", "name": "your_tool_name"}. La valeur par défaut "auto" laisse Claude décider. Utilisez "any" pour forcer au moins un appel d'outil sans préciser lequel.

Réponses en streaming

Par défaut, l'API Anthropic attend que le modèle ait terminé de générer avant d'envoyer quoi que ce soit. Le streaming change cela : l'API envoie chaque token (un fragment de mot, environ 3 à 4 caractères) à votre client au moment où il est produit, de sorte que l'utilisateur voit le texte apparaître mot par mot au lieu d'attendre la réponse complète.

Le streaming utilise le protocole Server-Sent Events (SSE). Le serveur maintient la connexion HTTP ouverte et pousse de petits blocs d'événements. Chaque bloc contient un delta, c'est-à-dire le nouvel incrément de texte à ajouter. Votre client accumule les deltas pour reconstituer le message complet.

Pour activer le streaming avec le SDK Python ou Node d'Anthropic, passez stream=True (Python) ou utilisez la méthode .stream() (Node). Le SDK expose un itérateur asynchrone afin de traiter un bloc à la fois sans tout mettre en mémoire tampon. Cela compte pour les longues réponses : une réponse de 4000 tokens peut commencer à s'afficher en moins d'une seconde au lieu d'attendre plusieurs secondes.

• stream=True (Python) : retourne un gestionnaire de contexte ; itérez text_stream pour obtenir les fragments de texte bruts.
• .stream() (Node/TS) : retourne un itérable asynchrone ; utilisez for await pour consommer les blocs.
• Types d'événements : message_start, content_block_delta, message_delta, message_stop.
• Les statistiques d'utilisation arrivent dans le dernier événement message_stop, pas au début.

Mise en cache des prompts via l'API

Chaque appel API retraite l'intégralité des tokens envoyés. Le prompt caching vous permet de marquer les sections stables de votre requête afin qu'Anthropic stocke une version compilée sur ses serveurs. Les appels suivants qui atteignent le même préfixe évitent le retraitement et bénéficient d'un tarif bien plus bas : environ 10 % du coût d'entrée normal pour un cache hit, contre 125 % pour l'écriture initiale qui alimente le cache.

Vous marquez une limite mise en cache en ajoutant "cache_control": {"type": "breakpoint"} dans un bloc de contenu. Claude lit votre prompt de haut en bas et met en cache tout ce qui précède ce marqueur. Vous pouvez placer jusqu'à quatre points de rupture par requête. Le schéma le plus courant consiste à placer un point de rupture après un long prompt système ou un document volumineux réutilisé dans de nombreux appels.

Quelques règles déterminent si le cache est effectivement utilisé :

• Le préfixe doit comporter au moins 1024 tokens (environ 750 mots) pour être éligible à la mise en cache.
• Les entrées du cache expirent après cinq minutes d'inactivité ; chaque hit remet le compteur à zéro.
• Le modèle, la version et l'ensemble du contenu situé avant le point de rupture doivent être octet pour octet identiques entre les appels.
• Modèles pris en charge (juin 2026) : claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5.

La réponse de l'API inclut un objet usage avec les champs cache_creation_input_tokens et cache_read_input_tokens, ce qui vous permet de vérifier les hits et de mesurer les économies en temps réel.

L'API Batch

L'API Batch vous permet de soumettre jusqu'à 10 000 requêtes en un seul appel et de récupérer tous les résultats de manière asynchrone (c'est-à-dire que vous n'attendez pas de réponse en direct : vous revenez consulter les résultats plus tard). En échange de cette souplesse, Anthropic applique une remise de 50 % par token par rapport à l'API temps réel standard.

Vous envoyez un fichier JSON contenant une liste de requêtes, chacune dotée d'un custom_id unique afin de faire correspondre les résultats aux entrées. Claude les traite en arrière-plan, en quelques minutes en général pour des centaines de requêtes, bien que le SLA (Service Level Agreement, la garantie officielle de délai) autorise jusqu'à 24 heures.

L'API Batch possède sa propre limite de débit indépendante, séparée de l'API temps réel. Cela signifie qu'un travail batch intensif n'empiète pas sur votre quota interactif. Elle est idéale pour toute tâche hors ligne : génération de jeux de données, évaluations, traduction de grands catalogues ou classification de milliers d'enregistrements.

• Modèles supportés : claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5
• Nombre maximum de requêtes par batch : 10 000
• Remise : 50 % sur les tokens en entrée et en sortie par rapport au tarif temps réel
• Format des résultats : une ligne JSONL par requête, associée par custom_id
• Annulation : vous pouvez annuler un batch en cours d'exécution avec un seul appel API

Compter les tokens

Avant d'envoyer une requête à Claude, vous pouvez demander à l'API de compter exactement combien de tokens (les morceaux de texte que le modèle lit et écrit) cette requête consommera. On utilise pour cela le point de terminaison de comptage de tokens : POST /v1/messages/count_tokens. Il accepte le même corps qu'une requête de messages normale, mais ne renvoie qu'un comptage, jamais une réponse, et ne coûte rien.

Les comptes de tokens sont importants pour deux raisons. Premièrement, chaque modèle possède une fenêtre de contexte (le nombre maximum de tokens qu'il peut traiter en une seule fois) : 200 000 pour Opus et Sonnet, 200 000 pour Haiku. Deuxièmement, la facturation se fait par token en entrée et en sortie, donc envoyer trop de tokens est un gaspillage d'argent, et en envoyer trop peu risque de tronquer votre prompt. Le comptage vous permet de rester sous la limite et d'estimer le coût avant de valider.

Ce que vous pouvez compter avant d'envoyer :

• Le prompt système seul, pour en comprendre le coût fixe.
• Les définitions d'outils, qui surprennent souvent les développeurs par leur taille.
• L'historique de conversation, pour décider quand résumer ou supprimer les anciens tours.
• Les fichiers envoyés ou les longs documents, pour vérifier qu'ils tiennent dans la fenêtre.

Pour le budget de tokens, définissez un plafond souple dans votre code : si input_tokens retourné par le point de terminaison de comptage dépasse, par exemple, 150 000, tronquez ou résumez avant d'envoyer. Vous pouvez aussi combiner le comptage avec le paramètre max_tokens (qui limite la longueur de la sortie) pour contrôler précisément la dépense totale par appel.

Identifiants de modèle, tarification et migration

Chaque modèle Claude possède un identifiant de modèle, la chaîne exacte que vous passez à l'API pour demander une version spécifique. En juin 2026, les trois identifiants actuels sont claude-opus-4-8 (le plus capable, le plus coûteux), claude-sonnet-4-6 (équilibre entre performance et coût) et claude-haiku-4-5 (le plus rapide, le moins coûteux). Utilisez toujours l'identifiant complet avec numéro de version dans le code de production, jamais un alias comme "claude-opus" sans suffixe de version, car Anthropic peut silencieusement rediriger les alias vers des modèles plus récents et modifier vos coûts ou comportements.

Choisir le bon modèle est un arbitrage coût-performance. Une règle pratique :

• Opus (claude-opus-4-8) : décisions d'architecture, raisonnement complexe, analyse de longs documents, boucles agentiques où la qualité prime.
• Sonnet (claude-sonnet-4-6) : tâches de codage courantes, résumé, rédaction, workflows multi-étapes où vitesse et coût comptent.
• Haiku (claude-haiku-4-5) : classification, routage, recherches rapides, traitements par lots à fort volume où la latence est critique.

La migration consiste à remplacer un ancien identifiant de modèle par un plus récent dans votre base de code. La méthode sûre est la suivante : mettez à jour la chaîne d'identifiant, exécutez votre suite d'évaluation ou de tests existante sur le nouveau modèle, comparez les sorties sur un échantillon de vraies invites, puis déployez. Comme les modèles plus récents peuvent refuser différemment ou formater les sorties autrement, ne migrez jamais sans étape de comparaison. Anthropic publie un guide de migration pour chaque génération ; consultez-le pour identifier les changements cassants dans les formats d'appel d'outils ou les tailles de fenêtre de contexte avant de basculer.

La tarification est par token (un token correspond à environ quatre caractères de texte en anglais). Vous payez séparément les tokens d'entrée (ce que vous envoyez) et les tokens de sortie (ce que le modèle retourne). Les tokens de sortie coûtent plus cher. Utilisez le prompt caching pour réutiliser un grand prompt système entre les appels et réduire les coûts d'entrée jusqu'à 90 % sur la portion mise en cache. L'API Batch d'Anthropic offre 50 % de réduction sur les tokens d'entrée et de sortie, au prix d'une latence plus élevée, idéale pour la génération de jeux de données hors ligne.

Mise à jour, juillet 2026 : la gamme actuelle est Fable 5 (claude-fable-5, 10/50 dollars par million de tokens), Opus 4.8 (claude-opus-4-8, 5/25), Sonnet 5 (claude-sonnet-5, 3/15, tarif de lancement 2/10 jusqu'au 31 août 2026) et Haiku 4.5 (claude-haiku-4-5-20251001, 1/5). Opus 4.1 part à la retraite le 5 août 2026 ; Opus 4.7/4.6/4.5 et Sonnet 4.6/4.5 sont en legacy. Depuis la génération 4.6, les ids de modèles sans date sont des instantanés figés, pas des pointeurs évolutifs. Deux leçons en fin de module couvrent les ruptures de Sonnet 5 et le contrat de refus de Fable 5.

Entrées vision et PDF

L'API Claude accepte bien plus que du texte. Vous pouvez envoyer des images et des fichiers PDF directement dans le tableau messages, en complément ou à la place d'un prompt textuel. Le modèle lit le contenu visuel et raisonne dessus exactement comme il le ferait avec des mots écrits. Cette capacité s'appelle l'entrée multimodale (multi-format, pas uniquement texte).

Les images sont transmises sous forme de chaînes encodées en base64 (une façon de représenter des données binaires sous forme de texte ASCII pur) dans un bloc content avec "type": "image". Vous précisez le type de média, par exemple image/jpeg, image/png, image/gif ou image/webp. Vous pouvez aussi passer une URL publique en utilisant "type": "image" avec une source "url" à la place du base64.

Les PDF utilisent "type": "document" avec "media_type": "application/pdf" et le contenu du fichier en base64. Claude lit la couche texte complète du PDF et, lorsque les pages contiennent des diagrammes ou des graphiques, il les interprète également visuellement. Les PDF sont limités à 100 pages et environ 32 Mo par fichier.

• Formats d'image acceptés : JPEG, PNG, GIF, WebP.
• Taille maximale par image par requête : 20 Mo (le poids encodé en base64 est environ 33 % supérieur au fichier brut).
• Jusqu'à 20 images par requête sur les modèles actuels.
• PDF : 100 pages maximum, 32 Mo brut. Contenu textuel et visuel analysés.
• La vision est disponible sur claude-opus-4-8, claude-sonnet-4-6 et claude-haiku-4-5.

Sonnet 5 sur l'API : ce qui casse, ce qui gagne

Le 30 juin 2026, Anthropic a lancé claude-sonnet-5, remplaçant Sonnet 4.6 comme modèle de milieu de gamme dans la famille Claude. C'est aussi le nouveau modèle par défaut sur les plans Free et Pro de claude.ai, et dans Claude Code depuis la version 2.1.197. Si vous développez sur l'API, c'est le modèle sur lequel tournera la majorité de votre trafic de production, à moins de fixer volontairement une version plus ancienne.

Les spécifications marquent un vrai bond en avant. Sonnet 5 embarque une fenêtre de contexte de 1 million de tokens (environ un million de tokens combinant entrée et historique de conversation) comme seule taille proposée, sans variante plus petite au choix. La sortie maximale par requête est de 128 000 tokens (le paramètre max_tokens, qui plafonne la quantité de texte qu'une seule réponse peut générer). Sa date de coupure des connaissances (la date au-delà de laquelle il n'a aucune donnée d'entraînement sur le monde) est janvier 2026. Anthropic le décrit comme le Sonnet le plus agentique à ce jour, c'est-à-dire qu'il planifie et exécute des tâches multi-étapes utilisant des outils avec moins d'accompagnement, et il approche désormais la qualité d'Opus 4.8 sur de nombreux benchmarks de code et d'agentivité, pour un prix bien plus bas.

La tarification pendant la période de lancement, qui court jusqu'au 31 août 2026, est de 2 $ par million de tokens (MTok) en entrée et 10 $ par MTok en sortie. Après cette date, elle revient au tarif standard du palier Sonnet, soit 3 $ en entrée / 15 $ en sortie par MTok. Si vous budgétez le coût d'un projet qui chevauche cette date, prévoyez le tarif le plus élevé pour tout ce qui tourne après le 1er septembre 2026.

Trois changements vont casser le code API existant écrit pour Sonnet 4.6 ou des modèles antérieurs, à traiter donc comme une checklist avant de basculer la chaîne de modèle. Premièrement, le raisonnement adaptatif est activé par défaut : contrairement à Opus 4.7 et 4.8, où omettre le paramètre thinking fait tourner le modèle sans raisonnement, sur Sonnet 5 le simple fait de ne pas définir thinking déclenche quand même le raisonnement adaptatif (le modèle décidant lui-même quand et combien raisonner avant de répondre). Deuxièmement, le raisonnement étendu manuel est supprimé : envoyer thinking: {type: "enabled", budget_tokens: N}, l'ancienne façon de donner au modèle un budget fixe de tokens de raisonnement, renvoie désormais une erreur 400 (une réponse de requête rejetée) au lieu d'être acceptée silencieusement ou dépréciée. Troisièmement, les paramètres d'échantillonnage non par défaut sont rejetés : régler temperature, top_p ou top_k sur autre chose que leur valeur par défaut renvoie une erreur 400. Ces réglages d'échantillonnage, qui permettaient auparavant d'ajuster l'aléatoire de la sortie du modèle, ont complètement disparu sur les modèles de classe Sonnet depuis cette version.

Il y a aussi un changement plus discret mais coûteux : le tokenizer (l'algorithme qui découpe le texte en unités que le modèle compte et facture réellement). Le tokenizer de Sonnet 5 découpe le même texte d'entrée en environ 30 % de tokens en plus que le tokenizer de Sonnet 4.6. Cela signifie qu'un prompt qui vous coûtait 10 000 tokens sur Sonnet 4.6 pourrait vous en coûter environ 13 000 sur Sonnet 5, alors même que rien n'a changé dans le texte. Toute estimation de coût, tout budget de fenêtre de contexte ou calcul de limite de débit construit pour Sonnet 4.6 doit être recalculé pour Sonnet 5 plutôt que réutilisé.

Parallèlement au lancement, Anthropic a resserré la gamme de modèles. Opus 4.1 est déprécié et sera retiré le 5 août 2026, donc tout code ciblant encore ce modèle a besoin d'un plan de migration avant cette date. Opus 4.7, Opus 4.6, Opus 4.5, Sonnet 4.6 et Sonnet 4.5 sont désormais considérés comme legacy, c'est-à-dire qu'ils restent appelables mais ne sont plus le choix recommandé pour de nouveaux développements. Un détail de nommage à connaître : depuis la génération de modèles 4.6, un identifiant de modèle sans date (un nom comme claude-sonnet-5 sans suffixe de date) est un instantané figé, et non un pointeur évolutif qui se met à jour silencieusement vers un modèle plus récent au fil du temps. Cet identifiant continuera de renvoyer indéfiniment la même version du modèle, ce qui est bon pour la reproductibilité mais implique de changer vous-même activement la chaîne pour récupérer une future version.

Pour migrer du code existant vers Sonnet 5, suivez cette checklist dans l'ordre. Remplacez l'identifiant de modèle par la chaîne claude-sonnet-5. Supprimez tout paramètre temperature, top_p, top_k et budget_tokens de vos charges utiles de requête, puisque tous provoquent désormais des erreurs. Recalculez vos comptages de tokens en utilisant le point de terminaison de comptage de tokens de l'API sur des prompts réels, car le décalage de 30 % du tokenizer invalide toutes vos anciennes estimations. Retarifez votre charge de travail en utilisant le nouveau tarif de lancement à 2 $/10 $ (ou 3 $/15 $ après le 31 août 2026) plutôt qu'en réutilisant vos anciens chiffres de coût Sonnet 4.6. Enfin, retestez vos garde-fous, c'est-à-dire tout filtre de contenu, vérification de longueur de sortie ou logique de sécurité que vous aviez calibrés sur le comportement de l'ancien modèle, car un modèle plus agentique et au découpage de tokens différent peut faire glisser les schémas de réponse au point d'échapper à des contrôles calibrés sur la version précédente.

Refus, solutions de repli et le contrat Fable 5

Claude Fable 5 est sorti le 9 juin 2026 et a de nouveau été mis à jour lors du redéploiement du 1er juillet 2026. Cela a changé la façon dont l'API Claude gère les refus de sécurité. Quand l'un des classificateurs de sécurité à double usage de Fable 5 (des filtres automatisés qui vérifient une requête par rapport à des catégories de politique comme le risque cyber ou biologique, avant ou pendant la génération) se déclenche, l'API ne renvoie pas de code d'erreur. Elle renvoie un HTTP 200 normal avec stop_reason réglé sur "refusal", et elle indique quel classificateur s'est déclenché. C'est important pour la facturation : une requête refusée avant qu'aucun résultat n'ait été produit n'est pas facturée du tout. Si le refus survient en cours de flux, après que certains tokens ont déjà été générés, ces tokens diffusés sont facturés normalement. Un développeur qui ne vérifie que les codes d'erreur HTTP manquera chacun de ces événements, car la requête a techniquement réussi.

Une fois un refus survenu, vous disposez de trois chemins de nouvelle tentative, et Anthropic recommande de les essayer dans l'ordre. Le premier chemin, celui à privilégier, est le paramètre fallbacks, une fonctionnalité bêta sur l'API Claude et sur Claude Platform on AWS (l'offre propre d'Anthropic hébergée sur AWS, distincte d'Amazon Bedrock). Vous déclarez un ou plusieurs modèles de repli dans la requête, et si le modèle principal refuse, la plateforme retente automatiquement la requête sur le modèle de repli pour vous, dans le même appel. Pas d'aller-retour supplémentaire, pas de logique côté client. Le deuxième chemin est le middleware SDK, disponible pour TypeScript, Python, Go, Java et C#. Il s'agit de code côté client qui intercepte un refus et réémet lui-même la requête, utile quand le paramètre côté serveur n'est pas disponible sur votre cible de déploiement. Le troisième chemin est la gestion manuelle dans votre propre code : intercepter le refus, décider quoi faire, et rappeler l'API vous-même. Chaque chemin échange de la commodité contre du contrôle, et vous devriez privilégier le premier par défaut, sauf raison précise de ne pas le faire.

Un détail qui élimine une objection courante à la nouvelle tentative : il existe un crédit de repli (fallback credit). Quand vous passez d'un modèle à un autre en cours de conversation, vous perdez normalement votre cache de prompt (la réutilisation à tarif réduit d'un préfixe de prompt déjà traité) et payez plein tarif pour le reconstruire sur le nouveau modèle. Avec le crédit de repli, le coût de ce changement de cache est remboursé lorsque le repli est déclenché par un refus. Cela signifie qu'opter pour les solutions de repli est proche de la gratuité du point de vue du coût, ce qui explique pourquoi Anthropic recommande de le traiter comme un défaut plutôt que comme une option à activer qu'il faudrait justifier.

Le raisonnement sur Fable 5 fonctionne différemment des modèles Claude précédents. Le raisonnement adaptatif est le seul mode : Fable 5 décide lui-même quand et combien raisonner avant de répondre, et vous ne pouvez pas passer de paramètre pour désactiver entièrement le raisonnement. C'est un changement par rapport aux anciennes configurations de raisonnement étendu où un développeur fixait un budget de tokens fixe pour le raisonnement. Second changement : la chaîne de raisonnement brute n'est jamais renvoyée à l'appelant, quels que soient les réglages. Ce que vous pouvez contrôler, c'est thinking.display, qui prend deux valeurs : "summarized" vous donne une version lisible et raccourcie du raisonnement, et "omitted" (la valeur par défaut) ne vous donne rien. Si votre produit affiche aux utilisateurs une vue en direct du processus de raisonnement de Claude, vous devez explicitement demander "summarized", sinon le champ sera simplement vide.

La gestion des données sur Fable 5 comporte une contrainte que les développeurs sensibles à la conformité doivent signaler tôt. Fable 5, ainsi que son modèle jumeau Mythos 5, est classé comme Covered Model (modèle couvert), ce qui s'accompagne d'une rétention des données obligatoire de 30 jours et, surtout, d'aucune option de rétention zéro (ZDR, zero-data-retention). Les organisations qui exigent la ZDR pour des raisons réglementaires ou contractuelles (finance, santé, travail gouvernemental) ne peuvent actuellement pas déployer Fable 5 dans ce mode. Ce n'est pas un réglage que vous pouvez basculer ; c'est une propriété du modèle à ce stade de son déploiement. Quiconque conçoit une intégration Fable 5 pour un client régulé devrait signaler cette contrainte avant d'écrire la moindre ligne de code d'intégration, pas après.

Côté fonctionnalités, Fable 5 prend en charge un ensemble assez complet de capacités d'API dès son lancement : le paramètre effort (contrôle l'effort de calcul que le modèle consacre à une tâche), les budgets de tâche (une fonctionnalité bêta pour plafonner les dépenses sur les longues exécutions agentiques), l'outil de mémoire (permet à Claude de conserver des notes entre les sessions), l'exécution de code, l'appel d'outils programmatique (Claude écrit du code qui appelle directement vos outils au lieu de passer par un aller-retour complet à chaque fois), l'édition de contexte, la compaction (résumer les anciens tours de conversation pour économiser de l'espace de contexte), et la vision. La tarification est de 10 dollars par million de tokens en entrée et 50 dollars par million de tokens en sortie, ce qui constitue un palier premium par rapport aux modèles Claude précédents ; les développeurs devraient donc évaluer si une tâche a réellement besoin de la profondeur de raisonnement de Fable 5 ou si elle fonctionnerait de façon acceptable sur un modèle moins coûteux.

Le schéma défensif à intégrer dans chaque intégration Fable 5 : toujours faire une distinction explicite sur stop_reason plutôt que de supposer que content est renseigné. Vérifiez "end_turn" (achèvement normal), "max_tokens" (le résultat a été coupé car il a atteint la limite de longueur), et "refusal" (un classificateur a bloqué la requête) comme des cas distincts, chacun nécessitant un traitement différent. Journalisez le nom du classificateur chaque fois qu'un refus survient, car c'est votre piste d'audit si un client se plaint que sa requête légitime a été bloquée. Enfin, décidez au cas par cas si un repli vers Opus 4.8 est un résultat acceptable à servir silencieusement à l'utilisateur, ou si la requête devrait plutôt faire apparaître une erreur visible pour qu'un humain puisse l'examiner. Un outil de conformité financière et un chatbot grand public devraient probablement faire des choix opposés sur ce point.