Gestion de la fenêtre de contexte
Découvrez comment fonctionne la fenêtre de contexte de 270 000 tokens de Bob, comment chaque catégorie contribue à l'utilisation des tokens, et les bonnes pratiques pour garder les sessions ciblées et rentables.
Vue d'ensemble de la fenêtre de contexte
Chaque session dans Bob Shell possède une fenêtre de contexte — le budget de tokens pour cette conversation. La limite est de 270 000 tokens. Tout ce que Bob charge est comptabilisé.
Ce qui remplit la fenêtre
| Catégorie | Ce qu'elle contient |
|---|---|
| Prompt système | Les instructions de base de Bob pour la session |
| Définitions d'outils | Schémas des outils intégrés et définitions des outils MCP connectés |
| Outils MCP | Instructions et descriptions des outils fournis par les serveurs MCP connectés |
| Règles | Instructions personnalisées provenant des fichiers de règles de projet et de mode (par exemple, AGENTS.md ou .bob/rules-*) |
| Skills | Instructions des skills chargés par Bob pour la conversation |
| Messages | Vos prompts, les réponses de Bob et l'activité des outils dans la conversation. C'est la transcription comptabilisée en tokens. |
La sortie des commandes et les résultats des outils sont comptabilisés dans les Messages. Le contenu des fichiers n'a pas de ligne séparée.
Le rapport de tokens comprend deux champs récapitulatifs :
- Réservé pour la réponse du modèle : Tokens mis de côté pour la prochaine réponse de Bob (généralement 20,0k).
- Espace disponible : Tokens libres restants.
Surcharge de base
Les catégories fixes utilisent du contexte avant même que vous commenciez à travailler avec Bob. Même un simple "Dis juste bonjour." totalise environ 8,5k tokens. La majeure partie correspond aux Définitions d'outils (5,1k), au Prompt système (1,5k), aux Règles (830) et aux Skills (454). Seulement 590 se trouvent dans les Messages.
Bob renvoie l'ensemble de la surcharge à chaque prompt. Plus de serveurs MCP ou de skills chargés augmentent les Outils MCP, les Définitions d'outils et les Skills avant même que vous tapiez.
Surveiller votre utilisation des tokens
Bob Shell rapporte l'utilisation des tokens à la fin de chaque échange. Le tableau suivant montre ce qui influence chaque catégorie :
| Catégorie | Ce qui la fait croître |
|---|---|
| Prompt système | Chargé au démarrage de la session. Reste stable pendant le travail normal. |
| Définitions d'outils | Schémas des outils intégrés. Définis au démarrage de la session. Restent stables pendant le travail normal. |
| Outils MCP | Serveurs MCP connectés et outils activés. Augmente quand vous ajoutez des serveurs ou des outils, pas quand vous envoyez des prompts. |
| Règles | Fichiers de règles de projet et de mode (par exemple, AGENTS.md). Définis à l'ouverture de la session. |
| Skills | Skills chargés par Bob pour la session. Peut augmenter si Bob active un skill en cours de conversation. |
| Messages | Vos prompts, les réponses de Bob, les lectures de fichiers, la sortie des outils et des commandes. Augmente à chaque échange et lors de l'exploration du dépôt. |
Dans un échange court, les catégories fixes occupent souvent la majeure partie du total. Quand vous demandez à Bob de lire des fichiers ou d'utiliser des outils, les Messages deviennent généralement la catégorie la plus importante. Surveillez ce changement.
L'espace disponible diminue à mesure que n'importe quelle catégorie augmente. Réservé pour la réponse du modèle est mis de côté pour la prochaine réponse de Bob. Il ne fait pas partie du total utilisé ci-dessus.
Limites des tokens
La limite stricte est de 270 000 tokens par session. Bob commence à condenser avant d'atteindre la limite. La condensation commence généralement autour de 190 000 tokens d'utilisation totale.
Condensation automatique du contexte
Au seuil de condensation, Bob :
- Préserve le contexte le plus récent et le plus pertinent.
- Résume ou supprime les segments de conversation plus anciens.
- Maintient les instructions système critiques, les définitions d'outils, les règles et les skills.
- Continue avec le contexte condensé.
La condensation est avec perte. Les détails du début des Messages peuvent ne pas survivre. Démarrez une nouvelle session quand vous changez de sujet ou quand les Messages sont suffisamment volumineux pour nuire à la qualité.
Impact sur les Bobcoins
Les Bobcoins suivent l'utilisation des tokens. Les tokens en entrée et en sortie sont tous deux comptabilisés.
- Chaque message renvoie l'intégralité du contexte actif, y compris la surcharge fixe.
- Bob retraite ce qui est déjà chargé à chaque envoi.
- Les longues sessions avec des Messages importants coûtent plus cher par prompt ultérieur.
Bonnes pratiques
La fenêtre de contexte n'est pas un espace de stockage. C'est de la mémoire de travail — ce que Bob peut utiliser à chaque étape. Contrôlez ce qui y entre. Réinitialisez quand la session se remplit de sorties obsolètes. Vérifiez le résultat avec des tests, pas seulement la réponse de Bob.
Cadrer la session et la conversation
Utilisez une session par objectif de travail et commencez par un prompt ciblé. Énoncez l'objectif, le résultat attendu et les contraintes avant de demander à Bob d'explorer le dépôt. Nommez explicitement les fichiers et les fonctions. Évitez les demandes vagues comme « lis tout le dépôt » ou « vérifie le backend ». Démarrez une nouvelle session quand le sujet change — un contenu non pertinent dans les Messages augmente les coûts et peut perturber Bob.
Garder le contexte permanent léger
Les catégories fixes consomment des tokens avant même que vous tapiez. Pour maintenir cette surcharge basse :
- Gardez les règles personnalisées et
AGENTS.mdcourts — n'y mettez que les commandes de configuration, de test et de style (par exemple,pnpm test,mvn verify). - Connectez uniquement les serveurs MCP, les outils et les skills dont le travail en cours a besoin. Déconnectez ce que vous n'utilisez pas, et préférez la configuration MCP au niveau projet plutôt que globale.
- Réservez les Messages pour les preuves situationnelles spécifiques à cette session — le bug, les logs et les fichiers pertinents. Ne répétez pas les règles permanentes dans chaque prompt.
Ajouter du contexte quand vous en avez besoin
Laissez Bob rechercher et lire des fichiers ciblés plutôt que de coller de grands blocs de contenu dans le prompt de chat. Référencez des chemins de fichiers et des plages de lignes spécifiques dans votre prompt, et évitez les références à des répertoires larges :
✓ Corrige la logique de validation d'email dans src/utils/validation.ts lignes 45-67
✗ Examine tout dans src/, tests/ et docs/ et suggère des améliorationsTravaillez par étapes — trouvez les fichiers probables, inspectez les pertinents, planifiez, modifiez et validez. Pour les lectures larges de dépôt, utilisez des sous-agents afin que la session reçoive des résultats condensés plutôt que chaque appel read_file dans les Messages. En cas de conflits entre les sources, faites confiance au code et aux tests exécutables plutôt qu'aux commentaires obsolètes ou aux anciennes notes de README.
Pour plus de tactiques sur les grands dépôts, consultez Travailler avec de grands projets.
Réinitialiser quand les Messages se remplissent
Au cours d'une longue session, les Messages accumulent des contenus de fichiers répétés, des plans abandonnés et des sorties d'outils périmées. Démarrez une nouvelle session quand l'objectif de travail change ou quand la conversation est suffisamment volumineuse pour nuire à la qualité. Conservez les contraintes, les preuves et les questions ouvertes — supprimez le reste.
Bob peut également condenser les anciens segments automatiquement, mais la condensation est avec perte et les détails du début des Messages peuvent ne pas survivre. Préférez de petits changements approuvés plutôt qu'une longue exécution autonome pour que les diffs restent vérifiables et que Bob reste sur la bonne voie.