Comment réduire l'usage des tokens de Droid

Fait partie du pilier réduire l'usage des tokens des agents IA. Vous comparez des agents en terminal ? Voyez les versions Qwen Code et Grok CLI. Cette page porte sur Droid CLI de Factory, la commande droid.

Comment réduire l'usage des tokens de Droid ?

Regardez /context et /cost, baissez compactionTokenLimit pour que la compaction se déclenche plus tôt, confiez la compaction et les subagents légers à un modèle moins cher, réglez reasoningEffort selon la tâche, et sortez les questions annexes du transcript avec /btw. Puis corrigez ce qui entre dans la conversation : fichiers et sorties de commandes.

Droid a un fichier de réglages exceptionnellement complet sur ce sujet. Seuil de compaction, modèle de compaction, modèles des subagents par niveau, modèle du mode Spec : chacun a sa clé. Aucun, en revanche, ne réduit un résultat d'outil avant que le modèle ne le lise. Cela reste le plus gros poste de la plupart des sessions.

Sources : réglages et commandes lus dans la référence des réglages de Droid et la référence de la CLI de Factory le 14 octobre 2026. Le chiffre de Tokenade vient du benchmark ouvert des optimiseurs de tokens.

Pourquoi les tokens de Droid comptent-ils même avec un abonnement ?

Parce que Factory mesure l'usage sur des fenêtres glissantes, et que ce sont les tokens qui les remplissent.

La page des offres individuelles de Factory décrit trois fenêtres de limites glissantes, sur 5 heures, 7 jours et 30 jours, chacune indépendante. Le Standard Usage est consommé en premier ; ensuite, les modèles Droid Core puisent dans une réserve séparée, et l'Extra Usage correspond à des crédits prépayés. La même page renvoie à un catalogue de modèles avec des multiplicateurs qui déterminent le coût de l'usage.

Une session gaspilleuse ne coûte donc pas seulement plus cher. Elle rapproche le prochain mur de limite. Si vous apportez votre propre clé, Factory indique que le BYOK est gratuit jusqu'à un certain quota sur toutes les offres individuelles, puis facturé selon votre offre.

La mécanique sous-jacente est la même que partout. Chaque tour renvoie la conversation, y compris chaque fichier lu et chaque résultat d'Execute. Un log de test lu au tour 4 est repayé à chaque tour suivant jusqu'à ce que la compaction le retire.

Comment voir où partent les tokens de Droid ?

Quatre commandes, de la fenêtre en cours jusqu'à votre forfait.

• /context affiche la répartition de l'usage de la fenêtre de contexte avec une barre de progression.
• /cost affiche les statistiques d'usage.
• /stats [period] affiche l'usage sur des périodes relatives ou des plages de dates.
• /limits gère les limites d'usage des tokens et les préférences de dépassement ; la page des offres y renvoie pour le suivi.

Pour une vue en continu, passez showTokenUsageIndicator à true dans ~/.factory/settings.json. Un indicateur d'usage des tokens s'affiche alors sous la zone de saisie : c'est le moyen le moins coûteux de voir une session gonfler pendant qu'elle gonfle.

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

Quatre clés dans ~/.factory/settings.json, à peu près par ordre de rendement.

1. compactionTokenLimit. Le seuil de tokens qui déclenche la compaction automatique. La valeur par défaut dépend du modèle. Baissez-le et moins d'historique voyage avec chaque requête ; compactionTokenLimitPerModel le surcharge modèle par modèle.
2. compactionModel. same utilise le modèle de la session pour rédiger le résumé. Pointez-le vers un modèle moins cher et chaque compaction coûte moins.
3. subagentModelSettings. Les subagents sont routés par niveau de complexité. lightModel couvre le travail léger, comme le subagent intégré explorer ; mediumModel couvre des niveaux comme le worker intégré. Les deux héritent par défaut du modèle de la session. Un lightModel moins cher est le gain le plus facile ici.
4. reasoningEffort. Il règle la quantité de réflexion structurée du modèle, de off à max selon le modèle. La doc de Factory donne les valeurs par défaut par modèle : Claude Opus 4.8 est à high, Claude Sonnet 4.5 à off.

Sur une offre Factory, il y a aussi Droid Core : une réserve gratuite de modèles open-weight avec ses propres limites. Factory conseille lui-même de lancer les Missions sur Droid Core quand c'est possible.

Faut-il démarrer les sessions Droid en mode Spec ?

Pour tout ce qui dépasse une petite correction, oui : un plan que vous validez coûte moins qu'une implémentation que vous pilotez.

sessionDefaultSettings.interactionMode décide si les nouvelles sessions démarrent en mode Auto ou Spec ; droid exec --use-spec fait de même pour une exécution headless. En mode Spec, Droid planifie avant d'exécuter, et vous pouvez donner à cette étape son propre modèle et son propre effort avec specModeModel et specModeReasoningEffort.

L'argument tokens porte sur l'échec, pas sur la planification. Corriger une implémentation en cours de route renvoie toute la tentative ratée à chaque tour de la réparation. Corriger un plan, c'est un court échange avant qu'aucun fichier n'ait été touché.

Quelles commandes gardent une session Droid légère ?

Celles qui gardent le transcript court, pas seulement celles qui le résument.

• /btw <question> pose une question annexe sans polluer le transcript principal. Chaque question hors sujet tapée autrement devient un bloc renvoyé à chaque tour suivant.
• /compress [prompt] compresse la session et passe à une nouvelle avec un résumé. Le prompt facultatif indique ce que le résumé doit garder.
• /clear efface la conversation mais garde votre modèle et votre niveau d'autonomie. /new repart de zéro et remet les deux par défaut.
• /fork copie la session dans une nouvelle, pour tenter une piste risquée sans ramener ses impasses dans le fil principal.

En mode headless, droid exec accepte --disabled-tools et --restrict-tools. Moins d'outils, c'est moins de définitions d'outils dans chaque requête, et moins de tentation pour l'agent de s'égarer.

Un réglage ressemble à une économie sans en être une : toolResultDisplay: "compact". Il change l'affichage des résultats d'outils dans votre transcript, pas ce que reçoit le modèle.

Que laissent intact les réglages de Droid ?

Le contenu des résultats d'outils : fichiers lus, sortie d'Execute, réponses MCP.

La compaction limite les dégâts. Quand compactionTokenLimit est atteint, un log de build de 2 000 lignes a déjà été renvoyé à chaque tour depuis son arrivée. Un modèle de compaction moins cher rend le nettoyage moins cher ; il n'empêche pas le désordre.

C'est là que travaille Tokenade. Sur Droid, tokenade install ajoute des hooks dans ~/.factory/hooks.json : PreToolUse et PostToolUse sur Execute, plus SessionStart, UserPromptSubmit et PreCompact. La sortie shell arrive au modèle réduite à ses lignes décisives. Il écrit aussi ses règles dans ~/.factory/AGENTS.md et enveloppe les serveurs de ~/.factory/mcp.json.

Droid fait partie des agents dont la ligne est complète dans la matrice de compatibilité : sortie des commandes, recherche web, résultats MCP, recherche de code, contexte, déduplication, documents et masquage des secrets sont tous couverts automatiquement. Aucun proxy nécessaire. Le brief complet est sur tokenade.net/agents/droid.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 Droid : le mécanisme est le même, la mesure non.

Comment l'appliquer dès aujourd'hui

1. Activez showTokenUsageIndicator et lancez /limits pour voir où vous en êtes dans chaque fenêtre.
2. Baissez compactionTokenLimit, et réglez compactionModel sur un modèle moins cher.
3. Réglez subagentModelSettings.lightModel pour que l'exploration ne tourne pas sur votre modèle le plus cher.
4. Choisissez reasoningEffort selon la tâche au lieu de laisser le niveau le plus profond.
5. Utilisez /btw pour les questions annexes et /new quand la tâche change.
6. Puis corrigez ce qui entre dans la conversation : installez Tokenade.

Ce qui tourne mal (anti-patterns)

Poser les questions annexes dans le fil principal. Chacune est renvoyée jusqu'à la fin de la session ou la prochaine compaction. C'est exactement à cela que sert /btw.

Laisser les subagents hériter du meilleur modèle. La valeur par défaut est inherit. Un explorer qui lit des fichiers sur votre modèle le plus cher, c'est la façon la plus coûteuse de faire un grep.

Prendre la compaction pour la solution. Elle raccourcit l'historique après les dégâts. Le log a été payé à chaque tour avant elle.

Passer toolResultDisplay à compact et s'arrêter là. Votre terminal a l'air plus propre. La requête a la même taille.

FAQ

Comment voir l'usage des tokens dans Droid ?

Lancez /context pour la fenêtre de contexte en cours, avec une barre de progression, et /cost pour les statistiques d'usage. /stats couvre des périodes plus longues, et /limits montre où vous en êtes par rapport aux limites de votre offre. Passer showTokenUsageIndicator à true dans settings.json ajoute un compteur de tokens en direct sous la zone de saisie.

Comment changer le moment où Droid compacte ?

Réglez compactionTokenLimit dans ~/.factory/settings.json : c'est le seuil de tokens qui déclenche la compaction automatique, avec une valeur par défaut qui dépend du modèle. Utilisez compactionTokenLimitPerModel pour des valeurs par modèle, et compactionModel pour choisir le modèle qui rédige le résumé. Vous pouvez aussi compacter à la main avec /compress, avec un prompt facultatif sur ce qu'il faut garder.

Les subagents de Droid utilisent-ils le même modèle que ma session ?

Par défaut, oui. subagentModelSettings route les subagents par niveau, léger, moyen et lourd, et chaque niveau hérite du modèle de la session sauf si vous en fixez un. Un lightModel moins cher sort le travail léger, comme le subagent intégré explorer, de votre modèle principal. Un droid personnalisé avec son propre model contourne ce routage.

Est-ce que /btw économise des tokens dans Droid ?

Il les garde hors de la conversation principale. /btw pose une question annexe sans polluer le transcript principal : la question et sa réponse ne sont donc pas renvoyées à chaque tour suivant de votre tâche. Pour une vérification rapide au milieu d'une longue session, c'est moins cher que de la poser dans le fil.

Tokenade est-il compatible avec Factory Droid ?

Oui, entièrement. tokenade install branche Droid via des hooks dans ~/.factory/hooks.json, écrit ses règles dans ~/.factory/AGENTS.md et enveloppe les serveurs MCP de ~/.factory/mcp.json. Toutes les fonctions de la matrice de compatibilité sont couvertes automatiquement sur Droid, sans proxy LLM.

---

À 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 de Grok CLI — l'agent en terminal de xAI
• Comment réduire l'usage des tokens de Claude Code — les mêmes leviers sur Claude Code
• Réduire les tokens sur les longues sessions — pourquoi l'historique se cumule