Gamme de modèles et tarifs

Gamme actuelle (septembre 2026)

Les écritures de cache coûtent ≈ 1,25× l’entrée de base (TTL de 5 minutes) ou 2× (TTL d’une heure). Batch API : 50 % de réduction sur l’entrée et la sortie.

Anciens modèles, toujours disponibles : Fable 5, Opus 4.8, 4.7, 4.6, 4.5, Sonnet 4.6, 4.5. Retirés : Opus 4.1 (2026-08-05).

Dates plancher de retrait publiées : Fable 5.1 pas avant le 2027-09-01 · Opus 5 pas avant le 2027-07-24 · Sonnet 5 pas avant le 2027-06-30 · Haiku 4.5 pas avant le 2026-10-15.

Matrice de capacités

Changements cassants de Fable 5.1 (favoris de l’examen)

1. Pas d’utilisation forcée d’outil. tool_choice: "any" et {"type": "tool", "name": …} renvoient 400. Alternatives : auto plus une instruction explicite ; strict: true sur le schéma de l’outil ; sortie structurée output_config.format.
2. Liaison des blocs de thinking. Les blocs de thinking ne sont lisibles que par le modèle qui les a produits ou un plus récent. Un basculement de secours ou de routeur vers un modèle plus ancien les supprime silencieusement (non facturés) et le modèle plus ancien replanifie de zéro.
3. Historique en ajout seul. Modifier, réordonner ou supprimer des tours antérieurs invalide tous les blocs de thinking ultérieurs. Figez system et tools, transmettez les changements d’instruction en cours de session sous forme de messages role: "system", et élaguez le contexte côté serveur (context editing / compaction) plutôt que côté client.
4. Rétention. Requiert une rétention des données de 30 jours ; non disponible pour les organisations ZDR sauf autorisation. Exclu du Priority Tier (comme Opus 5 et Sonnet 5).

Choisir un modèle — tableau de décision

Calculs de coûts détaillés

Exemple 1 — 10 000 documents, 3 000 tokens d’entrée chacun, 500 tokens de sortie chacun

Exemple 2 — prompt caching sur un prompt système de 20 000 tokens + outils, 1 000 requêtes/jour sur Sonnet 5

Règle : le caching se rentabilise après environ deux lectures du même préfixe dans le TTL.

Exemple 3 — choisir l’effort

Disponibilité cloud

La disponibilité des fonctionnalités peut être en retard sur les plateformes cloud ; vérifiez la doc par fonctionnalité avant d’arrêter une architecture.

Disponibilité des fonctionnalités par plateforme cloud

L’examen teste le réflexe selon lequel l’API Claude directe reçoit les nouvelles fonctionnalités en premier, et qu’une exigence de gouvernance ou de résidence peut imposer une plateforme en retard sur une fonctionnalité dont vous dépendez. Traitez ceci comme un instantané pour raisonner, pas comme un SLA en direct.

Paliers et dimensions de limites de débit

Les limites de débit s’appliquent simultanément sur trois dimensions ; vous atteignez celle qui contraint en premier.

Cycle de vie de dépréciation et de migration

Le retrait d’un modèle est un événement de cycle de vie planifié, pas une urgence. La posture correcte pour l’examen : surveiller les avis de dépréciation, conserver un jeu d’eval, migrer derrière cet eval, épingler les IDs en production.

Announced → Deprecated (still callable) → Retirement floor date → Retired (404)
   │              │                              │
   │              └─ start eval-gated migration  └─ published earliest date; often extended
   └─ appears in models.list() deprecation metadata / dashboard

Checklists de migration par modèle

1. Vers Haiku 4.5 — supprimez tout paramètre effort (non supporté → 400) ; si vous vous appuyiez sur budget_tokens, c’est le seul modèle actuel qui le conserve, donc une rétrogradation depuis les modèles à thinking adaptatif est là où budget_tokens réapparaît. Réajustez les prompts pour la fenêtre 200k/64k ; vérifiez la précision de classification/extraction sur le jeu golden.
2. Vers Sonnet 5 — abandonnez tout message role: "system" en milieu de conversation et les budgets de tâches (non supportés) ; confirmez que l’effort xhigh n’est pas supposé (aucun bénéfice). Revérifiez les budgets de latence ; c’est le défaut équilibré.
3. Vers Opus 5 — cible sûre pour la plupart des montées en gamme agentiques ; xhigh disponible. Supprimez budget_tokens (400) au profit de {"type":"adaptive"}. Rebaselinez le coût — 2,5× l’entrée de Sonnet.
4. Vers Fable 5.1 — la migration la plus friction. Supprimez le tool_choice forcé (any/nommé → 400) ; basculez vers auto+instruction, strict: true, ou output_config.format. Figez system/tools pour un historique en ajout seul. Confirmez que l’organisation n’est pas ZDR (rétention de 30 jours requise) et ne dépend pas du Priority Tier. Rebaselinez le coût à $10/$50.

Autres scénarios de coûts détaillés

Exemple 4 — caching + Batch combinés

Enrichissement nocturne de 50 000 enregistrements sur Sonnet 5. Chaque requête : préfixe partagé instruction/schéma de 12 000 tokens (cachable) + 800 tokens d’entrée uniques + 300 tokens de sortie. Exécuté comme un seul job Batch.

Sonnet 5 temps réel naïf, sans cache : préfixe 50k×12k=600M×$2=$1,200 + entrée 40M×$2=$80 + sortie 15M×$10=$150 = $1,430. Caching+Batch le réduit ≈ 88 %. Le préfixe domine, donc le mettre en cache importe bien plus que la réduction sur la petite portion unique.

Exemple 5 — mathématiques du routage en cascade

Un flux de 100 000 tickets. Une première passe Haiku 4.5 répond à 100 % (1 500 en entrée / 400 en sortie chacun). Un validateur externe signale 18 % comme à faible confiance ; ceux-ci escaladent vers Opus 5 (mêmes tokens). Comparez au fait de tout envoyer à Opus 5.

La cascade économise ≈ 62 %. Le taux d’escalade au point mort e où cascade = Opus-uniquement résout 350 + 1750e = 1750 → e ≈ 80%. En dessous de ~80 % d’escalade, la cascade gagne ; au-dessus, la passe Haiku est du pur surcoût — envoyez tout à Opus.

Idées reçues courantes

Analyse de scénario

Une fintech exécute un pipeline de classification de documents sur 2M de PDF/mois. Exigences : client fédéral américain (FedRAMP High), données personnelles (nécessite une résidence régionale et, idéalement, le ZDR), sensible au coût, latence non critique (nocturne), la qualité de classification doit être mesurée par type de document avant de changer de modèle.

Trace de raisonnement expert :

1. Résidence + FedRAMP High exclut l’API directe pour la charge réglementée → Bedrock ou Vertex. Choisissez celle correspondant aux dépenses cloud/IAM existantes.
2. ZDR souhaité + bon marché + classification à haut volume → Haiku 4.5. Il est éligible Priority Tier (sans importance ici, latence non critique) et supporte le ZDR. Fable 5.1 est rejeté : pas de ZDR, 10× le prix, et la classification n’a pas besoin de raisonnement de pointe (aveugle aux contraintes + sur-ingénierie).
3. Latence non critique, 2M/mois → Batch API (50 % de réduction). Le temps réel est rejeté comme inutilement coûteux (aveugle au coût).
4. Préfixe partagé schéma/instruction → prompt caching sur le préfixe stable ; PDF dynamique en dernier.
5. « Mesurée par type de document » → eval par segment sur un jeu golden, pas la précision agrégée (distracteur de métrique agrégée).
6. Migration de modèle plus tard → épinglez claude-haiku-4-5, conservez le jeu d’eval, migrez derrière lui quand un successeur sort.

Architecture correcte : Bedrock + Haiku 4.5 + Batch + prompt caching + evals par segment. Chaque alternative tentante (Fable partout, temps réel pour la vitesse, précision agrégée, routage sur confiance auto-déclarée) correspond à un pattern de distracteur nommé.