Comment réduire l'usage des tokens de Grok CLI

Fait partie du pilier réduire l'usage des tokens des agents IA. Vous comparez des agents en terminal ? Les pages Qwen Code et Droid couvrent le même terrain. Celle-ci porte sur Grok Build de xAI, la commande grok.

Comment réduire l'usage des tokens de Grok CLI ?

Surveillez /context en travaillant, baissez auto_compact_threshold_percent pour que la compaction se déclenche plus tôt, réduisez l'effort de raisonnement avec /effort pour le travail courant, plafonnez les longues exécutions autonomes avec /goal --budget, et ouvrez une nouvelle session quand la tâche change. Reste la sortie des outils, que les hooks de Grok Build ne savent pas réduire.

Ce dernier point est celui que la plupart des guides oublient. Grok Build gère des hooks, mais son hook PreToolUse ne peut qu'autoriser ou refuser un appel, et la sortie de PostToolUse est ignorée. Rien de ce qui se branche par hook ne peut compacter un log de test avant que le modèle ne le lise. Tout ce qui suit en découle.

Sources : réglages et commandes lus dans la doc de Grok Build et le guide utilisateur de grok-build le 14 octobre 2026. Le chiffre de Tokenade vient du benchmark ouvert des optimiseurs de tokens.

De quel « Grok CLI » parle cette page ?

De Grok Build, l'outil officiel de xAI, installé sous le nom grok et configuré dans ~/.grok/config.toml.

Il existe aussi un projet communautaire distinct, superagent-ai/grok-cli, un agent open source pour l'API Grok. C'est un autre programme, avec d'autres réglages. Si une astuce cite des variables d'environnement absentes de la doc de xAI, elle a probablement été écrite pour celui-là.

Grok Build lit ~/.grok/config.toml (%USERPROFILE%\.grok\config.toml sous Windows), ou $GROK_HOME/config.toml si vous définissez GROK_HOME. Le .grok/config.toml d'un projet n'apporte que des serveurs MCP, des plugins et des règles de permissions. Lancez grok inspect pour voir quelles configs sont réellement prises en compte.

Pourquoi Grok Build consomme-t-il autant de tokens ?

Pour la même raison que tous les agents : chaque tour renvoie la conversation, et tout ce que l'agent a lu en fait partie.

Le tour 25 transporte les tours 1 à 24, chaque fichier ouvert, chaque résultat shell, chaque page web récupérée. Un gros log lu tôt est repayé à chaque tour jusqu'à ce que la compaction le retire. Grok Build fait aussi tourner des modèles de raisonnement, et ces tokens comptent : son flux OpenTelemetry déclare reasoning comme type de token à côté de input, output et cache_read.

La facture a donc trois composantes sur lesquelles agir : ce qui entre dans l'historique, combien de temps cela y reste, et combien le modèle réfléchit à chaque tour.

Comment voir où partent les tokens de Grok Build ?

/context pour la fenêtre en cours, /usage pour les crédits, et OpenTelemetry si vous voulez un historique.

• /context affiche l'usage actuel du contexte. /session-info l'affiche aussi, avec les détails de la session.
• /usage affiche la consommation de crédits ou gère la facturation.
• /goal status donne les tokens utilisés et le temps écoulé d'un objectif en cours.
• L'export OpenTelemetry envoie une métrique grok_code.token.usage ventilée par type et par modèle, et un événement grok_code.compaction avec tokens_before et tokens_after. Le guide de monitoring précise qu'il n'y a pas de métrique de coût : vous croisez les tokens avec votre propre grille tarifaire.

L'événement de compaction est le plus utile. Il indique combien chaque compaction a réellement libéré, le chiffre qui dit si votre seuil est bien réglé.

Quels réglages intégrés réduisent vraiment la facture ?

Quatre réglages, plus une habitude.

1. auto_compact_threshold_percent sous [session]. Grok compacte automatiquement quand l'usage du contexte atteint ce pourcentage ; la valeur par défaut est 85. Baissez-le et moins d'historique voyage à chaque tour.
2. context_window par modèle. La référence des réglages indique qu'il pilote le moment de l'auto-compaction. Sur un modèle personnalisé, mettez la vraie taille de fenêtre, sinon le seuil est calculé sur le mauvais nombre.
3. L'effort de raisonnement. /effort le règle pour le modèle courant, et default_reasoning_effort sous [models] fixe la valeur par défaut. Les modifications courantes demandent rarement le niveau le plus profond.
4. /goal --budget <tokens>. Les objectifs laissent Grok avancer seul vers un but. Le budget plafonne les tokens qu'un objectif peut dépenser : c'est le bon garde-fou pour tout ce qui tourne sans surveillance.

L'habitude, c'est l'hygiène de session. /compact [context] compresse l'historique à la demande, avec des consignes facultatives sur ce qu'il faut garder. /new (alias /clear) ouvre une session neuve. /rewind ramène la conversation à un prompt antérieur, mais restaure aussi les fichiers sur disque : commitez d'abord.

max_completion_tokens existe aussi, global ou par modèle. Il plafonne chaque réponse, ce qui protège d'une génération qui s'emballe mais bouge à peine une facture d'agent : l'essentiel est en entrée.

Quels réglages de Grok ressemblent à des économies sans en être ?

Ceux qui portent « compact » dans leur nom, sous [ui].

compact_mode resserre l'espacement des messages, et tool_call_density (aussi /density) décide quelle part de chaque appel d'outil le transcript affiche. Les deux changent ce que vous voyez dans le terminal. Aucun ne change ce que reçoit le modèle. Un appel d'outil replié dans votre TUI est quand même envoyé en entier.

Masquer les blocs de réflexion avec show_thinking_blocks = false relève du même principe : c'est un choix d'affichage. Pour dépenser moins de tokens de raisonnement, baissez l'effort.

Que laissent intact les réglages de Grok ?

La sortie des outils : fichiers, résultats shell, pages web et documents, au moment où ils entrent dans la conversation.

La compaction agit après coup. Quand elle se déclenche, un log de 3 000 lignes a déjà été renvoyé à chaque tour depuis son arrivée. Et comme les hooks ne peuvent pas réécrire la sortie sur Grok Build, un optimiseur à base de hooks ne peut pas intervenir à ce moment-là non plus.

Tokenade contourne le problème avec un proxy LLM local. tokenade install le propose pour Grok et fait pointer [endpoints] models_base_url de ~/.grok/config.toml vers lui. Le proxy écoute uniquement en loopback et compacte les résultats d'outils dans chaque requête avant leur envoi à l'API du modèle.

Tokenade utilise quand même les hooks que Grok respecte, SessionStart et PreCompact, écrit ses règles dans ~/.grok/rules/tokenade.md et enveloppe vos serveurs MCP. Dans la matrice de compatibilité, sortie des commandes, recherche web et documents sont en Partial+ pour Grok : complets une fois le proxy LLM en place. Résultats MCP, recherche de code, contexte, déduplication et masquage des secrets sont couverts dans tous les cas.

Sans le proxy, vous pouvez appeler Tokenade vous-même : tokenade wrap '<cmd>', tokenade web <url>, tokenade read <file>. Le brief complet est sur tokenade.net/agents/grok.md.

Sur le benchmark ouvert des optimiseurs de tokens, il réduit le coût de session de 39 % sur les longues sessions par rapport à l'absence d'outil. Cette campagne a tourné sur Claude Code, pas sur Grok Build : le mécanisme est le même, la mesure non.

Comment l'appliquer dès aujourd'hui

1. Lancez grok inspect pour confirmer quel config.toml est actif.
2. Réglez auto_compact_threshold_percent sous [session] en dessous des 85 par défaut, et vérifiez context_window sur tout modèle personnalisé.
3. Utilisez /effort pour baisser le raisonnement sur le travail courant ; gardez les niveaux élevés pour la conception et le debug.
4. Donnez un --budget à chaque /goal lancé sans surveillance.
5. Surveillez /context, utilisez /compact en précisant ce qu'il faut garder, et /new quand la tâche change.
6. Puis corrigez ce qui entre dans la conversation : installez Tokenade et acceptez le proxy LLM pour Grok.

Ce qui tourne mal (anti-patterns)

Prendre /density pour un réglage de tokens. Il replie le transcript à l'écran, pas dans la requête. La facture ne bouge pas.

Lancer des objectifs sans budget. Une boucle autonome sans plafond est le moyen le plus rapide de brûler une journée de tokens sur une tâche bloquée à l'étape trois.

L'effort maximal par défaut. Les tokens de raisonnement sont des tokens facturés. Payer une réflexion profonde pour un renommage est une habitude, pas une nécessité.

Revenir en arrière au lieu de recommencer. /rewind restaure aussi les fichiers. Si vous vouliez seulement un contexte propre, /new est plus sûr.

FAQ

Comment voir l'usage des tokens dans Grok CLI ?

Dans Grok Build, /context affiche l'usage actuel du contexte et /usage la consommation de crédits. Pour un objectif, /goal status donne les tokens utilisés. Pour un historique sur plusieurs sessions, activez l'export OpenTelemetry : il émet une métrique grok_code.token.usage ventilée entre entrée, sortie, raisonnement et lectures en cache, par modèle.

Comment faire compacter Grok Build plus tôt ?

Réglez auto_compact_threshold_percent sous [session] dans ~/.grok/config.toml. Grok compacte automatiquement quand l'usage du contexte atteint ce pourcentage ; la valeur par défaut est 85. Sur un modèle personnalisé, renseignez aussi context_window correctement, puisqu'il pilote le moment de l'auto-compaction. Vous pouvez compacter à la main à tout moment avec /compact, en précisant ce qu'il faut garder.

Les hooks de Grok Build peuvent-ils réduire l'usage des tokens ?

Pas sur la sortie des outils. Le hook PreToolUse de Grok ne peut qu'autoriser ou refuser un appel, et la sortie de PostToolUse est ignorée : aucun hook ne peut réécrire ce qu'un outil renvoie. Les hooks peuvent encore agir au démarrage de session et avant la compaction. Réduire la sortie elle-même demande un composant sur le chemin des requêtes, comme un proxy LLM local.

Est-ce que /compact-mode économise des tokens ?

Non. /compact-mode et le réglage compact_mode ne font que resserrer la mise en page de la TUI, et /density change seulement la part de chaque appel d'outil que vous voyez. Le modèle reçoit toujours chaque résultat d'outil en entier. Pour réduire ce qui est envoyé, compactez l'historique avec /compact ou réduisez la sortie des outils avant qu'elle n'entre.

Tokenade est-il entièrement compatible avec Grok ?

En grande partie. Résultats MCP, recherche de code, contexte, déduplication et masquage des secrets fonctionnent d'emblée. Sortie des commandes, recherche web et documents sont en Partial+ : ils demandent le proxy LLM local de Tokenade, que tokenade install propose pour Grok, parce que les hooks de Grok ne peuvent pas réécrire la sortie. Sans le proxy, appelez vous-même tokenade wrap, web ou read.

---

À lire aussi :

• Comment réduire l'usage des tokens des agents IA — le pilier indépendant de l'outil
• Comment réduire l'usage des tokens dans Qwen Code — un autre agent en terminal, d'autres réglages
• Comment réduire l'usage des tokens dans opencode — le cas de la clé API personnelle
• Mesurer l'usage des tokens d'un agent — lire les chiffres que vous collectez