Sessions Claude Code : une session pilote par jour, pas une par tâche

Ce que relisent vos sessions Claude Code à chaque message

Claude ne se souvient de rien entre deux messages : il relit toute la conversation à chaque fois. La page de la documentation sur les coûts le dit à sa façon : la conversation entière repart avec chaque requête. Or une requête, ce n'est pas seulement votre message. Chaque fois que Claude lance un outil (lire un fichier, exécuter une commande, par exemple), il y a une nouvelle requête, et donc une nouvelle relecture. Certes, le cache de prompt fait payer ces relectures moins cher, mais elles comptent quand même.

Ce que relisent vos sessions Claude Code se range alors en deux piles :

• le socle, chargé avant même votre premier mot : le prompt système, les CLAUDE.md, l'index de la mémoire, les descriptions des skills, la liste des outils. La page sur la fenêtre de contexte détaille ce qui entre au démarrage ;
• la conversation, qui grossit à chaque échange : vos messages, les réponses, les fichiers lus, les sorties de commandes.

Voici un ordre de grandeur réel. Le 9 novembre 2026, sur la session du studio, juste après un /compact, la carte Contexte de l'application de bureau affichait :

C'est un relevé, pas une norme, car votre socle dépend de vos fichiers, de vos skills et des connecteurs branchés. En revanche, l'arbitrage vaut partout. Une session neuve repaie tout le socle. Une session longue fait relire toute sa conversation à chaque requête. (Pour alléger le socle lui-même, c'est l'objet de mon relevé sur les tokens économisés.)

Ce que chaque session relit

• La session pilote porte son socle et toute la journée empilée dessus. Par conséquent, chaque tâche ajoutée alourdit toutes les requêtes suivantes.
• Le sous-agent démarre avec un socle partiel et un brief écrit par Claude, lit ce qu'il a à lire, rend une conclusion, puis disparaît. Ses lectures n'entrent donc jamais dans la session pilote.
• La sous-session « fresh » repaie le socle, mais sa pile de conversation part de zéro : elle ne sait que ce que dit son brief.
• La sous-session « fork » repaie le socle et reçoit aussi une copie de toute la conversation. Elle sait tout, mais elle relit tout.

Les deux pièges des sessions Claude Code

Une session par tâche. C'était ma façon de faire. Chaque session repaie les 76k du socle, même pour une question à trois messages. Ensuite, quand l'option worktree est cochée, chaque session a sa propre copie du dépôt (j'y reviens), qu'il faut créer puis nettoyer. Pour les petites tâches, c'est donc le mode le plus cher.

Une seule session toute la journée. Le réflexe inverse, tout aussi mauvais. La conversation grossit sans arrêt, chaque requête coûte plus que la précédente, et la compaction finit par passer. D'abord, /compact résume la conversation pour faire de la place, et Claude Code le fait tout seul quand la fenêtre se remplit. Mais un résumé perd du détail. Pire, après une compaction, Claude ne sait plus exactement ce que contenaient les fichiers qu'il avait lus. Ainsi, s'il modifie un fichier sans le relire, il travaille sur un souvenir.

La journée type

1. Le matin, une session pilote. Dans le projet du jour, ou alors dans un dossier commun si la journée touche plusieurs projets.
2. Petite tâche (moins de trois fichiers touchés, une question, une vérification) : dans la session pilote. Ainsi, pas de socle à repayer, ni de copie du dépôt à créer.
3. Lecture, recherche, inventaire (fouiller trente fichiers, comparer des journaux, relire de la documentation) : un sous-agent de lecture. Ce qu'il lit reste chez lui, et seule sa conclusion revient.
4. Vraie tâche autonome (une fonctionnalité, un projet à déplacer, un skill à améliorer) : une sous-session « fresh ». Elle repaie le socle, mais part d'une pile courte. En parallèle, pas de plafond magique : chez moi, une huitaine de sessions et d'agents tournent toute la journée, en wifi. Sur une connexion mobile partagée, en revanche, c'est l'envoi qui sature d'abord, car chaque session renvoie son contexte à chaque requête.
5. Sous-session finie : on l'archive.
6. Session pilote qui s'alourdit : /compact au changement de sujet. Enfin, après deux compactions, une session neuve vaut mieux.

Les quatre types de session, côte à côte

Où va cette tâche ?

Quatre questions, dans l'ordre, et le premier oui gagne. Sinon, on passe à la suivante.

L'arbre de décision

1. Moins de trois fichiers, ou une simple question ? Session pilote.
2. La tâche ne fait que lire ? Sous-agent de lecture.
3. Le contexte tient en trois phrases ? Sous-session « fresh ».
4. La conversation est encore courte ? Sous-session « fork ». Sinon, session pilote.

La règle courte, celle que je retiens : si Claude doit expliquer longuement le contexte, la tâche reste dans la session pilote. Si trois phrases suffisent, elle part.

Sous-agents et sous-sessions : ce que fait l'outil

Le sous-agent

Le sous-agent est décrit dans la documentation des sous-agents : il travaille dans sa propre fenêtre de contexte, sans l'historique de la conversation, et seul son résumé revient à la session principale. On peut aussi lui fixer un modèle (un modèle moins cher pour lire, par exemple) et restreindre ses outils, en lecture seule. Ça marche au terminal comme dans l'application de bureau. Pour ma part, j'en ai un pour la lecture et un pour la relecture : le premier fouille, puis le second relit un livrable avec un autre regard que celui qui l'a écrit.

La sous-session, dans l'application de bureau

La sous-session, c'est mon nom pour une session lancée depuis une autre, dans l'application de bureau. La doc de l'application décrit la porte d'entrée. Quand Claude repère une tâche hors du sujet en cours, il la propose sous forme de carte, avec deux boutons. D'un côté, « Démarrer » la lance dans une autre session, rangée sous la session courante dans la barre latérale. De l'autre, « Le faire ici » la garde dans la conversation. Les sessions peuvent également s'envoyer des messages, et Claude peut lire ce qu'une autre a conclu.

Ce que j'ai constaté en plus, en novembre 2026, n'est pas décrit dans la doc à la date où j'écris. Au lancement, Claude choisit de passer à la nouvelle session toute la conversation (« fork ») ou seulement un brief qu'il rédige (« fresh »). Ensuite, la sous-session renvoie un court compte rendu à la session pilote quand elle a fini un tour. Au terminal, l'équivalent le plus proche est la commande /fork, qui copie la conversation dans une session en arrière-plan (voir la liste des commandes).

Le worktree

Une sous-session qui touche du code travaille en général dans un worktree : une copie de travail du dépôt, sur sa propre branche, pour ne pas marcher sur les fichiers de la session pilote. Au terminal, c'est l'option --worktree (page worktrees). Dans l'application, en revanche, c'est une case à cocher par session. La tâche finie, son commit est fusionné dans la branche principale du dépôt, puis on archive la session. Ensuite, d'après la doc de l'application, la copie reste sur le disque, puis disparaît une trentaine de jours plus tard. J'ai d'ailleurs décrit ce qui arrive quand ces copies de travail vivent dans un dossier synchronisé.

Ce que les sous-agents n'économisent pas

Un sous-agent n'est pas gratuit, parce qu'il consomme ses propres tokens : son socle, son brief, tout ce qu'il lit. La doc le précise, ses requêtes comptent dans les limites d'usage. Pourtant, il économise le contexte de la session pilote. Sans lui, les trente fichiers fouillés resteraient dans la conversation, et chaque requête suivante de la journée les relirait. Avec lui, au contraire, ils sont lus une fois, ailleurs, et seule une page de conclusion revient.

Donc :

• gros gain quand la lecture est volumineuse et que la session pilote continue longtemps après ;
• aucun gain pour lire un fichier ou deux : le sous-agent repaie un socle pour rien ;
• perte nette si on lui demande une conclusion floue et qu'il faut relire derrière lui.

Le piège du « fresh », et un cas réel

Une sous-session « fresh » ne sait que ce qui est dans son brief. C'est à la fois sa force (une pile courte) et son piège. Car si la tâche dépend d'une décision prise à l'oral dans la session pilote, et que le brief l'oublie, elle la redécouvre ou se trompe. C'est pourquoi une tâche qui découle directement de ce qu'on vient de trouver reste dans la session pilote, ou part en « fork » tant que la conversation est courte.

Le cas qui m'a fait écrire la règle date du 9 novembre. Ma session pilote venait d'être compactée, après une matinée sur un tableau de bord et une mise en ligne. Je demande alors d'améliorer un skill, en mode plan, pour lui ajouter une source, un compte et une exception. L'application propose de démarrer la tâche dans une session dédiée ou de la faire ici. Finalement, j'ai choisi la session dédiée :

• la demande tenait en quelques phrases (le skill visé, la source, le compte, l'exception) : critère des trois phrases rempli ;
• ce qui précédait n'avait aucun rapport : 41,8k de conversation à relire à chaque requête, pour rien ;
• c'était une vraie tâche : un skill modifié, son propre commit, sa propre branche ;
• le mode plan a suivi dans la nouvelle session : plan en texte, validation, puis écriture.

Le cas inverse, par exemple : « corrige ce qu'on vient de pousser ». Là, tout le contexte utile est dans la session pilote, donc la tâche y reste.

Et après

J'organise mes sessions Claude Code de cette façon depuis le 24 octobre, et la règle des trois phrases date du 9 novembre. Cependant, je n'ai pas encore de mesure avant/après sur un mois complet : je la publierai quand je l'aurai.

L'autre moitié du travail, c'est ensuite d'alléger le socle lui-même : CLAUDE.md court, mémoire triée, extensions inutiles coupées. Tout est dans Économiser des tokens Claude Code : 5 mois de mesures.

JG