Réduire la consommation de tokens d'OpenClaw

Fait partie du pilier réduire l'usage des tokens d'un agent de code. Cette page traite du contrôle des coûts ; ce qu'est OpenClaw et ce qu'il coûte est l'explicatif.

Comment réduire la consommation de tokens d'OpenClaw ?

Réduisez d'abord ce qui est injecté à chaque exécution, avant de toucher à quoi que ce soit d'autre : OpenClaw reconstruit son prompt système à partir de vos fichiers de bootstrap à chaque tour, donc un AGENTS.md obèse n'est pas payé une fois, il est repayé pendant toute la durée de la session. C'est la propriété qui rend le profil de coût d'OpenClaw différent de celui d'un agent de code par session. Il assemble son propre prompt à chaque exécution au lieu d'en reporter un, et ce prompt inclut vos fichiers de travail, la liste des outils et celle des skills. Tout ce que vous mettez dans ces fichiers est un abonnement. La bonne nouvelle : OpenClaw expose de vrais plafonds chiffrés pour tout cela, avec des valeurs par défaut documentées. La plupart des conseils qu'on trouve sur cet outil portent sur le choix du modèle. Les plafonds pèsent davantage.

Pourquoi OpenClaw consomme-t-il des tokens ?

Parce que quatre choses distinctes sont renvoyées ou relues à intervalles réguliers, et qu'une seule est la conversation. D'après la référence token-use d'OpenClaw, le prompt système de chaque exécution transporte :

• la liste des outils avec leurs descriptions courtes,
• la liste des skills en métadonnées (les instructions se chargent à la demande),
• les instructions d'auto-mise à jour,
• vos fichiers de travail et de bootstrap — AGENTS.md, SOUL.md, IDENTITY.md, USER.md, BOOTSTRAP.md quand il est neuf, et MEMORY.md s'il existe,
• l'heure, les balises de réponse, le comportement de heartbeat et les métadonnées d'exécution.

S'y ajoutent, dans la fenêtre de contexte : l'historique de conversation, les appels d'outils et leurs résultats, les pièces jointes et transcriptions, les résumés de compaction, et des enveloppes fournisseur que vous ne voyez jamais. Le repère à garder : OpenClaw compte des tokens, pas des caractères, et la plupart des modèles de style OpenAI tournent autour de quatre caractères par token en anglais. Un AGENTS.md de 20 000 caractères pèse donc de l'ordre de 5 000 tokens, à chaque tour.

Quels plafonds contrôlent réellement tout ça ?

Cinq, et leurs valeurs par défaut sont publiées. Les deux nombres de bootstrap sont à regarder en premier. Un plafond par défaut de 60 000 caractères d'injection cumulée représente environ 15 000 tokens de prompt permanent avant que la conversation ne commence. Si vos fichiers de travail approchent ce plafond, vous le payez à chaque tour, et l'abaisser est un changement d'une ligne à effet immédiat et durable. imageMaxDimensionPx compte plus qu'il n'y paraît sur un travail chargé en captures d'écran. Des valeurs basses réduisent directement les tokens de vision et la taille des payloads ; des valeurs hautes achètent un détail OCR dont vous n'avez souvent pas besoin. Les résultats d'outils ont un plafond qu'OpenClaw dérive du modèle et non de votre configuration : 16 000 caractères sous une fenêtre de 100K, 32 000 à partir de 100K, et 64 000 à partir de 200K. Un garde-fou d'exécution limite en plus tout résultat d'outil isolé à 30 % de la fenêtre de contexte. Ce sont des plafonds, pas des objectifs : un résultat qui arrive juste en dessous reste une ligne énorme.

Quel réglage retarife silencieusement une requête ?

L'opt-in long contexte. Franchir un seuil d'entrée peut retarifer la requête entière, pas seulement les tokens au-dessus de la ligne. C'est la chose la plus coûteuse de la documentation d'OpenClaw, et on y tombe facilement. Les modèles OpenAI GPT-5.5 et GPT-5.6 en direct publient une fenêtre totale de 1 050 000 tokens. OpenClaw plafonne délibérément leur budget d'exécution par défaut à 272 000 tokens. Le budget d'entrée optionnel de 922 000 tokens réserve l'allocation de sortie complète de 128 000. Le piège, dans les termes d'OpenClaw : OpenAI applique la tarification long contexte à la requête entière dès que l'entrée dépasse 272 000 tokens. Pas au dépassement. À tout. Une session qui dérive d'un token au-delà de cette frontière ne paie donc pas un peu plus : elle retarife tout ce qu'elle vient d'envoyer. Qu'OpenClaw n'active pas la grande fenêtre automatiquement est une décision de coût assumée de leur part, et la contourner est une décision à prendre exprès, avec une raison, pas parce qu'un plus grand nombre faisait meilleur effet dans un fichier de configuration. Côté Anthropic, c'est moins spectaculaire : OpenClaw dimensionne déjà les modèles Claude 4.x éligibles avec la fenêtre de 1M, donc params.context1m: true n'est plus nécessaire pour eux, et l'identifiant doit être éligible sous peine d'une erreur de limite côté fournisseur.

Comment voir où sont partis les tokens ?

/context detail pour le prompt, /usage pour le tour, /usage cost pour la session. Quatre commandes, quatre questions différentes :

• /context list et /context detail décomposent le prompt lui-même : par fichier injecté, outils, skills, et taille totale du prompt système. C'est la première à lancer, parce qu'elle dit si votre coût permanent est le problème avant que vous n'alliez optimiser la conversation.
• /status donne une carte d'état : modèle de session, usage du contexte, tokens d'entrée/sortie de la dernière réponse, et coût.
• /usage tokens ajoute un pied de page par réponse avec le détail tokens et cache du tour ; /usage full y ajoute modèle, contexte et coût. Le réglage persiste par session, et /usage reset le remet au défaut configuré.
• /usage cost résume le coût à partir des journaux de session d'OpenClaw.

Une réserve à connaître avant de faire confiance au chiffre en dollars : en authentification OAuth, le système masque les coûts et n'affiche que les compteurs de tokens. Sur une installation OAuth, les tokens sont votre monnaie.

Et le cache, et le heartbeat ?

La rétention de cache est configurable par agent, et le heartbeat existe en partie pour garder un cache long au chaud. OpenClaw expose cacheRetention dans les params d'un modèle, et agents.entries.*.params se superpose aux défauts du modèle sélectionné : vous pouvez donc surcharger la seule rétention et hériter du reste. Leur exemple documenté est parlant sur l'intention : un agent research avec heartbeat: every: "55m" pour garder le cache long au chaud sur les sessions profondes, et un agent alerts en cacheRetention: "none" pour éviter les écritures de cache sur des notifications en rafale. C'est la bonne intuition généralisée : le cache paie sur les contextes longs et répétitifs, et coûte sur les courts et sporadiques. Un assistant toujours actif avec des tâches programmées fait tourner les deux formes en même temps, ce qui justifie de régler la rétention par agent plutôt que globalement.

Comment appliquer ça dès aujourd'hui

1. Lancez /context detail avant de changer quoi que ce soit. Il faut savoir si le problème est votre prompt permanent ou votre conversation. Deviner ici coûte l'après-midi.
2. Mesurez vos fichiers de bootstrap. Comptez les caractères, divisez par quatre pour une estimation en tokens. Face à un plafond par défaut de 60 000 caractères, la réponse saute généralement aux yeux.
3. Réduisez AGENTS.md et MEMORY.md à ce dont l'agent a besoin à chaque tour. Le reste appartient derrière un outil de mémoire ou une skill, chargé à la demande. Le test est simple : cette phrase change-t-elle le comportement de l'agent sur un tour typique ? Sinon, c'est du loyer.
4. Abaissez bootstrapMaxChars et bootstrapTotalMaxChars à un plafond que vous avez choisi, pas à celui dont vous avez hérité.
5. Baissez imageMaxDimensionPx si vous collez des captures. 1200 est généreux pour la plupart des travaux d'interface.
6. Laissez le budget long contexte tranquille sans raison mesurée, et rappelez-vous que franchir 272 000 tokens d'entrée retarife toute la requête sur GPT-5.5/5.6.
7. Réglez cacheRetention par agent : long pour les sessions profondes, aucun pour les rafales.
8. Utilisez /compact sur les sessions longues plutôt que de laisser l'historique s'accumuler.

Ce qui cloche en pratique (anti-patterns)

Traiter AGENTS.md comme de la documentation. Ce n'est pas un README, c'est un abonnement par tour. Les équipes l'écrivent une fois, longuement, et n'y reviennent jamais : un document d'accueil réfléchi devient la plus grosse ligne fixe de la facture. Optimiser le modèle avant le prompt. Changer pour un modèle moins cher multiplie un nombre que vous n'avez pas mesuré. Retirer 30 000 caractères d'injection permanente le réduit. Faites le second d'abord. Activer la grande fenêtre parce qu'elle existe. Le budget d'entrée de 922 000 tokens est optionnel pour une raison, et la retarification porte sur la requête entière, pas sur le dépassement. Lire un plafond de résultat d'outil comme un budget. 64 000 caractères, c'est le seuil au-delà duquel OpenClaw tronque, pas une quantité raisonnable de sortie de commande à mettre devant un modèle. Filtrer à la source coûte moins cher que se faire tronquer à la frontière — voir filtrer la sortie des commandes. Croire que les plafonds couvrent les relectures. Ils bornent la taille d'une injection ou d'un résultat d'outil. Ils ne font rien contre le même fichier qui entre onze fois dans le contexte au cours d'une session, autre problème et autre remède — comment mesurer l'usage des tokens d'un agent traite de sa détection.

---

À lire aussi :

• Réduire l'usage des tokens d'un agent de code — le pilier
• OpenClaw : ce que c'est et ce que ça coûte — l'explicatif, dont le profil de coût toujours actif
• Comment réduire l'usage des tokens dans opencode — le même exercice sur un agent par session