D5 · Context Management and Reliability

Ce domaine vaut environ 9 des 60 items et sous-tend chaque scénario : un système qui marche en démo mais se dégrade à mesure que la fenêtre de contexte se remplit, ou s’effondre quand l’API renvoie 429, n’est pas prêt pour la production. Il évalue l’économie de la fenêtre de contexte, les deux façons de la récupérer (édition de contexte vs compaction), ce qui doit vivre dans un état durable, et les patrons de fiabilité — caching, réessais, repli, supervision — qui maintiennent un système agentique en fonctionnement.

Objectifs d’apprentissage

À la fin de cette page, vous devriez savoir :

1. Raisonner sur l’économie de la fenêtre de contexte et ce qui consomme le contexte.
2. Choisir entre l’édition de contexte (effacer les résultats d’outils) et la compaction (résumer en préservant la trame narrative).
3. Utiliser le memory tool et l’état externe pour tout ce qui doit survivre à la compaction, et l’isolation des sous-agents pour protéger le contexte principal.
4. Utiliser le prompt caching comme levier de fiabilité et de coût, et honorer la contrainte append-only de Fable 5.1.
5. Concevoir des réessais/backoff/idempotence, une dégradation gracieuse et des modèles de repli — et savoir ce qui casse lors d’un repli depuis Fable 5.1.
6. Maintenir la provenance et les citations, et concevoir des barrières d’escalade / human-in-the-loop.
7. Mettre en place une supervision (latence p95, taux d’erreur, taux de succès du cache, coût par tâche) et concevoir pour les rate limits, timeouts et résultats partiels.

5.1 Économie de la fenêtre de contexte

La fenêtre est un budget, non un espace gratuit. Tout la partage :

┌───────── context window budget ─────────┐
│ system prompt                            │  stable
│ tool definitions                         │  stable
│ conversation history (turns)             │  grows every turn
│ tool results (can be huge)               │  grows fast
│ thinking tokens                          │  grows with reasoning
└──────────────────────────────────────────┘

À mesure que la fenêtre se remplit, la latence et le coût montent et la qualité peut se dégrader (« context rot »). Le rôle de l’architecte est de garder l’ensemble de travail petit : mettre en cache les parties stables, évincer ce qui n’est plus nécessaire, et pousser les faits durables vers un état externe.

5.2 Édition de contexte vs compaction

Deux mécanismes distincts récupèrent du contexte. Bien choisir est testé.

Context editing:  [sys][tools][turn1][BIG tool result ✗ cleared][turn2]…  ← keeps dialogue, drops bulk
Compaction:       [sys][tools][==== summary of turns 1..40 ====][turn41]… ← condenses the narrative

5.3 Memory tool et état externe

La compaction et l’édition de contexte sont avec perte. Tout ce qui doit survivre — une décision, un fait client, un point de contrôle, des données métier canoniques — appartient à un état durable :

• Memory tool — persistance gérée par le modèle entre sessions.
• Fichiers — artefacts et points de contrôle que vous contrôlez.
• Base de données — état métier canonique et transactionnel (commandes, tickets).

La conversation référence l’état durable ; elle ne le possède pas. C’est la même règle que la table état-vs-conversation du Domaine 1.

5.4 L’isolation des sous-agents protège le contexte principal

Un sous-agent s’exécute dans sa propre fenêtre de contexte. Déléguer une sous-tâche volumineuse (lire 50 fichiers, chercher dans un large corpus) à un sous-agent signifie que la matière brute n’entre jamais dans la fenêtre du coordinateur — seul le résultat distillé revient. C’est l’un des patrons de protection du contexte les plus efficaces, et c’est pourquoi le passage de contexte explicite (Domaine 1) compte : le sous-agent démarre propre.

5.5 Ordonnancement en contexte long et prompt caching

• Ordonnancement. Placez le contenu stable et réutilisable en premier (system, outils, longs documents de référence) ; placez la tâche variable en dernier. Cela active le caching et garde l’attention du modèle sur le bon matériel.
• Prompt caching comme levier de fiabilité + de coût. Les lectures de cache ≈ 0,1× le prix d’entrée de base ; les écritures ≈ 1,25× (TTL 5 min) ou 2× (TTL 1 heure). Marquez le dernier bloc stable avec cache_control: {"type": "ephemeral"}. Préfixe cachable minimum ~1024 tokens (2048 sur Haiku). Un fort taux de succès du cache abaisse le coût et la latence, améliorant la fiabilité sous charge.

system = [
    {"type": "text", "text": SYSTEM_RULES},
    {"type": "text", "text": TOOLS_DOC},
    {"type": "text", "text": REFERENCE, "cache_control": {"type": "ephemeral"}},  # cache boundary
]

5.6 Fable 5.1 : historique append-only et liaison des thinking blocks

Fable 5.1 introduit des changements cassants autour desquels un architecte doit concevoir :

• Historique append-only. Éditer, réordonner ou supprimer les tours antérieurs invalide les thinking blocks ultérieurs. Les harnais doivent être append-only : figez system et tools, placez les changements en cours de session dans des messages role: "system", et réduisez côté serveur via l’édition de contexte/la compaction plutôt qu’en réécrivant la transcription.
• Liaison des thinking blocks. Les thinking blocks ne sont lisibles que par le modèle qui les produit ou un plus récent. Le repli vers un modèle plus ancien écarte silencieusement ces thinking blocks.
• Contraintes opérationnelles. Requiert une rétention des données de 30 jours ; pas dans le Priority Tier ; thinking toujours actif.

5.7 Réessais, backoff, idempotence

Réessayez les erreurs transitoires avec un backoff exponentiel et un jitter, en honorant retry-after :

Ne réessayez sans danger que les opérations idempotentes ; donnez aux écritures une clé d’idempotence (Domaine 1).

def call_with_backoff(fn, max_attempts=5):
    for i in range(max_attempts):
        try:
            return fn()
        except (RateLimitError, APIError, OverloadedError) as e:
            if i == max_attempts - 1:
                raise
            delay = min(2 ** i, 30) + random.random()      # backoff + jitter
            time.sleep(getattr(e, "retry_after", delay))

5.8 Dégradation gracieuse et modèles de repli

Lorsque le modèle principal est indisponible ou surchargé, dégradez gracieusement : repliez vers un autre modèle, servez un résultat en cache/partiel, ou mettez en file pour plus tard. Le repli a des coûts.

5.9 Provenance et citations

Pour toute sortie sur laquelle on s’appuiera, préservez d’où elle vient : conservez les citations issues du web search / de la récupération, attachez des identifiants de source aux faits extraits, et faites remonter la provenance pour qu’un humain puisse vérifier. La provenance est à la fois un contrôle de qualité et de gouvernance (et se marie aux métriques par type et à la validation du Domaine 3).

5.10 Escalade et barrières human-in-the-loop

Les actions irréversibles ou à fort enjeu ont besoin d’une barrière humaine — la même logique d’escalade que le Domaine 1 (demande explicite → immédiat ; lacune de capacité → après avoir tenté ; jamais sentiment/auto-déclaration), plus une approbation humaine obligatoire avant les effets irréversibles (paiements, suppressions, envois externes). La barrière est déterministe (une permission/hook), non une requête de prompt.

5.11 Supervision

Instrumentez le système avec les métriques qui prédisent la défaillance :

Associez aux traces par agent et aux identifiants de corrélation (Domaine 1).

5.12 Rate limits, timeouts et résultats partiels

• Les rate limits sont par palier de modèle (RPM, ITPM, OTPM). Concevez la concurrence et le batching pour rester en dessous ; utilisez le Batch API (réduction de 50 %, sous 24 h) pour le travail tolérant à la latence.
• Timeouts. Fixez-les à chaque frontière (appels d’outils, sous-agents, tâche globale) ; un outil bloqué ne doit pas bloquer l’agent.
• Résultats partiels. En cas de timeout ou de défaillance partielle, renvoyez ce que vous avez avec la provenance de la lacune (gestion des défaillances partielles du Domaine 1), plutôt que rien ou une fausse réponse complète.

5.13 Économie du contexte avec calcul de tokens

Traitez la fenêtre comme un budget contre lequel vous pouvez calculer. Un exemple travaillé pour un agent de longue durée sur Opus 5 (fenêtre 1M, $5/M en entrée, $25/M en sortie) :

Turn budget as the session grows (input tokens carried each turn):
  system + tools (stable)          =  12,000
  CLAUDE-style reference docs      =   8,000
  conversation history @ turn 30   =  60,000
  accumulated tool results         = 400,000   ← the runaway
  thinking (this turn)             =  10,000
  ----------------------------------------------
  input this turn                  = 490,000 tokens
  cost of THIS input turn          = 490,000 × $5 / 1e6 = $2.45   (and rising every turn)

Les résultats d’outils accumulés dominent. Trois leviers, avec leur calcul :

• L’édition de contexte efface les 400k de résultats d’outils périmés → l’entrée tombe à ~90k → le coût d’entrée de ce tour passe de $2.45 à ~$0.45.
• Le prompt caching du préfixe stable de 20k (system + outils + docs) → ces tokens se lisent à ~0,1× (20,000 × $0.5/1e6 = $0.01 vs $0.10).
• L’isolation des sous-agents : déléguez la sous-tâche gourmande en outils pour que les 400k n’entrent jamais dans la fenêtre principale — seul le résultat distillé revient.

5.14 Le harnais Fable 5.1 : contraintes et une conception conforme

Fable 5.1 (claude-fable-5-1, 1M/128k, $10/$50) a les règles de harnais les plus strictes de l’examen. Concevez autour de toutes :

Compliant Fable 5.1 harness:
  ┌ freeze system + tools (never edited) ─────────────┐
  │ append user/assistant turns only                  │
  │ mid-session change? → append a role:"system" msg  │  (NOT edit an old turn)
  │ window pressure?    → server-side context editing  │
  │                       / compaction (append-safe)   │
  │ need structured out?→ output_config.format / strict │  (never forced tool_choice)
  └────────────────────────────────────────────────────┘

5.15 Budgets de fiabilité : timeouts, concurrence et calcul de rate-limit

La fiabilité est quantitative. Une vérification rapide de capacité pour une charge temps réel :

Tier limits (example):  RPM = 4,000   ITPM = 400,000 input tokens/min
Per request:            ~10,000 input tokens
Token-bound throughput: 400,000 / 10,000 = 40 requests/min  ← ITPM binds first
Request-bound:          4,000 RPM
=> Effective ceiling = min(40, 4,000) = 40 rpm; the token limit dominates.

Si vous avez besoin de 10 000 tâches tolérantes à la latence, le plafond temps réel (40/min ≈ 4 h et plus, avec un risque de rate-limit) plaide pour le Batch API (50 % de réduction, ≤24 h) à la place. Fixez des timeouts à chaque frontière (outil, sous-agent, tâche globale) pour qu’un appel bloqué ne puisse pas figer le système, et en cas de timeout renvoyez des résultats partiels avec la provenance de la lacune.

Idées reçues fréquentes

Étude de scénario — un agent de recherche rapide en démo qui s’effondre en production

Situation. Un agent de recherche multi-agents marche en démo mais en production (1) se dégrade après ~30 tours à mesure que la fenêtre se remplit de grands résultats de recherche dont il n’a plus besoin, alors que le fil du dialogue doit rester intact ; (2) lors d’un événement de capacité chez Anthropic, il bascule de Fable 5.1 vers un modèle plus ancien et se met à se comporter différemment même avec un prompt identique ; (3) un SRE rapporte qu’il est « correct en moyenne » alors que des utilisateurs attendent parfois 9 secondes et que la facture mensuelle est une surprise ; et (4) une exécution nocturne de 10 000 tâches d’extraction bute sans cesse sur les rate limits.

Trace de raisonnement d’expert.

1. Problème 1 — fenêtre qui se remplit, garder le dialogue. Des résultats d’outils volumineux et périmés avec la trame narrative préservée → édition de contexte, non la compaction (qui résumerait le dialogue) ni un modèle plus gros. De plus, déléguez le travail gourmand en recherche à des sous-agents pour que les résultats bruts n’entrent jamais dans la fenêtre principale.

2. Problème 2 — changement de comportement au repli. Les thinking blocks de Fable 5.1 ne sont lisibles que par ce modèle ou un plus récent, donc le repli plus ancien les écarte silencieusement. La conception doit tester le chemin dégradé et ne pas supposer la parité ; la taille de fenêtre et l’expiration de clé sont des fausses pistes.

3. Problème 3 — queue cachée et coût. Ajoutez la latence p95/p99 (la queue de 9 secondes que les moyennes masquent) et le coût par tâche (la facture surprise). Rejetez « nombre total de requêtes » et « nom du modèle » comme non diagnostiques.

4. Problème 4 — rate limits sur la masse. 10 000 tâches tolérantes à la latence appartiennent au Batch API (50 % de réduction, ≤24 h), qui allège la pression de rate-limit. Rejetez la concurrence maximale en temps réel (plein tarif, risque de limite) et une seule requête géante (ne rentrera pas).

Décision correcte à l’examen : édition de contexte + isolation des sous-agents pour la fenêtre ; un chemin dégradé testé pour le repli Fable 5.1 ; supervision p95/p99 et coût-par-tâche ; et le Batch API pour la masse. Chaque option rejetée est un piège nommé (modèle-plus-gros, hypothèse-de-parité, supervision-en-moyenne-seule, masse-en-temps-réel).

Pièges d’examen dans ce domaine

Questions d’entraînement

Points clés à retenir

• La fenêtre de contexte est un budget partagé consommé par le system, les outils, l’historique, les résultats d’outils et le thinking ; gardez l’ensemble de travail petit.
• L’édition de contexte efface les résultats d’outils périmés ; la compaction résume la trame narrative — ni l’une ni l’autre ne préserve tout, donc les faits durables vont au memory tool ou à une base de données.
• L’isolation des sous-agents garde la matière brute volumineuse hors de la fenêtre principale ; mettez le contenu stable en premier et cachez-le pour des lectures ~10× moins chères et une latence plus basse.
• Faites le calcul : le terme des résultats d’outils accumulés domine généralement une fenêtre qui se remplit, donc l’édition de contexte (ou l’isolation des sous-agents) — non un modèle plus gros — est le correctif économique.
• Fable 5.1 est append-only (n’éditez jamais d’anciens tours), le thinking est toujours actif, un tool_choice forcé est un 400, il a une rétention de 30 jours/pas de ZDR, et il n’est pas Priority Tier — concevez autour de tout cela.
• Ne réessayez que les erreurs transitoires (429/5xx/529) avec backoff, jitter et retry-after ; ne réessayez que les écritures idempotentes.
• Le repli n’est pas gratuit — depuis Fable 5.1 les thinking blocks sont écartés ; Haiku 4.5 est à 200k, non 1M ; validez le chemin dégradé.
• Dimensionnez le débit temps réel au regard de l’ITPM/RPM (la limite de tokens lie souvent en premier) ; utilisez le Batch API pour la masse tolérante à la latence ; fixez des timeouts de frontière et renvoyez des résultats partiels avec provenance.
• Supervisez la latence p95/p99, le taux d’erreur par catégorie, le taux de succès du cache et le coût par tâche ; barrez les actions irréversibles sur des humains.