Les Core 4 & Dépenser ses tokens intelligemment

Les Core 4 : Modèle, Prompt, Outils, Contexte

L’idée en une phrase

Tout run d’un agent se règle sur quatre primitives — les Core 4 : le Modèle, le Prompt, les Outils et le Contexte. Trois d’entre elles (Prompt, Outils, Contexte) occupent la fenêtre et sont donc le terrain direct de Reduce ; la quatrième, le Modèle, ne consomme aucun token mais fixe la taille de la fenêtre et la qualité de l’attention. Connaître les Core 4, c’est disposer de la carte de l’endroit où partent les tokens — préalable à toute décision de réduire ou de déléguer.

Analogie : une cuisine avant le service. Le Modèle, c’est le tour de main du cuisinier ; le Prompt, la recette qu’on lui donne ; les Outils, les ustensiles posés sur le plan de travail ; le Contexte, les ingrédients sortis du frigo. Un plan de travail encombré de vingt ustensiles et de tout le garde-manger ralentit le meilleur des cuisiniers. Ne sortir que la casserole et les trois ingrédients de la recette, c’est déjà appliquer Reduce.

Points clés

• Core 4 = Modèle, Prompt, Outils, Contexte. C’est le cadre de lecture de tout ce que « voit » l’agent. Trois primitives se logent dans la fenêtre de contexte ; une seule, le Modèle, se choisit en amont de la fenêtre.
• Les Outils ne sont pas gratuits. Chaque outil activé — outil natif, serveur MCP — charge sa définition (nom, description, schéma JSON des arguments) dans la fenêtre, qu’on l’appelle ou non. Un serveur MCP bien fourni peut ajouter des dizaines de milliers de tokens de définitions avant le premier appel. C’est un poste de Reduce majeur, détaillé au prochain chapitre.
• Le Prompt a deux étages : le prompt système (le rôle, les règles — incompressible, à peu près fixe) et le prompt utilisateur (la demande — là où la précision paie). Le context engineering agit surtout sur le second.
• Le Modèle décide la fenêtre. Il fixe sa taille (~200 000 tokens, extensible à ~1M sur certains modèles) et, à remplissage égal, sa tenue de l’attention (les lois d’échelle inverses du chapitre 2 valent pour tous). On le choisit par tâche et on en change par /model ou --model.
• /context est la projection des Core 4 sur la fenêtre : le poste prompt système renvoie au Prompt, les postes outils système et outils MCP aux Outils, les postes mémoire (CLAUDE.md) et messages au Contexte. Le Modèle, lui, n’y apparaît pas en tokens : il en fixe le cadre.

Exemple concret

Un /context en début de session, sur un projet chargé « au cas où », peut afficher : prompt système et outils natifs ~15 000 tokens (primitives Prompt + Outils), deux serveurs MCP ~28 000 (Outils), un CLAUDE.md fourre-tout ~8 000 et six fichiers pré-lus ~30 000 (Contexte) — soit ~81 000 tokens, ~40 % d’une fenêtre de 200k, avant la première question. Rapporté aux Core 4, le diagnostic est net : le Modèle ne pèse aucun token (il fixe la fenêtre, pas son remplissage), le Prompt système est incompressible, mais Outils et Contexte cumulent ~66 000 tokens en grande partie évitables. Retirer un serveur MCP inutile à la tâche (~14 000) et quatre fichiers non essentiels (~20 000) ramène l’occupation sous 24 % — sans changer ni le modèle ni le prompt.

Le Core 4 face à la fenêtre

Primitive	Ce que c’est	Où ça se voit dans /context	Levier R&D
Modèle	Le moteur : taille de fenêtre, finesse d’attention	Nulle part (0 token) — il fixe le cadre	Choisir la bonne cylindrée par tâche
Prompt	Système (rôle, règles) + utilisateur (la demande)	Poste prompt système	Reduce sur l’utilisateur : précis, pas verbeux
Outils	Définitions des outils natifs et MCP chargées	Postes outils système et outils MCP	Reduce : n’activer que l’utile (chapitre 4)
Contexte	CLAUDE.md, fichiers lus, historique	Postes mémoire et messages	Reduce et Delegate : n’amener que le signal

Commande — choisir et situer le Modèle

# Le Modele est la 4e primitive : il fixe la taille de fenetre (~200k, extensible ~1M)
# et la tenue de l'attention a remplissage egal (cf. lois d'echelle inverses, chapitre 2).
claude --model sonnet          # choisir un modele au lancement (l'alias reste stable)

# En session, basculer de modele sans repartir de zero (commande CLIENTE, tapee dans le REPL) :
/model
# Regle de poche : un modele leger pour une tache simple, un modele fort pour du raisonnement lourd.
# Le Modele ne consomme aucun token de la fenetre — il en decide la taille et la finesse.

Piège courant : « un outil ne coûte rien tant qu’on ne l’appelle pas » est inexact. La définition de chaque outil activé occupe la fenêtre en permanence, appel ou non. Brancher trois serveurs MCP « au cas où », c’est charger leurs schémas — souvent des dizaines de milliers de tokens — qui diluent l’attention avant le premier appel. L’outil se paie à l’activation, pas à l’usage.

---

Dépenser ses tokens intelligemment pour une exécution du premier coup

L’idée en une phrase

Tous les tokens ne se valent pas : certains augmentent la probabilité de réussir du premier coup (fort signal — une spécification précise, les fichiers exacts, un exemple), d’autres ne font que remplir la fenêtre (faible signal — du bruit). Dépenser intelligemment, ce n’est donc pas dépenser peu, c’est maximiser la probabilité de 1-shot par token : c’est la fonction-objectif que servent Reduce et Delegate.

Analogie : préparer un sac pour une longue randonnée. Le sac le plus léger échoue — sans eau, on n’atteint pas le sommet ; le plus lourd échoue aussi — on s’épuise sous la charge. Le bon sac n’est ni l’un ni l’autre : il ne contient que ce qui augmente les chances d’arriver en haut, chaque objet devant justifier son poids. Un contexte se prépare comme ce sac : au signal, pas au volume.

Points clés

• Valeur inégale des tokens. Fort signal : une spec claire, un critère d’acceptation, les 2-3 fichiers concernés, un exemple travaillé. Faible signal : fichiers hors sujet, documentation verbeuse, historique redondant. Le premier fait gagner le 1-shot ; le second le sabote.
• Dépenser intelligemment ≠ dépenser peu. Une fenêtre quasi vide avec un prompt vague échoue tout autant qu’une fenêtre saturée. La cible est la densité de signal, pas la rareté.
• Le coût de l’échec est caché. Chaque tour de correction relit le contexte, rallonge l’historique et dilue un peu plus l’attention (chapitre 2). Une spec de 400 tokens qui achète un 1-shot bat trois tours de reprise qui, cumulés, coûtent bien davantage.
• C’est le pourquoi de R&D. Reduce coupe les tokens à faible signal du Prompt, des Outils et du Contexte ; Delegate déporte le traitement bruyant. Les deux existent pour que la fenêtre reste majoritairement du signal.
• Règle avant de charger quoi que ce soit : « ce token augmente-t-il mes chances de réussir du premier coup ? » Si non, on le coupe (Reduce) ou on le délègue (Delegate).

Exemple concret

Même tâche — ajouter la pagination à une API — deux façons de dépenser la fenêtre de 200k :

• Dépense « à l’aveugle » : un prompt vague (« améliore l’API », ~50 tokens) et 18 fichiers chargés « au cas où » (~45 000 tokens). L’agent part dans une mauvaise direction ; trois tours de correction s’enchaînent, chacun relisant le contexte et allongeant l’historique — ~150 000 tokens cumulés sur la session, une fenêtre poussée au-delà de 70 %, et un résultat encore à reprendre.
• Dépense « à fort signal » : une spécification précise + un critère d’acceptation (~400 tokens), les 3 fichiers réellement concernés (~8 000 tokens) et un exemple travaillé (~1 200 tokens) — soit ~10 000 tokens (~5 %). L’agent exécute la tâche du premier coup.

La seconde dépense est à la fois plus petite et plus efficace ; mais l’essentiel n’est pas qu’elle soit plus petite — c’est qu’elle place des tokens à fort signal là où ils font basculer le 1-shot. Même plus chère en amont, elle resterait gagnante face au coût caché des boucles de correction.

La valeur d’un token

Ce qu’on charge	Coût	Signal	Effet sur le 1-shot	Verdict R&D
Spec précise + critère d’acceptation	~400 tokens	Fort	↑	Dépenser
Les 3 fichiers concernés	~8 000 tokens	Fort	↑	Dépenser
Un exemple travaillé	~1 200 tokens	Fort	↑	Dépenser
15 fichiers « au cas où »	~40 000 tokens	Bruit	↓ (dilution)	Reduce
Doc HTML brute, 5 pages	~40 000 tokens	Faible	↓	Delegate (résumé ~1 500)

Commande — rendre la dépense délibérée

# Protocole de depense : dans le REPL, avant de charger le contexte d'une tache.
# 1. Ecrire d'abord la SPEC : une phrase + un critere d'acceptation verifiable (fort signal).
# 2. Ne charger QUE les fichiers qui augmentent la chance de 1-shot (les couper sinon).
# 3. Deleguer le bruit incompressible (doc, scraping) a un sous-agent — il ne rend qu'un resume.
# 4. Verifier le budget obtenu :
/context
# On ne cherche pas la fenetre la plus vide, mais la plus dense en signal.

Piège courant : « dépenser peu de tokens, c’est toujours mieux » est inexact. L’objectif n’est pas le minimalisme mais la probabilité de réussite du premier coup. Un contexte trop maigre — prompt vague, fichier-clé manquant — échoue aussi sûrement qu’un contexte saturé. Le bon point de fonctionnement est une forte densité de signal, pas la disette.

---

Fil rouge — Reduce ou Delegate ?

Ce chapitre relie les deux leviers à leur raison d’être. Les Core 4 dressent la carte de l’endroit où partent les tokens — Prompt, Outils et Contexte occupent la fenêtre, le Modèle la dimensionne ; dépenser intelligemment en est la fonction-objectif. Reduce retire les tokens à faible signal de ces trois postes ; Delegate déporte le traitement bruyant vers un contexte isolé. L’impact se chiffre : une fenêtre à ~10 % de tokens à fort signal garde une attention dense et réussit du premier coup, là où la même tâche « à l’aveugle » à ~40-70 % de bruit part en boucles de correction. On ne vise pas la fenêtre la plus vide, mais celle où chaque token gagne sa place.

---

---

Travaux pratiques

À chaque leçon, un petit artefact à déposer dans ton .claude/ — commande, sous-agent, hook, mémo… — pour te bâtir, au fil du livre, une boîte à outils de context engineering réutilisable.

Une commande maison — /core4

Ce chapitre donne une carte : autant en faire un réflexe de pré-vol. Cette commande slash, à déposer dans .claude/commands/core4.md, force l’agent à poser les Core 4 avant d’agir — choisir le modèle, cadrer le prompt, n’activer que les outils utiles, budgéter le contexte — et à chiffrer le total en tokens. C’est Reduce appliqué aux quatre primitives à la fois : rien n’entre dans la fenêtre sans avoir gagné sa place.

---
description: Pré-vol Core 4 — poser Modèle, Prompt, Outils, Contexte avant d'agir.
argument-hint: [la tâche]
---

Avant d'agir sur : $ARGUMENTS — pose explicitement les Core 4, sans rien exécuter encore :

1. **Modèle** — quel modèle pour cette tâche (léger si simple, fort si raisonnement lourd), et pourquoi.
2. **Prompt** — reformule la tâche en une phrase, puis donne un critère d'acceptation vérifiable.
3. **Outils** — la liste minimale d'outils/MCP réellement nécessaires ; nomme ce que tu n'actives PAS.
4. **Contexte** — les 1 à 3 fichiers à charger, avec une estimation en tokens (~1 token pour 4 caractères).

Termine par le budget total estimé (tokens et % d'une fenêtre de 200k), puis attends mon feu vert.

Invoque-la par /core4 ajoute la pagination à l'API. En quelques lignes, l’agent choisit sa cylindrée, cadre le prompt, écarte les outils inutiles et budgète le contexte — souvent quelques milliers de tokens à fort signal au lieu d’une fenêtre remplie au hasard, et une attention gardée dense pour réussir du premier coup.