Réponse : B. system, temperature et les autres paramètres d’échantillonnage sont optionnels. max_tokens n’a pas de valeur par défaut : son omission provoque une erreur 400. Piège en D : contrairement à d’autres API du marché, il est obligatoire chez Anthropic.

Réponse : B. Atteindre le plafond max_tokens n’est pas une erreur HTTP : la requête réussit (200) mais la génération est coupée. La seule détection fiable est applicative : tester stop_reason == "max_tokens" sur chaque réponse. L’en-tête de C n’existe pas.

Réponses : A et C. Le prefilling est une technique officielle : le dernier message peut être un tour assistant partiel que le modèle prolonge. Le texte préfixé appartient à l’entrée, pas à la sortie — l’oublier produit des JSON invalides (sans accolade ouvrante). D est faux : seul le premier message doit être user.

Réponse : B. Le paramètre system est structurellement séparé de messages et le modèle est entraîné à lui accorder un poids particulier (instructions durables, résistance accrue aux tentatives de contournement dans les tours user). A est faux (facturé comme tout token d’entrée), C est fantaisiste, D est faux — l’API est sans état : tout doit être renvoyé à chaque appel.

Réponse : B. L’API étant sans état, l’historique complet est renvoyé — et facturé — à chaque tour. La somme des préfixes croît quadratiquement. « Lost in the middle » © est un effet de rappel dégradé de l’information au milieu du contexte, pas une suppression de tokens.

Réponse : B. ⚠ L’écriture au cache coûte un surcoût de ~25 % (donc 125 % du tarif) ; la lecture d’un hit coûte ~10 % du tarif (soit ~90 % d’économie). Conséquence : le cache est rentable dès la deuxième requête dans la fenêtre TTL (1,25 + 0,10 < 2,00) — et un cache jamais relu (préfixe instable) coûte plus cher que pas de cache du tout.

Réponse : C. Le cache porte sur le préfixe exact jusqu’au breakpoint, dans l’ordre tools → system → messages. Tout ce qui se situe après le breakpoint peut varier librement — c’est précisément le design cible : contenu stable en tête, question variable en queue. A et B modifient le préfixe ; D : le cache est propre à chaque modèle.

Réponse : C. Les tokenizers diffèrent entre familles et éditeurs — réutiliser un comptage tiktoken (OpenAI) pour Claude est une erreur classique. L’endpoint de comptage est distinct de la génération et permet de valider la fenêtre de contexte et d’estimer le coût avant de payer un appel. D décrit le comptage a posteriori, qui existe mais n’est pas le seul.

Réponse : C. La séquence canonique est message_start → content_block_start → content_block_delta* → content_block_stop → message_delta → message_stop. Les métadonnées finales (stop_reason, usage.output_tokens) arrivent dans message_delta. message_stop (D) est le piège classique : il clôt le flux mais ne porte pas ces champs ; un client qui ne parse pas message_delta ne détectera jamais une troncature en streaming.

Réponse : B. ⚠ Remise de 50 % sur entrée et sortie, engagement de traitement sous 24 h (la majorité des batches terminent en moins d’une heure), plafond de 100 000 requêtes (~256 Mo). Les requêtes sont indépendantes (pas d’état partagé — D faux) et les résultats arrivent dans un ordre quelconque : le custom_id est la seule clé de corrélation fiable. Bonus certification : batch et prompt caching se cumulent (hits non garantis).