04 · Model Selection and Optimization : choisir le modèle, le régler et maîtriser son coût

Version : 1.1 · Date : 2026-10-22 · Domaine 5 : Model Selection and Optimization (16,8 %)

En une phrase : un LLM produit un token après l'autre dans une fenêtre de contexte partagée par l'entrée et la sortie ; on choisit le modèle en réglant d'abord l'effort, on mesure les tokens au lieu de les estimer, et on paie moins grâce au prompt caching, au Batch API et à un préfixe stable, jamais en coupant max_tokens.

C'est le 2e domaine de l'examen (16,8 %), et le plus « chiffré » : prix, limites, valeurs par défaut. Les chiffres de ce chapitre ont été relevés le 22/10/2026 sur la doc officielle ; ils bougent à chaque sortie de modèle, relisez la page Pricing et la page Models overview avant l'examen.

Ce que l'examen demande#

Texte officiel du Claude Certified Developer – Foundations Exam Guide v1.0 (juillet 2026) :

Convention du cours : le produit évolue plus vite que le guide v1.0. Quand c'est le cas, un encadré donne d'abord la réponse d'examen (celle du guide), puis l'état actuel du produit (relevé le 22/10/2026 sur la doc officielle).

0. Les bases à maîtriser avant tout#

0.1 Le vocabulaire#

0.2 Les quatre questions du domaine#

1. LLM Fundamentals (skill 5.1)#

1.1 La génération, un token après l'autre#

Le modèle lit toute l'entrée, puis produit un token à la fois : chaque nouveau token est choisi à partir de tout ce qui précède (l'entrée et les tokens déjà produits). Trois conséquences pratiques :

1.2 Mesurer les tokens, ne pas les deviner#

Le nombre de tokens d'un texte dépend du tokenizer du modèle. Les modèles récents n'utilisent pas le même : à partir d'Opus 4.7, le même texte produit environ 1 à 1,35 fois plus de tokens. Deux outils officiels :

import anthropic

client = anthropic.Anthropic()  # lit ANTHROPIC_API_KEY dans l'environnement

# Avant l'appel : estimer la taille exacte d'une requête (gratuit, soumis à des rate limits)
compte = client.messages.count_tokens(
    model="claude-opus-5-5",
    system="Tu es un assistant de support.",
    messages=[{"role": "user", "content": "Résume ce ticket : ..."}],
)
print(compte.input_tokens)

# Après l'appel : le compteur réel, à journaliser pour chaque requête
reponse = client.messages.create(model="claude-opus-5-5", max_tokens=1024,
                                 messages=[{"role": "user", "content": "Bonjour"}])
print(reponse.usage)  # input_tokens, output_tokens, cache_creation_input_tokens, cache_read_input_tokens

Piège : un tokenizer d'un autre fournisseur (tiktoken, par exemple) ou la règle « 4 caractères = 1 token » donnent un ordre de grandeur, jamais le chiffre. Pour un budget, une limite ou une facture : count_tokens avant, usage après.

1.3 La fenêtre de contexte : un seul budget pour tout#

Tous les modèles actuels ont 1M tokens de fenêtre et jusqu'à 128K tokens de sortie (300K en Batch API avec le beta output-300k-2026-03-24). Ce qui se passe quand ça déborde :

Deux idées reçues à corriger :

• Le prompt caching n'agrandit pas la fenêtre : un token lu depuis le cache compte dans la fenêtre comme un autre. Il change le prix, pas la place.
• Plus de contexte n'est pas mieux : la doc parle de context rot, la précision baisse quand le contexte s'allonge. On garde le contexte pertinent, on élague les résultats d'outils inutiles (voir le chapitre 05).

Certains modèles savent combien de contexte il leur reste (context awareness : Sonnet 5, Sonnet 4.6, Sonnet 4.5, Haiku 4.5). Pour les autres, les task budgets (beta, en-tête task-budgets-2026-03-13, champ output_config.task_budget, 20 000 tokens au moins) donnent au modèle un budget de tokens pour toute une boucle agentique.

1.4 Sampling et non-déterminisme#

À chaque pas, le modèle calcule une probabilité pour chaque token possible, puis en tire un : c'est l'échantillonnage (sampling). Deux requêtes identiques peuvent donc produire deux réponses différentes.

Réponse d'examen : temperature règle l'aléa (basse pour l'extraction, la classification ou le code ; plus haute pour la créativité) ; top_p et top_k restreignent les tokens candidats ; on règle l'un ou l'autre, pas les deux. Même à temperature 0, la sortie n'est pas garantie identique d'un appel à l'autre.

État actuel : les modèles Claude 4.7 et suivants (Opus 4.7 à 5.5, Fable, Sonnet 5 / 5.5, Haiku 5.5) n'acceptent que les valeurs par défaut : toute autre valeur renvoie une 400. La version d'API 2026-10-21 supprime ces paramètres (400 sur tous les modèles, même à la valeur par défaut). Le levier de qualité devient le prompt, l'effort et le thinking.

Ce qu'on fait du non-déterminisme, quel que soit le modèle :

1.5 Les options du modèle : thinking, effort, fast mode#

Adaptive thinking. Le modèle réfléchit avant de répondre, et décide quand et combien. Les tokens de thinking sont des tokens de sortie (dans max_tokens, facturés au prix de la sortie).

reponse = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},          # toujours actif sur Opus 5.5 et Fable 5.1
    output_config={"effort": "high"},       # low | medium | high | xhigh | max
    messages=[{"role": "user", "content": "Planifie la migration de ce schéma de base ..."}],
)

Réponse d'examen : extended thinking = thinking: {type: "enabled", budget_tokens: N}, un budget fixe de réflexion ; adaptive thinking = le modèle choisit lui-même.

État actuel : budget_tokens est déprécié sur Opus 4.6 et Sonnet 4.6, et rejeté (400) sur Fable 5 / 5.1, Opus 5.5 / 5 / 4.8 / 4.7, Sonnet 5.5, Sonnet 5 et Haiku 5.5. On utilise adaptive + effort. Sur Opus 5.5, thinking: {type: "disabled"} renvoie 400 ; sur Sonnet 5.5, le réglage le plus bas est {type: "between_tools"} (avec un effort high au plus).

Effort. C'est le premier levier coût / qualité / latence. Il agit sur tous les tokens de sortie : texte, appels d'outils et thinking. Un effort bas = moins de tokens, plus vite, moins cher ; un effort haut = plus de travail sur les cas difficiles.

Changer l'effort au niveau de la requête invalide le cache ; le changer en cours de conversation par un message role: "system" (beta mid-conversation-output-config-2026-07-01) le préserve.

Fast mode. Le même modèle, servi plus vite : jusqu'à 2,5 fois plus de tokens de sortie par seconde, au prix d'un tarif premium.

Ce qu'il faut savoir : pas de gain sur le délai avant le premier token (TTFT) ; usage.speed indique la vitesse servie ; rate limit dédié (429 quand il est atteint) ; repasser en vitesse standard provoque un cache miss ; incompatible avec le Batch API et le Priority Tier. Opus 5.5 en fast mode est aussi disponible sur Microsoft Foundry hébergé sur Azure.

1.6 Zero-shot, single-shot, multi-shot#

<examples>
  <example>
    <ticket>Ma facture de mars est en double.</ticket>
    <categorie>billing</categorie>
  </example>
  <example>
    <ticket>L'export CSV plante au-delà de 10 000 lignes.</ticket>
    <categorie>bug</categorie>
  </example>
</examples>

Piège : des exemples trop semblables apprennent au modèle un détail non voulu (toujours la même longueur, le même mot). On varie les exemples et on couvre les cas limites. Les exemples coûtent des tokens d'entrée à chaque requête : on les met dans le préfixe caché (section 4.2).

2. Technical Fundamentals (skill 5.2)#

2.1 Une API REST JSON sous le SDK#

La Claude API est une API REST : des requêtes HTTPS avec un corps JSON. L'appel principal :

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-opus-5-5", "max_tokens": 1024,
       "messages": [{"role": "user", "content": "Bonjour"}]}'

Les SDK officiels (Python, TypeScript, Java, Go, Ruby, C#, PHP) enveloppent cette API. Ils n'ajoutent ni modèle, ni tarif, ni limite : ils ajoutent l'ergonomie.

import anthropic

client = anthropic.Anthropic(max_retries=4, timeout=60.0)  # un seul client, réutilisé par toute l'application

try:
    reponse = client.messages.create(model="claude-sonnet-5-5", max_tokens=512,
                                     messages=[{"role": "user", "content": "Classe ce ticket ..."}])
except anthropic.RateLimitError:
    ...  # 429 après les retries : file d'attente, ou réduire le débit
except anthropic.APIStatusError as e:
    print(e.status_code, e.response.headers.get("request-id"))

Bonne pratique : créer un client et le réutiliser (connexions HTTP gardées ouvertes). Créer un client par requête coûte des connexions et fait perdre le bénéfice du pool.

Les erreurs à reconnaître : 400 requête invalide (paramètre retiré, prompt trop long), 401 clé invalide, 403 permission, 413 requête trop grosse, 429 rate limit (en-tête retry-after), 500 erreur interne, 529 overloaded_error (API surchargée, réessayer plus tard).

2.2 Streaming : SSE côté API, WebSocket côté client#

Avec stream: true, l'API renvoie des server-sent events (SSE) sur la même connexion HTTPS :

sequenceDiagram
    participant S as Votre serveur (SDK)
    participant A as Claude API
    S->>A: POST /v1/messages (stream: true)
    A-->>S: message_start (usage initial)
    A-->>S: content_block_start
    loop pour chaque morceau
        A-->>S: content_block_delta (text_delta, thinking_delta ou input_json_delta)
    end
    A-->>S: content_block_stop
    A-->>S: message_delta (stop_reason, usage final)
    A-->>S: message_stop

with client.messages.stream(model="claude-opus-5-5", max_tokens=4096,
                            messages=[{"role": "user", "content": "Explique ..."}]) as flux:
    for texte in flux.text_stream:
        print(texte, end="", flush=True)  # relayer vers le client au fil de l'eau
    message = flux.get_final_message()    # le message complet, usage compris

Le streaming est conseillé dès que la sortie est longue ou max_tokens élevé : il évite les timeouts sur les requêtes longues.

Le guide cite les websockets : ils se placent sur le premier saut, entre le navigateur et votre serveur. La clé API reste sur le serveur, qui appelle Claude en HTTPS et relaie le flux SSE.

Piège : appeler la Claude API directement depuis le navigateur expose la clé. Le serveur intermédiaire porte la clé, les quotas par utilisateur, la journalisation de usage et l'annulation.

2.3 Versions, betas et modèles#

• anthropic-version fige l'interface ; une nouvelle version peut retirer des paramètres (exemple : 2026-10-21 supprime temperature, top_p, top_k).
• anthropic-beta active une fonctionnalité en preview ; elle peut changer ou disparaître. On isole son usage derrière un drapeau de configuration.
• L'ID du modèle est un snapshot : changer d'ID, c'est changer de modèle, donc refaire les evals (section 3.4).
• La Models API (client.models.list() / retrieve) renvoie pour chaque modèle max_input_tokens, max_tokens et capabilities : utile pour vérifier une limite par code plutôt qu'en dur.

3. Model Selection and Tradeoffs (skill 5.3)#

3.1 La gamme actuelle#

Points communs : 1M de contexte, 128K de sortie, adaptive thinking, cutoff de connaissances à juin 2026. Le thinking est toujours actif sur Opus 5.5 et Fable 5.1. Les modèles legacy encore servis : Fable 5, Opus 5, Opus 4.8 / 4.7 / 4.6 / 4.5, Sonnet 5, Sonnet 4.6, Haiku 4.5.

Réponse d'examen : le guide oppose Opus (capacité maximale), Sonnet (équilibre) et Haiku (vitesse et volume).

État actuel : Fable 5.1 se place au-dessus d'Opus pour le raisonnement le plus exigeant, et la doc recommande Opus 5.5 comme point de départ. Le raisonnement « capacité / équilibre / vitesse » reste le bon.

3.2 Choisir : effort d'abord, modèle ensuite#

flowchart TD
    A[Tâche + eval sur vos cas réels] --> B[Commencer avec Opus 5.5, effort par défaut]
    B --> C{Qualité atteinte ?}
    C -- oui --> D[Baisser l'effort tant que la qualité tient]
    D --> E{Coût ou latence encore trop hauts ?}
    E -- oui --> F[Essayer Sonnet 5.5 puis Haiku 5.5 sur la même eval]
    E -- non --> G[Garder ce réglage]
    C -- non --> H[Monter l'effort : high, xhigh, max]
    H --> I{Qualité atteinte ?}
    I -- non --> J[Essayer Fable 5.1, revoir le prompt et le contexte]
    I -- oui --> G
    F --> G

Deux stratégies, toutes deux validées sur une eval :

La bonne mesure n'est pas le prix par token mais le coût par tâche terminée : un modèle moins cher qui échoue une fois sur trois, ou qui fait trois tours d'agent de plus, peut coûter plus cher au final. On compare sur les cas difficiles de l'eval, pas sur la moyenne.

3.3 Combiner plusieurs modèles#

3.4 Cycle de vie et breaking changes#

Exemple au 22/10/2026 : Sonnet 4.5 est retiré le 30/11/2026. La page Usage de la Console permet d'exporter un audit des modèles appelés, pour repérer ce qui utilise encore un modèle déprécié.

Les breaking changes récents, à connaître pour l'examen et pour toute migration :

Les erreurs d'interface sont bruyantes (400 immédiat). Les vrais risques sont silencieux : un coût qui monte avec le nouveau tokenizer, un comportement qui change avec le nouvel effort par défaut, un prompt écrit pour l'ancien modèle. La méthode du schéma : eval sur les tâches réelles, correction de l'interface, recomptage des tokens, audit des prompts et nouveau balayage d'effort, puis bascule progressive en surveillant usage et stop_reason.

4. Cost and Token Management (skill 5.4)#

4.1 Les quatre compteurs et la formule de coût#

Chaque réponse porte un objet usage :

Entrée totale = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Un input_tokens très petit ne veut pas dire une requête bon marché : il faut lire les quatre compteurs.

Tarifs relevés le 22/10/2026 ($ / MTok) :

Lecture cache = 0,05x l'entrée sur Opus 5.5 et Sonnet 5.5, 0,025x sur Fable 5.1, 0,1x ailleurs : ne pas confondre Sonnet 5.5 (0,10) avec Sonnet 5 (0,20).

Multiplicateurs qui s'ajoutent : Batch API -50 % sur tous les tokens (cache compris, les remises se cumulent) ; inference_geo: "us" (data residency) 1,1x ; fast mode (section 1.5). Le contexte long est au prix standard, sauf sur Haiku 5.5.

Modéliser un coût : coût d'une requête = Σ (compteur × tarif) ; coût mensuel = coût moyen par requête × volume, par fonctionnalité, à partir des usage réels journalisés (pas d'une estimation). Pour un agent, on compte la tâche entière : tous les tours, tous les résultats d'outils renvoyés.

4.2 Prompt caching#

Le cache fonctionne sur le préfixe de la requête, rendu dans l'ordre tools → system → messages. On place un cache_control sur le dernier bloc d'une partie stable ; tout ce qui précède ce point est mis en cache.

reponse = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=2048,
    tools=OUTILS,  # liste stable, dans un ordre déterministe
    system=[{
        "type": "text",
        "text": CONSIGNES_ET_DOCUMENTATION,             # gros bloc stable : rien de variable dedans
        "cache_control": {"type": "ephemeral", "ttl": "1h"},
    }],
    messages=historique,                                # la partie qui change
)
u = reponse.usage
print(u.cache_creation_input_tokens, u.cache_read_input_tokens, u.input_tokens)

Ce qui invalide le cache : tout octet modifié dans le préfixe invalide ce qui suit. Les causes classiques : un horodatage ou un identifiant de requête dans le system prompt, des outils dans un ordre variable, un JSON sérialisé sans ordre de clés stable, et les changements de réglages qui touchent le préfixe (outils, web search, citations, speed, tool_choice, images, thinking, effort au niveau de la requête).

Cache check-pointing. Dans une conversation ou une boucle d'agent, on place le breakpoint sur le dernier bloc du tour courant. Au tour suivant, tout le préfixe jusqu'à ce point est lu depuis le cache et seul le nouveau tour est écrit : le breakpoint « avance » à chaque tour. Le lookback de 20 positions permet de retrouver le point précédent ; au-delà (un tour qui ajoute beaucoup de blocs, par exemple de nombreux résultats d'outils), on ajoute un breakpoint intermédiaire.

sequenceDiagram
    participant App as Application
    participant API as Claude API
    App->>API: tour 1 : tools + system (cache 1 h) + message 1 (breakpoint)
    API-->>App: cache_creation_input_tokens élevé
    App->>API: tour 2 : même préfixe + réponse 1 + message 2 (breakpoint déplacé)
    API-->>App: cache_read élevé, cache_creation = le tour 1 seulement
    App->>API: tour 3 : même préfixe + ... + message 3 (breakpoint déplacé)
    API-->>App: cache_read encore plus élevé, input_tokens faible

Exemple chiffré (Opus 5.5, system prompt de 50 000 tokens, 1 000 requêtes par jour, chacune moins de 5 min après la précédente) :

Vérification indispensable : cache_read_input_tokens doit être supérieur à 0 à partir de la deuxième requête. Sinon, le préfixe change d'une requête à l'autre ou il est sous la taille minimum.

4.3 Batch API#

Bon usage : tout ce qui n'attend pas une réponse immédiate (évaluations, enrichissement de données, traitements de nuit). Mauvais usage : un chat ou une API synchrone.

4.4 Suivre l'usage#

La Usage and Cost API demande une clé Admin (sk-ant-admin01-…), non disponible pour les comptes individuels :

Les données arrivent en environ 5 minutes ; une interrogation par minute suffit. Le Priority Tier n'apparaît pas dans le cost report ; l'exécution de code n'apparaît que dans le cost report.

4.5 Les leviers, dans l'ordre#

Piège classique : baisser max_tokens pour économiser. C'est une coupure, pas une consigne : le modèle ne produit pas une réponse plus courte, elle est tronquée (stop_reason: "max_tokens"), et la reprise coûte plus cher. Pour des réponses plus courtes : la consigne dans le prompt, un format structuré, ou un effort plus bas.

5. Labs conseillés#

Chaque lab coûte quelques centimes sur un workspace de test (count_tokens est gratuit). Clé dans une variable d'environnement, jamais dans le code.

1. Compter avant, mesurer après : même texte passé à count_tokens sur claude-haiku-4-5 et claude-opus-5-5 ; comparer (nouveau tokenizer). Puis un messages.create et la lecture des quatre compteurs de usage.
2. Déborder exprès : max_tokens=50 sur une question longue, observer stop_reason: "max_tokens" et la réponse tronquée.
3. Balayage d'effort : 10 questions de difficulté variée, low / medium / high sur Sonnet 5.5 ; noter output_tokens, la latence et la qualité ; calculer le coût par réponse correcte.
4. Prompt caching : un system prompt de plus de 512 tokens avec cache_control, deux requêtes identiques à moins de 5 min ; vérifier cache_creation_input_tokens puis cache_read_input_tokens. Ajouter un horodatage dans le system prompt et constater le cache miss.
5. Check-pointing : une conversation de 4 tours avec le breakpoint sur le dernier message ; suivre l'évolution des trois compteurs d'entrée.
6. Streaming : messages.stream avec affichage des text_delta, puis get_final_message().usage.
7. Batch : un lot de 5 requêtes avec custom_id, suivre processing_status, rapprocher les résultats.
8. Breaking change : envoyer thinking: {type: "enabled", budget_tokens: 2000} à claude-opus-5-5, lire l'erreur 400, corriger en adaptive + effort.

6. Pièges d'examen#

7. Scénarios corrigés#

Questions originales, au format de l'examen. Répondez avant de lire la correction.

Q1. Un assistant interne reçoit 20 000 requêtes par jour. Chaque requête envoie le même system prompt de 30 000 tokens (procédures internes), puis une question courte. La facture est dominée par l'entrée. Que faire en premier ? A. Passer à Haiku 5.5. B. Mettre le system prompt en cache avec cache_control et vérifier cache_read_input_tokens. C. Réduire max_tokens. D. Passer en Batch API.

B. Préfixe identique et volume élevé : le prompt caching réduit le coût de ce bloc à 0,05x (Opus 5.5 / Sonnet 5.5) sans toucher à la qualité. A est un compromis à mesurer, C ne touche pas l'entrée, D est inadapté à un assistant interactif.

Q2. Après l'ajout du cache, cache_read_input_tokens reste à 0 à chaque requête. Le system prompt commence par Nous sommes le {date et heure}. Cause la plus probable ? A. Le TTL est trop court. B. Le préfixe change à chaque requête. C. Le modèle ne supporte pas le cache. D. Il faut 4 breakpoints.

B. L'heure en tête rend chaque préfixe unique. On la déplace après le breakpoint (dans le message utilisateur).

Q3. Une équipe migre de Sonnet 5 vers Sonnet 5.5. Son code envoie thinking: {type: "enabled", budget_tokens: 4000} et tool_choice: {type: "any"}. Que se passe-t-il ? A. Tout fonctionne, les paramètres sont ignorés. B. Erreur 400 ; il faut passer en adaptive + effort et en tool_choice auto. C. Avertissement dans la réponse. D. Le modèle bascule seul en Sonnet 5.

B. Les deux paramètres sont rejetés sur Sonnet 5.5. Ensuite : recompter les tokens et refaire le balayage d'effort.

Q4. Une tâche d'extraction sur Opus 5.5 donne la qualité voulue mais coûte trop cher. Première action ? A. Passer à Haiku 5.5 en production. B. Mesurer sur l'eval un effort low, puis seulement ensuite comparer Sonnet 5.5 et Haiku 5.5 au coût par extraction correcte. C. Baisser max_tokens. D. Activer le fast mode.

B. L'effort d'abord, mesuré ; puis le modèle, au coût par tâche réussie. D augmente le coût.

Q5. Un chat produit des réponses longues ; les utilisateurs trouvent qu'il « met du temps à répondre », bien que la qualité convienne. Le premier mot arrive vite mais la suite défile lentement. Quelle option ? A. Fast mode sur Opus 5.5. B. Batch API. C. Baisser max_tokens. D. Thinking disabled.

A. Le TTFT n'est pas le problème, c'est le débit de sortie : le fast mode l'augmente jusqu'à 2,5x (prix premium). B est asynchrone, C tronque, D renvoie 400 sur Opus 5.5.

Q6. Une application monopage (navigateur) doit afficher la réponse de Claude au fil de l'eau et permettre à l'utilisateur d'annuler. Quelle architecture ? A. Le navigateur appelle api.anthropic.com avec la clé. B. Le navigateur ouvre un WebSocket vers votre serveur, qui appelle la Messages API en stream: true et relaie les événements. C. Le serveur appelle l'API sans streaming et renvoie la réponse entière. D. Le navigateur interroge le serveur toutes les secondes.

B. Clé côté serveur, WebSocket bidirectionnel pour l'annulation, SSE entre le serveur et l'API.

Q7. Une requête contient 990 000 tokens d'entrée avec max_tokens à 64 000 sur un modèle à 1M de contexte. Résultat ? A. Erreur 400 immédiate. B. La requête est acceptée et la génération peut s'arrêter avec stop_reason: "model_context_window_exceeded". C. Le cache libère de la place. D. L'entrée est tronquée automatiquement.

B. L'entrée seule tient ; c'est la somme qui dépasse. 400 seulement si l'entrée seule dépasse la fenêtre.

Q8. Chaque nuit, 50 000 fiches produits doivent être résumées ; personne n'attend le résultat avant le matin. Le prompt commun fait 2 000 tokens. Quelle combinaison ? A. Fast mode + cache. B. Batch API + prompt caching (TTL 1 h), résultats rapprochés par custom_id. C. Appels synchrones en parallèle. D. Batch API + fast mode.

B. -50 % du Batch, cumulable avec le cache ; TTL 1 h car les requêtes du lot s'étalent. A et D : le fast mode est incompatible avec le Batch et coûte plus.

Q9. Un agent fait 30 tours par tâche, chaque tour renvoyant tout l'historique. Le coût d'entrée croît à chaque tour. Quelle technique ? A. Un seul breakpoint figé sur le system prompt. B. Cache check-pointing : breakpoint sur le dernier bloc de chaque tour, et un breakpoint intermédiaire si un tour ajoute plus de 20 blocs. C. Réduire max_tokens. D. Changer d'ID de modèle à chaque tour.

B. Le breakpoint qui avance fait lire tout l'historique depuis le cache ; A ne cache que le début.

Q10. Un directeur financier veut un tableau de bord quotidien des coûts Claude par workspace. Quelle source ? A. Additionner usage à la main dans les logs. B. Le cost_report de la Usage and Cost API avec une clé Admin, bucket 1d. C. count_tokens sur chaque requête. D. La page Pricing.

B. Coûts en USD par jour, groupables par workspace ; A sert au détail par fonctionnalité, C n'est qu'une estimation avant appel.

8. Pour aller plus loin (hors examen)#

• Priority Tier : capacité réservée pour les charges critiques (incompatible avec le fast mode).
• Data residency : inference_geo pour l'inférence aux États-Unis (1,1x).
• Effort par message (beta) : changer l'effort en cours de conversation sans casser le cache.
• Migration guide officiel : la liste complète des changements par modèle, à relire à chaque nouvelle version.
• La commande cost-optimize du skill claude-api de Claude Code applique la même méthode : profil de tokens, leviers sans perte d'abord, compromis mesurés ensuite.

9. Fiche à retenir#

• Génération : un token après l'autre ; la latence suit la longueur de sortie ; le streaming réduit la latence perçue.
• Tokens : count_tokens avant, usage après ; tokenizer propre au modèle (Opus 4.7+ : jusqu'à 1,35x plus).
• Fenêtre : 1M pour tout (entrée, outils, sortie, thinking) ; entrée seule trop grande = 400 ; entrée + max_tokens = model_context_window_exceeded ; le cache ne libère pas de place.
• Sampling : non-déterminisme ; temperature / top_p / top_k valeur par défaut seulement sur Claude 4.7 et suivants, et supprimés sur tous les modèles dans l'API 2026-10-21.
• Thinking : adaptive + effort ; budget_tokens = 400 sur la gamme récente.
• Effort : low → max, agit sur tous les tokens ; défaut medium (Opus 5.5, Haiku 5.5), high (Fable 5.1, Sonnet 5.5).
• Fast mode : jusqu'à 2,5x de débit, pas de gain TTFT, prix premium, pas de Batch.
• Shots : zero, single, multi (3 à 5 exemples variés, balisés).
• Technique : SDK = REST JSON + retries (2), timeout (10 min), exceptions typées ; un client réutilisé ; SSE côté API, WebSocket éventuel côté client ; clé sur le serveur.
• Choix : Opus 5.5 pour démarrer ; effort d'abord ; coût par tâche terminée ; Haiku pour le volume, Fable pour l'extrême.
• Breaking changes : budget_tokens, prefill, tool_choice forcé, thinking disabled, sampling, tokenizer, effort par défaut.
• Cache : tools → system → messages ; 4 breakpoints ; lookback 20 ; minimum 512 ; 5 min (1,25x) ou 1 h (2x) ; lecture 0,1x (0,05x Opus 5.5 / Sonnet 5.5, 0,025x Fable 5.1) ; check-pointing = breakpoint qui avance.
• Batch : -50 %, cumulable avec le cache ; 24 h max ; custom_id.
• Suivi : Usage and Cost API, clé Admin, usage_report et cost_report.
• Jamais : baisser max_tokens pour économiser.

Références#

Toutes consultées le 22/10/2026.

• Claude Certified Developer – Foundations Exam Guide v1.0 (juillet 2026)
• Models overview
• Pricing
• Model deprecations
• Migration guide
• Context windows
• Adaptive thinking · Extended thinking
• Effort
• Fast mode
• Prompt caching
• Batch processing
• Token counting
• Streaming messages
• Errors · Rate limits · Beta headers
• Usage and Cost API
• Cursus tiers, leçons 5.1 à 5.4 : claudecertificationguide.com/ccdv-f/learn