Claude Fable 5 & Mythos API : Changements, ce qui fonctionne encore (et comment le tester)

Anthropic a lancé ses gammes de modèles Fable et Mythos avec un ensemble de règles différent de celui auquel les développeurs étaient habitués, et la réaction fut bruyante. Deux sujets ont dominé la discussion : une nouvelle exigence de conservation des données de 30 jours pour le trafic Fable et Mythos, et une série de modifications des garde-fous qui ont été mises en œuvre sans grand avertissement. Si vous utilisez l'API Claude en production, ces changements vous affectent directement.

Cet article sépare le bruit des éléments qui affectent votre code. Vous verrez ce qui aurait changé, ce qui fonctionne toujours de la même manière que la semaine dernière, et comment vérifier votre propre intégration avec Apidog au lieu de deviner. Si vous maintenez une intégration Claude, la démarche la plus sûre est de tester vos hypothèses, pas de leur faire confiance.

bouton

Ce qui a réellement changé

Trois choses sont confondues dans la discussion. Séparez-les et l'image devient plus claire.

Conservation des données. Le changement majeur est une fenêtre de conservation de 30 jours appliquée aux requêtes Fable et Mythos. En pratique, cela signifie que les données de requête et de réponse liées à ces modèles sont conservées pendant une période fixe plutôt que supprimées immédiatement. Les équipes ayant des engagements stricts en matière de traitement des données s'en soucient car cela modifie ce que vous pouvez promettre à vos propres utilisateurs. Si votre politique de confidentialité stipule « nous ne conservons pas les invites », le comportement de conservation de votre fournisseur en amont fait désormais partie de cette déclaration.

Garde-fous. Un sujet distinct a couvert les changements de garde-fous sur Fable sur lesquels certains chercheurs en sécurité ont émis des réserves. La plainte n'était pas que des garde-fous existent ; c'était que le comportement a changé silencieusement, de sorte que les réponses qui passaient hier pourraient être filtrées ou remodelées aujourd'hui. Pour une application qui dépend d'une sortie cohérente, un changement silencieux dans le comportement de refus est une véritable source de bugs.

Accès programmatique. C'est la partie sur laquelle la plupart des développeurs doivent réellement agir. La surface de l'API, le modèle d'authentification et la forme de la requête principale n'ont pas été remplacés. Vos clés existantes, vos appels `messages` et votre schéma d'utilisation d'outils fonctionnent toujours. Ce qui peut changer en dessous de vous, c'est le comportement : quelles invites sont refusées, combien de temps les appels prennent sous charge, et à quoi ressemble une réponse en streaming lorsqu'un garde-fou se déclenche en cours de génération.

En bref : le contrat est stable, le comportement n'est pas garanti stable, et la politique concernant vos données est plus stricte. Cette combinaison est exactement ce à quoi servent les tests.

Ce qui fonctionne toujours

Avant de tout réécrire, confirmez ce qui est inchangé pour ne pas résoudre des problèmes que vous n'avez pas.

• Authentification. Les clés API et l'en-tête `x-api-key` fonctionnent comme avant. Vous n'avez pas besoin de faire pivoter les clés à cause de ces changements, bien que la rotation des clés soit une bonne pratique quoi qu'il en soit. Consultez la référence API d'Anthropic pour le contrat d'en-tête actuel.
• La forme de l'API Messages. Le corps de la requête, le champ `model`, `max_tokens`, les invites `system` et le tableau `messages` sont inchangés. Le code écrit pour l'API Messages continue de fonctionner.
• Utilisation d'outils. Vos définitions d'outils et l'aller-retour `tool_use` / `tool_result` se comportent de la même manière. Si vous avez construit un agent basé sur l'appel de fonctions, le câblage reste valide.
• Streaming. Les événements envoyés par le serveur continuent de diffuser les jetons de la même manière. Ce qui peut différer, c'est le contenu du flux lorsqu'un garde-fou intervient en cours de route.
• Alias de modèle. Si vous épinglez un modèle par son ID complet plutôt que par un alias flottant, vous contrôlez exactement quel modèle répond. L'épinglage est votre meilleure défense contre la dérive comportementale silencieuse.

Donc, rien n'exige une réécriture d'urgence. Le travail est la vérification : prouvez que le comportement dont dépend votre application est toujours valide, et détectez les cas où il ne l'est plus discrètement.

Comment tester votre intégration avec Apidog

C'est là qu'un vrai client API prend toute sa place. Vous pouvez lire les journaux de modifications toute la journée, mais la seule façon de savoir comment votre intégration répond est de lancer des requêtes et d'inspecter ce qui revient. Apidog vous offre un espace de travail pour concevoir ces requêtes, les sauvegarder, simuler le fournisseur en amont et les exécuter comme des vérifications automatisées. Si vous avez abandonné Postman ou si vous n'avez jamais standardisé, c'est un bon point de départ ; voici l'argument plus large pour le test d'API sans Postman.

1. Capturez une référence fiable connue

Créez une requête dans Apidog qui atteint l'API Messages avec une invite qui vous intéresse ; une invite de production représentative, pas un jouet. Épinglez l'ID complet du modèle. Enregistrez la réponse. C'est votre référence. Lorsque le comportement dérive plus tard, vous comparez avec cette réponse enregistrée au lieu de vous fier à votre mémoire.

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

{
  "model": "claude-fable-5",
  "max_tokens": 1024,
  "messages": [
    { "role": "user", "content": "Summarize this support ticket and label its priority: ..." }
  ]
}

Stockez la clé API comme variable d'environnement dans Apidog plutôt que de la coder en dur. Cela permet de garder la clé hors de vos requêtes enregistrées et vous permet de basculer entre les environnements de staging et de production avec un seul menu déroulant. Le même modèle fonctionne que vous testiez Claude, le SDK de Claude Code, ou tout autre modèle derrière la même clé.

2. Affirmez sur la réponse, ne l'inspectez pas visuellement

Une référence n'est utile que si vous la vérifiez automatiquement. Dans Apidog, ajoutez des assertions à la requête :

• Le statut est `200`.
• `stop_reason` est `end_turn`, pas `max_tokens` ou un refus.
• Le corps de la réponse contient le champ structuré que votre application analyse (par exemple, une étiquette de priorité).
• Le temps de réponse reste en dessous de votre budget de délai d'attente.

Vous avez maintenant un test, pas une capture d'écran. Exécutez-le selon un calendrier et vous découvrirez le jour où un changement de garde-fou commence à filtrer une invite qui passait auparavant. C'est la même discipline qui sous-tend le test de contrat d'API ; vous épinglez le comportement que votre code en aval suppose.

3. Testez délibérément les chemins de refus et de garde-fous

Les plaintes concernant les garde-fous sont importantes car les refus sont faciles à ignorer jusqu'à ce qu'ils interrompent un flux de travail. Créez un petit ensemble de requêtes qui se situent près de vos limites de contenu et enregistrez les réponses. Si une invite précédemment acceptée commence à être refusée ou remodelée, votre assertion échoue et vous le savez avant vos utilisateurs. Traitez le comportement de refus comme un contrat testé, et non comme une considération après coup.

4. Simulez Anthropic pour que vos propres tests ne dépendent pas de l'API en direct

Vous ne voulez pas que votre suite CI appelle un fournisseur en amont payant, limité en débit et au comportement changeant à chaque exécution. Le serveur de simulation d'Apidog vous permet de mettre en place un faux point de terminaison Messages qui renvoie des réponses préenregistrées ; y compris les formes de refus et d'erreur que vous avez capturées ci-dessus. Dirigez votre application vers le simulacre pendant le développement et les tests d'intégration. Votre code exerce la vraie structure de réponse sans dépenser de jetons ni déclencher de limites de débit. Lorsque vous voulez la vraie chose, rétablissez l'URL de base. Vous construisez un agent basé sur cela ? Le même modèle de simulation est l'épine dorsale d'une bonne configuration de test d'agent IA.

5. Vérifiez le comportement sensible à la conservation

Si la fenêtre de conservation de 30 jours est importante pour votre récit de conformité, documentez-le là où votre équipe le verra et testez les contrôles dont vous disposez. Confirmez quels points de terminaison vous appelez, quelles données quittent votre système dans chaque requête, et si vous envoyez plus que nécessaire. L'historique des requêtes d'Apidog facilite l'audit des charges utiles exactes que votre intégration envoie, afin que vous puissiez supprimer tout élément sensible qui n'a pas besoin d'être dans l'invite. Vous ne pouvez pas modifier la politique de conservation d'Anthropic, mais vous pouvez contrôler ce que vous lui donnez.

6. Testez sous charge et avec des délais d'attente

Le comportement sous charge est l'endroit où les changements silencieux se cachent. Utilisez Apidog pour exécuter la même requête à plusieurs reprises et surveiller l'augmentation de la latence, les flux partiels ou les déclenchements intermittents des garde-fous. Définissez un délai d'attente réaliste et une politique de réessai dans votre client, puis testez si votre réessai gère réellement une réponse lente ou tronquée au lieu d'aggraver le problème. Si vous constatez une lenteur en amont, l'approche de débogage pour résoudre les délais d'attente de requête en amont s'applique directement.

Une liste de contrôle pratique

Parcourez ceci une fois et vous saurez exactement où vous en êtes :

• [ ] Épinglez les ID complets des modèles ; ne vous fiez plus aux alias flottants pour les chemins de production.
• [ ] Enregistrez une réponse de référence pour chaque invite dont votre application dépend.
• [ ] Ajoutez des assertions sur le statut, le `stop_reason` et les champs que vous analysez.
• [ ] Capturez les formes de refus et d'erreur ; assurez-vous qu'elles ne changent pas silencieusement.
• [ ] Simulez l'API Messages pour que la CI n'atteigne pas le point de terminaison en direct.
• [ ] Auditez les charges utiles sortantes par rapport à la fenêtre de conservation de 30 jours.
• [ ] Testez le comportement de délai d'attente et de réessai sous charge répétée.

Rien de tout cela ne nécessite d'attendre qu'Anthropic publie plus de détails. Vous contrôlez la vérification, et la vérification est ce qui transforme un titre de politique en un non-événement pour votre équipe.

FAQ

Dois-je modifier mes clés API en raison des changements de Fable et Mythos ? Non. L'authentification est inchangée. La rotation des clés selon un calendrier reste une bonne pratique, mais ces changements ne l'imposent pas.

Mon code existant pour l'API Messages et l'utilisation d'outils sera-t-il cassé ? Le contrat de requête et de réponse est stable, donc votre code continue de fonctionner. Ce qui peut changer, c'est le comportement ; les refus, la latence et le contenu diffusé sous l'influence des garde-fous. C'est un problème de test, pas de réécriture.

Qu'est-ce que le changement de conservation de 30 jours ? Les rapports décrivent une fenêtre de conservation de 30 jours appliquée au trafic Fable et Mythos. Si vos propres engagements en matière de confidentialité dépendent du comportement de conservation du fournisseur en amont, tenez-en compte et confirmez les données que vous envoyez réellement. Vérifiez toujours la documentation actuelle d'Anthropic sur l'utilisation des données pour les conditions faisant autorité.

Comment puis-je détecter les changements de garde-fous avant les utilisateurs ? Enregistrez des réponses de référence pour les invites proches de vos limites de contenu, ajoutez des assertions et exécutez-les selon un calendrier dans Apidog. Une assertion échouée vous indique le jour où le comportement change.

Puis-je tester tout cela sans dépenser de jetons ? Oui. Utilisez le serveur de simulation d'Apidog pour rejouer les réponses capturées, y compris les cas de refus et d'erreur, afin que vos exécutions de développement et de CI ne touchent jamais l'API en direct.

En résumé

Les changements de Fable et Mythos sont réels, mais pour la plupart des développeurs, il s'agit d'une histoire de comportement et de politique, pas d'une histoire d'API cassée. Vos clés fonctionnent, vos appels Messages fonctionnent, vos outils fonctionnent. L'exposition réside dans les éléments qui changent discrètement : les refus, la latence et ce que vos données deviennent après avoir quitté votre système. Épinglez vos modèles, capturez des références, faites des assertions dessus et simulez le fournisseur en amont pour que vos tests restent économiques et fiables. Téléchargez Apidog et transformez « Je pense que ça marche encore » en « J’ai vérifié, et voici la preuve. »