# D2 · Claude Models, Prompting & Context Engineering
Sélection et routage de modèles au niveau portefeuille, prompts et garde-fous comme actifs gouvernés, contrôle du thinking/de l’effort, optimisation du contexte et des tokens, architecture de caching, versionnement des prompts, et contraintes du harnais Fable 5.1.
import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components';
Ce domaine pèse **13 % – environ 8 des 63 items**. Au niveau Professional, vous n’écrivez pas un seul prompt ; vous gérez un **portefeuille de modèles et une bibliothèque de prompts gouvernés** à l’échelle d’une organisation, avec le calcul de coût, le versionnement, le déploiement et la gestion des changements incompatibles. Les items récompensent l’option qui traite prompts, modèles et configuration du thinking comme des **actifs conçus et versionnés** aux arbitrages mesurables.
## Objectifs d’apprentissage
À la fin de cette page, vous devriez savoir :
1. Sélectionner et **router/mettre en cascade** au sein du portefeuille de modèles (Fable 5.1, Opus 5, Sonnet 5, Haiku 4.5) avec un vrai calcul de coût.
2. Gérer les **changements incompatibles** entre versions de modèles (règles des thinking blocks, paramètres supprimés).
3. Traiter les **system prompts, templates et garde-fous** comme des actifs gouvernés et versionnés.
4. Appliquer les techniques de prompting (**zero-shot, few-shot, CoT, thinking étendu/adaptatif, effort**) à la bonne altitude.
5. Optimiser la **fenêtre de contexte et les tokens**.
6. Concevoir une **architecture de caching** (préfixe stable d’abord, prompts modulaires, Skills) et un processus de **versionnement/déploiement**.
7. Respecter les **contraintes du harnais append-only de Fable 5.1**.
---
## 2.1 The model portfolio and routing
Il n’y a pas de « meilleur » modèle unique — il y a un portefeuille, et le rôle de l’architecte est de router chaque requête vers le modèle le moins cher qui atteint sa barre de qualité.
| Modèle | ID | Contexte / sortie max | In / out par MTok | Quand c’est le bon défaut |
| --- | --- | --- | --- | --- |
| Fable 5.1 | `claude-fable-5-1` | 1M / 128k | \$10 / \$50 | Raisonnement frontier ; thinking toujours actif ; harnais append-only ; rétention 30 jours |
| Opus 5 | `claude-opus-5` | 1M / 128k | \$5 / \$25 | Coding agentique complexe et travail d’entreprise |
| Sonnet 5 | `claude-sonnet-5` | 1M / 128k | \$2 / \$10 | Meilleur équilibre vitesse/intelligence ; défaut général |
| Haiku 4.5 | `claude-haiku-4-5` | 200k / 64k | \$1 / \$5 | Le plus rapide/le moins cher ; tâches à fort volume, sensibles à la latence, étroites |
### Routage et cascades
```text
┌──────────────┐ classify task difficulty / stakes
request ────▶ │ router │ (rules, or a Haiku classifier)
└──────┬───────┘
easy / high-vol │ hard / high-stakes
▼ ▼
┌────────────┐ ┌────────────┐
│ Haiku 4.5 │ │ Opus 5 / │
│ Sonnet 5 │──fail─▶│ Fable 5.1 │ (escalate on
└────────────┘ check └────────────┘ validation failure)
```
- **Routage statique** : règles par type de tâche/segment (extraction → Haiku, synthèse → Sonnet, coding le plus dur → Opus/Fable).
- **Cascade** : essayer d’abord le moins cher ; escalader sur l’échec d’une **vérification de validation/qualité**, non sur la confiance auto-déclarée.
:::tip[Signal d’examen]
« Le coût est 4× le budget mais la qualité est bonne » → introduire une **cascade** (moins cher d’abord, escalade sur échec de vérification). « Il nous faut la capacité la plus récente et le coût est secondaire » → Opus 5 / Fable 5.1. Les distracteurs qui escaladent sur la **confiance auto-déclarée** sont faux (anti-patron n° 4).
:::
### Exemple chiffré de calcul de coût
100k requêtes/jour, ~3k d’entrée + 1k de sortie tokens chacune.
| Stratégie | Coût quotidien (approx.) | Note |
| --- | --- | --- |
| Tout Opus 5 | 100k × (3k×\$5 + 1k×\$25)/1e6 = 100k × \$0.040 = **\$4,000** | référence |
| Tout Sonnet 5 | 100k × (3k×\$2 + 1k×\$10)/1e6 = 100k × \$0.016 = **\$1,600** | 60 % moins cher |
| Cascade : 80 % Haiku, 20 % Opus | 80k×\$0.008 + 20k×\$0.040 = **\$1,440** | qualité préservée sur les 20 % difficiles |
| Sonnet + cache (80 % de hit sur un préfixe de 2k) | ~**\$960** | lecture de cache ≈ 0,1× de l’entrée |
---
## 2.2 Managing breaking changes across versions
Les ID de modèles à partir de 4.6 sont **sans date mais restent des snapshots figés**. Mettre à niveau un modèle peut changer le comportement et casser du code qui reposait sur des paramètres supprimés.
| Changement | Concernés | Action de migration |
| --- | --- | --- |
| `budget_tokens` supprimé (renvoie 400) | Fable 5.x, Opus 5, Sonnet 5, Opus 4.7–4.8 | Utilisez `thinking: {"type": "adaptive"}` et `effort` ; seul Haiku 4.5 utilise encore `budget_tokens` |
| L’usage forcé d’outils renvoie 400 sur Fable 5.1 | Fable 5.1 | `tool_choice:"any"` / `{"type":"tool"}` forcé → utilisez `auto` + instruction, `strict:true`, ou les sorties structurées |
| Thinking blocks lisibles seulement par le modèle producteur ou plus récent | tous les modèles à thinking | Ne repliez jamais silencieusement vers un modèle plus ancien en cours de session |
| Opus 4.1 retiré le 2026-08-05 | épinglé sur 4.1 | Ré-épinglez et relancez la suite d’éval/régression |
Relancez toujours la **suite de régression** (D4) avant de promouvoir un changement de modèle. Utilisez `client.models.list()` / `.retrieve(id)` pour confirmer les limites en vigueur.
---
## 2.3 Prompts and guardrails as governed assets
Au niveau Professional, un system prompt est un **actif organisationnel partagé**, non une chaîne dans le carnet de quelqu’un. Gouvernez-le comme du code.
| Propriété | Pratique |
| --- | --- |
| Versionné | Stocké en VCS avec version sémantique ; changements revus |
| Testable | Chaque version tourne contre le golden eval set avant release |
| Modulaire | Composé de blocs stables (rôle, politique, format) + blocs volatils (tâche) |
| Doté de garde-fous | Règles de sûreté et métier en couches, non enfouies dans la prose |
| Déployé | Canary → pourcentage → complet, avec rollback |
:::caution[Anti-patron du prompt comme mécanisme d’application]
Les règles métier critiques (« ne jamais émettre un remboursement supérieur à 500 $ ») doivent être appliquées **programmatiquement** (hooks de permission d’outil, validation), non par une phrase dans le system prompt. On peut convaincre un modèle de contourner des règles en prose ; pas un hook. Les options qui reposent sur la formulation du prompt pour appliquer une règle ferme sont fausses (anti-patron n° 3).
:::
---
## 2.4 Prompting techniques at the right altitude
| Technique | À utiliser quand | Note coût/latence |
| --- | --- | --- |
| Zero-shot | La tâche est courante et bien spécifiée | Le moins cher |
| Few-shot | La forme/le format de sortie doit être fixé ; cas limites montrés | Ajoute des tokens d’entrée (cachez les exemples) |
| Chain-of-thought | Le raisonnement doit être explicite (modèles anciens/sans thinking) | Plus de tokens de sortie |
| Thinking étendu / adaptatif | Raisonnement difficile ; `thinking:{"type":"adaptive"}` sur les modèles actuels | Tokens de thinking facturés comme sortie |
| Effort (`low\|medium\|high\|xhigh`) | Régler la profondeur de raisonnement vs le coût ; `xhigh` pour le coding/agentique le plus dur sur Opus 5 / Fable 5.1 | Effort plus élevé = plus de tokens/latence |
| Fast mode | Usage sensible à la latence | Échange de la profondeur contre de la vitesse |
Sur les modèles actuels, préférez le **thinking adaptatif + effort** aux budgets manuels. Seul **Haiku 4.5** accepte encore `budget_tokens` et **n’a pas de paramètre `effort`**.
```json
{
"model": "claude-opus-5",
"thinking": { "type": "adaptive" },
"effort": "xhigh",
"messages": [{ "role": "user", "content": "Refactor this service for idempotency." }]
}
```
---
## 2.5 Context-window and token optimisation
Une fenêtre de 1M tokens est un budget, non une cible. La remplir augmente le coût et la latence et peut *réduire* la justesse (dégradation du needle-in-haystack).
| Levier | Effet |
| --- | --- |
| Récupérer, ne pas bourrer | N’envoyer que les chunks pertinents (RAG, D3) plutôt que des corpus entiers |
| Prompt caching | Amortir le préfixe stable ; lecture de cache ≈ 0,1× de l’entrée |
| Context editing | Effacer les résultats d’outils périmés de la fenêtre |
| Compaction | Résumé côté serveur préservant le fil pour les longues sessions |
| Réduction de sortie | Demander le schéma nécessaire ; éviter la prose verbeuse |
| Sorties structurées | Moins de tokens gaspillés que la forme libre + re-parsing |
---
## 2.6 Caching architecture: stable-prefix-first
Le prompt caching n’aide que si le **préfixe de cache est stable**. Ordonnez le contenu du **plus stable d’abord** : system prompt → outils → longs documents → exemples few-shot → tour utilisateur volatil. Marquez la frontière stable avec `cache_control`.
```text
[ system prompt ] ← stable ┐
[ tool definitions ] ← stable │ cache_control: {"type":"ephemeral"} (this prefix is cached)
[ reference documents]← stable │
[ few-shot examples ] ← stable ┘
------------------------------------- cache boundary
[ user's actual question ] ← volatile (changes every request → never cache here)
```
- **Écriture** de cache ≈ 1,25× (TTL 5 min) ou 2× (TTL 1 h) ; **lecture** de cache ≈ 0,1× de l’entrée de base.
- Préfixe minimal cachable ~**1024 tokens** (2048 sur Haiku).
- Placer quoi que ce soit de volatil avant le contenu stable **invalide le cache** à chaque appel — une erreur classique.
**Prompts modulaires + Skills** : gardez les blocs de capacité réutilisables sous forme de **Skills** (`SKILL.md`, chargées progressivement à la demande) plutôt que de tout coller dans chaque prompt. Cela garde le préfixe cachable stable et le contexte allégé.
---
## 2.7 Prompt versioning and rollout
Traitez chaque prompt comme `name@semver`. Stockez-le en VCS. Consignez la version de modèle contre laquelle il a été validé — un prompt réglé pour Opus 5 n’est pas garanti de se comporter pareil sur Haiku 4.5. Étiquetez les scores d’éval atteints.
Déployez la nouvelle version en canary sur une petite tranche de trafic avec des métriques online et un garde-fou sur la régression. Montez en charge par pourcentage. Gardez la version précédente à chaud pour un rollback instantané. Ne remplacez jamais un prompt à l’échelle de l’organisation sans une passe d’éval offline d’abord.
Parce que les prompts sont versionnés et que la version antérieure reste déployable, le rollback est un basculement de config, non un redéploiement. C’est pourquoi les prompts appartiennent à un registre gouverné, non inline dans le code applicatif.
---
## 2.8 Fable 5.1 append-only harness constraints
Fable 5.1 a le **thinking toujours actif**, et ses **thinking blocks ne sont lisibles que par le modèle producteur (ou un plus récent)**. Éditer, réordonner ou supprimer des tours antérieurs **invalide les thinking blocks ultérieurs**. Par conséquent, les harnais doivent être **append-only**.
| Règle | Conséquence si violée |
| --- | --- |
| Figer `system` et `tools` après le démarrage de la session | Les éditer invalide le thinking en aval |
| Placer les changements en cours de session dans un message `role: "system"` (ajouter, ne pas éditer) | Réécrire l’historique casse la boucle |
| Élaguer côté serveur via **context editing / compaction**, non en supprimant des tours côté client | La suppression côté client invalide les thinking blocks |
| Ne jamais forcer l’usage d’outils (`tool_choice:"any"` / outil forcé) — renvoie 400 | La requête échoue ; utilisez `auto` + instruction / `strict` / sorties structurées |
| Ne jamais replier silencieusement vers un modèle plus ancien | Le modèle plus ancien supprime les thinking blocks |
:::note[Sonnet 5 diffère]
Sonnet 5 ne prend **pas** en charge les messages système en cours de conversation et n’a pas de budgets de tâche. Ne supposez pas que l’astuce d’ajout de message système de Fable fonctionne à l’identique sur Sonnet 5 — l’examen teste ces différences par modèle.
:::
---
## 2.9 Arithmétique du coût du prompt caching
Le caching ne paie que lorsque vous pouvez le quantifier. Lecture ≈ **0,1×** de l’entrée de base ; écriture ≈ **1,25×** (TTL 5 min) ou **2×** (TTL 1 h) ; préfixe minimal cachable ~**1024** tokens (2048 sur Haiku).
**Exemple chiffré.** Sonnet 5, préfixe stable de 4 000 tokens (\$2/MTok en entrée), tour volatil de 500 tokens, 10 000 requêtes/jour, taux de cache-hit de 90 % après le warm-up.
```text
Uncached input cost/req = 4,500 × $2 / 1e6 = $0.0090
Cached (hit) input cost = (4,000 × 0.1 + 500) × $2/1e6 = (400 + 500)×$2/1e6 = $0.0018
Cache write (miss, 1.25×) = (4,000 × 1.25 + 500) × $2/1e6 ≈ $0.0110 (paid on ~10% of calls)
Daily uncached = 10,000 × $0.0090 = $90.00
Daily cached = 0.9×10,000×$0.0018 + 0.1×10,000×$0.0110 = $16.20 + $11.00 = $27.20
Saving ≈ 70% of input cost.
```
:::tip[Signal d’examen]
Le caching aide proportionnellement à la **taille du préfixe × le taux de hit**. Un préfixe minuscule ou un taux de hit faible (parce qu’un token volatil se trouve dans le préfixe) rend le caching inutile. Si un énoncé dit « le taux de hit est proche de zéro », cherchez un élément volatil avant la frontière de cache — non « désactiver le caching ».
:::
| Symptôme | Cause | Correctif |
| --- | --- | --- |
| Taux de hit proche de zéro | Contenu volatil avant la frontière ; timestamp/user-id par requête dans le préfixe | Déplacer le contenu volatil après la frontière `cache_control` |
| Le coût d’écriture domine | Le préfixe est rarement réutilisé dans le TTL | Utiliser le TTL 1 h, ou ne pas cacher les préfixes à faible réutilisation |
| Aucun effet sur Haiku | Préfixe sous le minimum de 2048 tokens | Consolider le contexte stable ou accepter l’absence de caching |
---
## 2.10 Structured outputs and schema enforcement
Au niveau Professional, « parser la prose » n’est jamais la réponse. Utilisez `output_config.format` avec un JSON schema et `strict: true` pour que la sortie du modèle soit conforme par construction, et réservez la validation-retry au rare raté.
```json
{
"model": "claude-sonnet-5",
"messages": [{ "role": "user", "content": "Extract the invoice fields." }],
"output_config": {
"format": {
"type": "json_schema",
"schema": {
"type": "object",
"properties": {
"invoice_id": { "type": "string" },
"total": { "type": "number" },
"currency": { "type": "string", "enum": ["USD", "EUR", "GBP"] }
},
"required": ["invoice_id", "total", "currency"],
"additionalProperties": false
},
"strict": true
}
}
}
```
| Approche | Fiabilité | Quand |
| --- | --- | --- |
| Texte libre + regex/parsing | Fragile | Jamais pour des données structurées |
| Prompt « renvoyer du JSON » seul | Mieux, mais faillible | Chemins legacy/non pris en charge |
| JSON schema `strict` (sorties structurées) | Conforme par construction | Défaut pour la sortie consommée par machine |
| Schéma d’outil avec `strict: true` | Arguments d’outil imposés | Quand un outil a besoin d’arguments typés |
:::tip[Signal d’examen]
Sur **Fable 5.1**, vous ne pouvez pas forcer l’usage d’outils (`tool_choice:"any"` → 400). Pour garantir une forme, utilisez les **sorties structurées / le schéma `strict`** ou `auto` + instruction — l’examen associe le besoin de « JSON garanti » à la contrainte « pas d’outils forcés sur Fable ».
:::
---
## 2.11 Context editing vs compaction
Les sessions de longue durée débordent la fenêtre. Deux outils côté serveur la gèrent, et ils ne sont pas interchangeables.
| Technique | Ce qu’elle fait | À utiliser quand | Risque en cas de mauvais usage |
| --- | --- | --- | --- |
| **Context editing** | Retire/efface les résultats d’outils et blocs périmés de la fenêtre | Les sorties d’outils sont volumineuses et devenues inutiles | Éditer des tours antérieurs invalide les thinking blocks de Fable 5.1 — éditez les *résultats d’outils*, pas le raisonnement |
| **Compaction** | Résumé côté serveur préservant le fil narratif | Sessions très longues où l’historique doit être conservé en substance | La sur-compaction perd du détail nécessaire plus tard |
| **Memory tool** | Persiste des faits durables hors de la fenêtre | Les faits doivent survivre entre sessions | Stocker des secrets/PII de façon inappropriée |
Préférez l’élagage **côté serveur** (context editing / compaction) à la suppression côté client des tours, qui casse les invariants du harnais append-only (2.8). Le hook `PreCompact` vous permet de capturer l’état avant l’exécution de la compaction.
---
## 2.12 Scénario détaillé : maîtriser une facture de prompt-et-modèle emballée
**Scénario.** Un produit d’analyse de documents exécute chaque requête sur Opus 5 avec `effort: xhigh`, un system prompt de 9k tokens dupliqué par appel, et l’usage forcé d’outils. La dépense mensuelle est 5× le budget ; l’équipe vient aussi d’échouer un pilote Fable 5.1 avec des erreurs 400. La qualité est acceptable ; la latence n’est pas le grief — c’est le coût.
**Trace de raisonnement d’expert.**
1. **Dimensionner correctement le modèle.** La qualité est déjà acceptable sur Opus 5, donc l’essentiel du trafic peut tourner sur **Sonnet 5** avec une cascade escaladant vers Opus 5 seulement sur l’échec d’une vérification de validation. Cela seul réduit le tarif par requête de ~60 %.
2. **Corriger l’effort.** `xhigh` partout est du gaspillage ; passez à `high`/`medium` et relancez la suite de régression par segment pour confirmer l’absence de baisse.
3. **Cacher le préfixe.** Le system prompt de 9k tokens est stable → marquez une frontière `cache_control` ; déplacez le document par requête *après* lui. Les lectures à 0,1× rendent le préfixe quasi gratuit à un taux de hit élevé.
4. **Modulariser avec des Skills.** Le texte de capacité dupliqué appartient à des **Skills** chargées à la demande, gardant le préfixe caché allégé et stable.
5. **Expliquer les 400 de Fable.** L’usage forcé d’outils n’est pas pris en charge sur Fable 5.1 ; passez à `auto` + instruction ou aux **sorties structurées**. Notez toutefois que le tarif \$10/\$50 de Fable en fait de toute façon le *mauvais* choix de coût ici.
6. **Re-valider et déployer.** Régression offline par segment → canary → montée en charge, version antérieure à chaud pour rollback.
**Pourquoi les alternatives tentantes sont fausses :** « tout passer sur Haiku » risque la barre de qualité ; « escalader sur la confiance auto-déclarée » est l’anti-patron n° 4 ; « acheter simplement un budget plus gros » ignore le calcul ; « continuer à forcer les outils et réessayer » ne peut pas corriger un 400.
---
## 2.13 Common misconceptions
| Idée reçue | Réalité | Pourquoi c’est important à l’examen |
| --- | --- | --- |
| « `budget_tokens` est la façon standard de contrôler le thinking. » | Supprimé sur les modèles actuels (400) ; seul Haiku 4.5 l’utilise encore. Utilisez le thinking adaptatif + `effort`. | Un énoncé « 400 après mise à niveau » teste exactement ceci. |
| « Une phrase forte du system prompt applique une règle métier. » | Les prompts sont de l’orientation ; les règles fermes nécessitent des hooks/validation. | Le prompt comme mécanisme d’application est une mauvaise réponse récurrente. |
| « Un effort plus élevé signifie toujours de meilleures réponses. » | Au-delà du besoin de la tâche, cela ajoute juste tokens/latence/coût. | Les distracteurs « xhigh partout » surdépensent. |
| « Le caching économise automatiquement de l’argent une fois activé. » | Seulement si le préfixe est stable et réutilisé au-dessus de la taille minimale. | Les énoncés à préfixe volatil rendent le caching inutile. |
| « Forcer l’usage d’outils fonctionne sur tout modèle. » | Fable 5.1 renvoie 400 sur l’usage forcé d’outils. | Les énoncés de forme garantie s’associent aux sorties structurées. |
| « Un prompt réglé sur Opus se comporte pareil sur Haiku. » | Le comportement diffère par modèle ; re-validez par modèle. | La réutilisation cross-model sans ré-éval est le piège. |
| « On peut élaguer une longue session en supprimant les anciens tours côté client. » | Sur les modèles à thinking cela invalide les thinking blocks ultérieurs ; élaguez côté serveur. | Les règles du harnais append-only sont testées par modèle. |
---
## Pièges de l’examen dans ce domaine
| Piège | Pourquoi c’est faux |
| --- | --- |
| Utiliser le modèle le plus cher pour chaque requête | Ignore le routage/les cascades ; fait exploser le budget de coût |
| Escalader dans une cascade sur la confiance auto-déclarée | L’auto-déclaration n’est pas fiable (anti-patron n° 4) ; escaladez sur l’échec de validation |
| Appliquer une règle métier ferme via le system prompt | Prompt comme mécanisme d’application (anti-patron n° 3) ; utilisez hooks/validation |
| Fixer `budget_tokens` sur Opus 5 / Sonnet 5 / Fable 5.1 | Supprimé ; renvoie 400 — utilisez le thinking adaptatif + effort |
| Forcer l’usage d’outils sur Fable 5.1 | Renvoie 400 ; utilisez `auto`+instruction, `strict`, ou sorties structurées |
| Éditer des tours antérieurs dans une session Fable 5.1 | Invalide les thinking blocks ultérieurs ; le harnais doit être append-only |
| Replier silencieusement vers un modèle plus ancien en cours de session | Supprime les thinking blocks ; corrompt la session |
| Placer le tour utilisateur volatil avant le préfixe caché | Invalide le cache à chaque appel |
| Remplir la fenêtre de 1M « parce qu’elle est disponible » | Augmente coût/latence ; peut réduire la justesse ; récupérez plutôt |
| Supposer qu’un prompt réglé sur un modèle se comporte à l’identique sur un autre | Doit être re-validé par version de modèle |
| Parser la prose en texte libre pour des données structurées au lieu d’un schéma `strict` | Fragile ; les sorties structurées sont conformes par construction |
| Supprimer les anciens tours côté client pour élaguer une session à thinking | Invalide les thinking blocks ultérieurs ; utilisez context editing/compaction |
| Supposer que le caching économise quelle que soit la taille du préfixe ou le taux de hit | Économie ∝ taille du préfixe × taux de hit ; un préfixe volatil donne ~0 |
| Stocker secrets/PII dans le memory tool ou le contexte persisté | Risque d’exfiltration/conformité ; gardez les secrets dans des gestionnaires de secrets |
| Monter l’`effort` à `xhigh` pour « améliorer la qualité » sans preuve | Ajoute tokens/latence/coût au-delà du besoin de la tâche |
---
## Questions d’entraînement
A. Déplacer tout le trafic vers Haiku 4.5.
B. Construire une cascade : Haiku 4.5 / Sonnet 5 d’abord, escalader vers Opus 5 seulement quand une vérification de validation de sortie échoue, et cacher le préfixe stable.
C. Escalader vers Opus 5 chaque fois que le modèle déclare une faible confiance dans sa propre réponse.
D. Augmenter l’effort à xhigh partout.
**Réponse : B.** Le moins cher d’abord avec escalade sur l’échec de *validation* préserve la qualité sur les cas difficiles tandis que l’essentiel du trafic tourne à bas coût ; le caching amortit le préfixe stable. Haiku partout (A) sacrifie la qualité. La confiance auto-déclarée (C) est un anti-patron. Monter l’effort partout (D) augmente le coût.
A. Ajouter plus de retries.
B. Remplacer `budget_tokens` par `thinking: {'type': 'adaptive'}` et contrôler la profondeur via `effort`, puisque `budget_tokens` est supprimé sur Opus 5.
C. Rétrograder définitivement vers Haiku 4.5.
D. Supprimer entièrement le thinking.
**Réponse : B.** `budget_tokens` est supprimé sur Opus 5 (et Sonnet 5 / Fable 5.x) et renvoie 400 ; le thinking adaptatif plus `effort` est le remplacement pris en charge. Les retries (A) ne corrigeront pas un 400. Haiku (C) est le seul modèle utilisant encore `budget_tokens` mais n’est pas un équivalent pour les charges Opus. Supprimer le thinking (D) élimine le raisonnement nécessaire.
A. Comme une phrase fermement formulée dans le system prompt.
B. Comme un hook programmatique de permission d’outil / une validation qui rejette tout remboursement supérieur à 500 $ avant exécution.
C. Comme un exemple few-shot montrant un gros remboursement refusé.
D. Dans le budget de thinking du modèle.
**Réponse : B.** Les règles métier fermes exigent une application programmatique — un hook ou une validation que le modèle ne peut pas contourner par le discours. La formulation du prompt (A) et les exemples few-shot (C) sont des anti-patrons du prompt comme mécanisme d’application. Le budget de thinking (D) est sans rapport.
A. Le caching est cassé ; désactivez-le.
B. Le tour utilisateur volatil se trouve avant le contenu stable, donc le préfixe caché change à chaque appel — réordonnez en stable-d’abord (system → outils → docs) puis le tour utilisateur, et marquez la frontière stable avec `cache_control`.
C. Les documents sont trop courts.
D. Haiku ne prend pas en charge le caching.
**Réponse : B.** Le caching s’appuie sur un préfixe stable ; placer le tour utilisateur changeant en premier l’invalide à chaque appel. Le préfixe stable d’abord avec une frontière `cache_control` corrige cela. Le caching n’est pas cassé (A) ; la longueur du document (C) ne compte que pour le minimum de ~1024 tokens ; Haiku prend en charge le caching (D) avec un minimum de 2048 tokens.
A. Coût en tokens et latence plus élevés par appel.
B. Possible dégradation de la justesse pour localiser le needle pertinent.
C. La fenêtre ne peut physiquement pas le contenir.
D. Les sorties structurées sont désactivées au-dessus de 200k tokens.
E. Le caching est interdit sur les grandes entrées.
**Réponse : A et B.** Le bourrage augmente coût et latence et peut nuire à la justesse de récupération dans un contexte énorme ; la récupération (RAG) n’envoie que les chunks pertinents. Cela tient dans la fenêtre (C est faux à 500k sur 1M), les sorties structurées ne sont pas bornées par la taille de cette façon (D), et le caching est autorisé sur les grandes entrées (E).
A. Éditer le champ `system` original sur place.
B. Ajouter le changement comme un nouveau message `role: 'system'`, en laissant les tours antérieurs intacts, car le harnais doit être append-only.
C. Supprimer les tours les plus anciens pour faire de la place.
D. Réordonner les messages pour placer la nouvelle instruction en premier.
**Réponse : B.** Les thinking blocks de Fable 5.1 sont invalidés par l’édition/le réordonnancement/la suppression des tours antérieurs, donc les changements en cours de session sont ajoutés comme un nouveau message système. Éditer sur place (A), supprimer des tours (C) et réordonner (D) invalident tous les thinking blocks en aval.
A. Réessayer jusqu’à ce que ça marche.
B. Utiliser `tool_choice: 'auto'` avec une instruction d’utiliser l’outil, fixer `strict: true` sur le schéma d’outil, ou utiliser les sorties structurées — car l’usage forcé d’outils n’est pas pris en charge sur Fable 5.1.
C. Basculer définitivement vers Haiku 4.5.
D. Supprimer tous les outils.
**Réponse : B.** L’usage forcé d’outils (`any` / outil forcé) renvoie 400 sur Fable 5.1 ; les chemins pris en charge sont `auto` + instruction, les schémas `strict`, ou les sorties structurées. Réessayer (A) ne corrigera pas un 400. Changer de modèle (C) ou supprimer les outils (D) abandonne l’exigence.
A. La remplacer à l’échelle de l’organisation immédiatement pour aller vite.
B. Valider offline contre le golden set, canary sur une petite tranche de trafic avec des garde-fous de régression, monter en charge par pourcentage, et garder la version antérieure à chaud pour un rollback instantané.
C. Laisser chaque ingénieur éditer le prompt inline dans son propre service.
D. La livrer et surveiller les plaintes clients.
**Réponse : B.** Les prompts sont des actifs gouvernés et versionnés : éval offline → canary → montée en charge → conserver la version antérieure pour rollback. Les remplacements à l’échelle de l’organisation (A) et la surveillance pilotée par les plaintes (D) sautent la validation. Les éditions inline par ingénieur (C) détruisent la gouvernance et la reproductibilité.
A. Opus 5 pour les deux étapes.
B. Haiku 4.5 pour l’extraction à fort volume ; Sonnet 5 ou Opus 5 pour la synthèse — en accordant le coût du modèle à la difficulté de chaque étape.
C. Fable 5.1 pour les deux, pour une qualité maximale.
D. Haiku 4.5 pour les deux, pour une économie maximale.
**Réponse : B.** Le routage de portefeuille affecte le modèle adéquat le moins cher par étape : Haiku pour l’extraction étroite à fort volume, un modèle plus fort pour la synthèse plus difficile. Opus/Fable pour les deux (A, C) surpaie ; Haiku pour les deux (D) risque la qualité de la synthèse.
A. Les packager comme des Skills (`SKILL.md`) chargées progressivement à la demande, gardant le préfixe cachable stable et allégé.
B. Les dupliquer dans le prompt de chaque service.
C. Les déplacer dans le tour utilisateur volatil.
D. Augmenter la fenêtre de contexte.
**Réponse : A.** Les Skills chargent la capacité progressivement à la demande, gardant le contexte allégé et le préfixe de cache stable. La duplication (B) est ce qui a causé le gonflement ; les déplacer dans le tour volatil (C) aggrave le caching ; une fenêtre plus grande (D) ne traite ni le coût ni la stabilité du cache.
A. Tous les modèles actuels requièrent `budget_tokens`.
B. Les modèles actuels utilisent `thinking: {'type':'adaptive'}` avec des niveaux d’`effort` low/medium/high/xhigh ; seul Haiku 4.5 utilise encore `budget_tokens` et n’a pas de paramètre `effort`.
C. L’effort n’existe que sur Haiku 4.5.
D. L’effort xhigh est le défaut sur tous les modèles.
**Réponse : B.** Le thinking adaptatif plus l’effort est standard sur les modèles actuels ; Haiku 4.5 est l’exception, utilisant encore `budget_tokens` et dépourvu d’`effort`. `budget_tokens` n’est pas universel (A) ; l’effort n’est pas propre à Haiku (C) ; high (pas xhigh) est le défaut (D).
A. Haiku 4.5 est défectueux.
B. Les prompts sont validés par version de modèle ; un prompt réglé pour un modèle doit être re-testé (et souvent ajusté) contre le golden set sur tout autre modèle avant usage.
C. Toujours utiliser Opus 5.
D. Les chutes de qualité sont inévitables et doivent être ignorées.
**Réponse : B.** Le comportement du modèle diffère au sein du portefeuille, donc les versions de prompt portent le modèle contre lequel elles ont été validées et doivent être ré-évaluées lors d’une réutilisation ailleurs. Haiku n’est pas défectueux (A) ; imposer Opus (C) ignore le coût ; ignorer les régressions (D) est une négligence.
A. Rien ; le caching n’aide jamais les grands préfixes.
B. Environ 70 %, car une lecture de cache est ~0,1× de l’entrée, donc le préfixe de 4k devient ~400 tokens effectifs sur les hits.
C. Exactement 50 %, la remise Batch.
D. 100 % ; les requêtes cachées sont gratuites.
**Réponse : B.** Une lecture ≈ 0,1× de l’entrée transforme les 4 000 tokens du préfixe en ~400 sur les 90 % de hits ; le coût d’entrée quotidien tombe de ~\$90 à ~\$27, soit environ 70 %. Le caching aide bien les grands préfixes stables (A) ; 50 % est la remise Batch, pas le caching (C) ; les lectures cachées sont peu chères, pas gratuites (D).
A. Forcer un appel d’outil avec `tool_choice: 'any'` et réessayer sur 400.
B. Utiliser les sorties structurées avec un JSON schema `strict` (ou `auto` + instruction), ce qui garantit la forme sans forcer l’usage d’outils.
C. Demander du JSON dans le prompt et regex-parser la prose.
D. Passer au texte libre et re-parser.
**Réponse : B.** Les sorties structurées avec un schéma `strict` sont conformes par construction et n’exigent pas d’usage forcé d’outils, que Fable 5.1 rejette avec 400. Forcer les outils (A) échoue ; le JSON par prompt seul avec regex (C) et le re-parsing en texte libre (D) sont du parsing de prose fragile.
A. Supprimer les tours utilisateur/assistant les plus anciens côté client.
B. Utiliser le context editing pour effacer les résultats d’outils périmés côté serveur (et la compaction pour le fil narratif), en évitant les éditions côté client du raisonnement antérieur qui invalident les thinking blocks.
C. Baisser la température pour rétrécir le contexte.
D. Forcer le modèle à se résumer lui-même dans le même tour.
**Réponse : B.** Le context editing retire les résultats d’outils périmés côté serveur ; la compaction résume le fil narratif — les deux évitent d’invalider les thinking blocks. Supprimer des tours côté client (A) casse l’invariant append-only ; la température (C) n’affecte pas la taille du contexte ; l’auto-résumé dans le tour (D) ne récupère pas la fenêtre.
A. Mettre en cascade l’essentiel du trafic vers Sonnet 5, en escaladant vers Opus 5 seulement sur l’échec d’une vérification de validation.
B. Baisser l’effort à un niveau adéquat et relancer la suite de régression par segment.
C. Escalader sur la confiance auto-déclarée du modèle.
D. Déplacer tout le trafic vers Fable 5.1 pour la qualité.
E. Supprimer la suite d’évals pour réduire le calcul.
**Réponse : A et B.** Une cascade moins-cher-d’abord et un effort correctement dimensionné (re-validé par segment) réduisent le coût tout en préservant la qualité sur les cas difficiles. L’auto-déclaration (C) est l’anti-patron n° 4 ; Fable 5.1 (D) est le modèle le plus cher ; supprimer les évals (E) retire la garde de qualité.
A. Désactiver le caching ; il ne fonctionne pas ici.
B. Retirer le `request_id` volatil du préfixe (le journaliser séparément) pour que le préfixe soit stable au byte près, restaurant les cache hits.
C. Raccourcir les documents.
D. Augmenter la fenêtre de contexte.
**Réponse : B.** Un token par requête dans le préfixe le change à chaque appel, donc rien ne se cache ; le sortir restaure un préfixe stable. Le caching n’est pas cassé (A) ; la longueur du document (C) n’affecte que le minimum ; une fenêtre plus grande (D) est sans rapport.
A. Coller le fait dans chaque system prompt.
B. Utiliser le memory tool pour persister le fait entre sessions, mais ne jamais y stocker de secrets/PII de façon inappropriée et le tenir hors des logs visibles par le modèle.
C. Le stocker dans `CLAUDE.local.md`.
D. Augmenter la rétention pour le garder dans les logs du fournisseur.
**Réponse : B.** Le memory tool persiste des faits durables entre sessions ; la contrainte est de ne pas y stocker de secrets/PII de façon inappropriée. Coller par prompt (A) gonfle le contexte ; `CLAUDE.local.md` (C) est un fichier de développement de Claude Code, non un store runtime ; s’appuyer sur la rétention du fournisseur (D) n’est pas un mécanisme de mémoire et augmente le risque de conformité.
## À retenir
- Gérez un **portefeuille** : routez/mettez en cascade vers le modèle le moins cher qui franchit la barre de qualité ; escaladez sur l’**échec de validation**, non sur la confiance auto-déclarée.
- Faites le **calcul de coût** — cascades et caching réduisent couramment la dépense de 60–75 % avec la qualité préservée sur les cas difficiles.
- Gérez les **changements incompatibles** : `budget_tokens` supprimé (400) sauf sur Haiku 4.5 ; l’usage forcé d’outils échoue sur Fable 5.1 ; relancez les régressions avant de promouvoir un modèle.
- Traitez prompts et garde-fous comme des **actifs versionnés et gouvernés** ; appliquez les règles fermes **programmatiquement**, jamais via la prose du prompt.
- Utilisez le **thinking adaptatif + effort** ; réservez `xhigh` au travail Opus/Fable le plus dur.
- **Cachez le préfixe stable d’abord** ; gardez les blocs réutilisables comme des Skills ; ne placez jamais de contenu volatil avant le préfixe caché.
- Les harnais Fable 5.1 sont **append-only** : figez system/outils, ajoutez des messages système, élaguez côté serveur, ne forcez jamais les outils et ne rétrogradez jamais silencieusement.
- **Économie du caching ∝ taille du préfixe × taux de hit** ; un token volatil dans le préfixe (timestamps, request IDs) fait tomber le taux de hit à ~0 — retirez-le, ne désactivez pas le caching.
- Garantissez la forme de sortie avec les **sorties structurées / schémas `strict`**, surtout sur Fable 5.1 où l’usage forcé d’outils renvoie 400 — ne parsez jamais la prose.
- Gérez les longues sessions avec le **context editing** (effacer les résultats d’outils périmés) et la **compaction** (résumer le fil narratif) côté serveur ; le **memory tool** persiste des faits durables (pas de secrets/PII).