Comment réduire l'usage des tokens dans Kilo Code

On réduit l'usage des tokens dans Kilo Code en deux temps : envoyer chaque requête au modèle le moins cher capable de la traiter, puis réduire ce qui entre dans la fenêtre de contexte avant que la compaction ait à intervenir. Kilo offre des réglages d'une précision rare pour les deux, la plupart dans kilo.jsonc.

Cet article fait partie du guide réduire l'usage des tokens d'un agent de code IA. Vous hésitez encore entre les deux ? Lisez opencode vs Kilo Code. Cette page est propre à Kilo : les réglages qu'il documente, et ce qu'ils laissent de côté.

Pourquoi Kilo Code consomme-t-il autant de tokens ?

Parce que chaque étape de l'agent est une requête à part, qui renvoie le prompt système, les définitions d'outils et toute la conversation jusque-là.

La page de contrôle des coûts de Kilo liste les causes sans détour : choix du modèle, taille du prompt et du contexte, nombre d'étapes, boucles de relance, tâches sans surveillance et longueur de session. Chaque token du prompt système, de l'historique, des pièces jointes et des définitions d'outils « est facturé en entrée ».

Le modèle économique rend ce point plus sensible qu'avec un abonnement forfaitaire. Kilo répercute les prix des fournisseurs sans marge, avec 5 % de frais de paiement à l'achat de crédits. En BYOK, vous payez le fournisseur directement. Dans les deux cas, rien n'absorbe le gaspillage : un fichier relu est une ligne sur votre solde.

N'est-ce pas la même chose qu'opencode ?

Presque, mais pas tout à fait, et les différences portent justement sur les leviers de coût.

Kilo présente son CLI comme un fork d'OpenCode et maintient sa propre distribution basée sur OpenCode. L'extension VS Code et le CLI partagent ce runtime. Le problème a donc la même forme que dans réduire l'usage des tokens dans opencode : modèle sans état, historique qui grossit, sorties d'outils transportées tour après tour.

Ce que Kilo ajoute, c'est précisément ce qui compte ici :

• Des niveaux de routage de modèles (Auto Frontier, Auto Efficient, Auto Free) via le Kilo Gateway.
• Une compaction réglable et documentée dans kilo.jsonc : seuil de déclenchement, pruning, fin de conversation conservée telle quelle et modèle de compaction séparé.
• Des garde-fous de dépense : pause sur les boucles d'échec, approbation par outil, alertes de dépense et plafonds journaliers d'organisation.

Si vous utilisez opencode tel quel, la page opencode est faite pour vous. Si vous êtes sur Kilo, lisez la suite.

Quel modèle Kilo doit-il utiliser ?

Auto Efficient pour le quotidien, Auto Frontier seulement pour l'architecture et le débogage difficile.

La page Cost Efficiency & Model Selection de Kilo qualifie le choix du modèle de « moyen le plus efficace de contrôler la dépense ». Ses niveaux Auto Model routent pour vous :

Auto Efficient tient compte de la session, selon Kilo : il reste sur un même modèle pendant des tours liés et se rabat sur un modèle de référence fixe quand il ne peut pas trancher. On change de niveau depuis le sélecteur de modèle du chat, sans autre configuration.

Le choix du modèle touche aussi la sortie. Kilo conseille de garder le mode Code à 16k tokens de sortie maximum ou moins, et de n'augmenter qu'en mode Architect ou Debug. Chaque token de sortie réservé est de la place que l'historique ne peut plus occuper.

Comment régler la compaction de Kilo ?

Laissez la compaction automatique active, fixez threshold_percent pour des résumés plus précoces, et confiez la synthèse à un modèle moins cher.

La documentation Context Condensing décrit deux mécanismes. La compaction remplace l'historique ancien par un résumé ancré : objectif, contraintes, avancement, décisions, fichiers utiles. Le pruning est plus léger : entre deux tours, il vide les sorties d'outils terminées situées hors d'une fenêtre récente de 40 000 tokens.

Tout se règle dans kilo.jsonc :

Le modèle de compaction est le réglage que l'on oublie le plus. Sans lui, Kilo résume avec le modèle de la session, parfois votre plus cher. Dans VS Code, c'est « Compaction model » sous Settings → Models.

Deux variables d'environnement l'emportent sur le fichier : KILO_DISABLE_AUTOCOMPACT=1 et KILO_DISABLE_PRUNE=1. Les deux agrandissent le contexte. Servez-vous-en pour déboguer une perte de contexte, pas pour « garder plus d'historique ».

Un piège documenté : les modèles personnalisés qui ne déclarent pas de fenêtre de contexte ne sont pas suivis, donc la compaction automatique ne s'exécute pas. Si vous branchez un endpoint maison, déclarez sa fenêtre ou lancez /compact vous-même.

Comment garder des fichiers hors du contexte de Kilo ?

Mentionnez des fichiers, pas des dossiers, et interdisez la lecture de tout ce qui est généré.

La page de coûts de Kilo est claire sur @folder : joindre un dossier « envoie chaque fichier en tokens d'entrée », même si seuls un ou deux sont utiles. Utilisez @file avec des chemins précis, et ne joignez que le fichier du bug et ses dépendances directes.

Kilo ignore déjà node_modules, dist, build, .git, __pycache__, .cache et vendor. Ajoutez les vôtres avec un .kilocodeignore à la racine du workspace, ou une règle de refus dans kilo.jsonc :

C'est le token le moins cher que vous économiserez jamais : celui qui n'entre pas dans la fenêtre. Un rapport de couverture ou un bundle lu par erreur est renvoyé à chaque tour suivant, jusqu'à ce que la compaction ou le pruning le rattrape.

Quels autres réglages de Kilo réduisent le coût ?

Quatre de plus, tous documentés par Kilo.

1. Le mode Architect pour l'analyse. Kilo précise qu'il ne peut pas modifier le code, ce qui en fait le moyen économique d'explorer avant de s'engager. Obtenez un plan, puis passez en mode Code.
2. Désactiver les serveurs MCP inutilisés. Selon la doc de Kilo, cela « réduit nettement la taille du prompt système envoyé à chaque requête ». Ce prompt accompagne chaque étape.
3. Laisser doom_loop sur ask. C'est la valeur par défaut : quand l'agent répète une action qui échoue, Kilo s'arrête et demande. Le passer à allow laisse une boucle bloquée vous facturer sans fin.
4. Surveiller l'estimation par requête. Kilo affiche un coût estimé par requête dans l'historique du chat. S'il grimpe sur une tâche simple, arrêtez-vous et regardez ce que l'agent lit.

Le prompt caching ne demande rien de votre part. Kilo indique l'appliquer automatiquement chez les fournisseurs compatibles, avec des lectures en cache facturées à tarif réduit.

Côté compte, ce sont des garde-fous plutôt que des économies. Les alertes de dépense se déclenchent sur une limite glissante ou un pic horaire, et les organisations peuvent fixer des plafonds journaliers par utilisateur, remis à zéro à minuit UTC.

Que laissent de côté les réglages de Kilo ?

Le contenu des résultats d'outils : les lectures de fichiers entiers et les sorties de commandes brutes arrivent toujours en taille réelle.

Compaction et pruning agissent après coup. Une lecture de fichier de 3 000 tokens entre dans la fenêtre, voyage plusieurs tours, et n'est résumée ou vidée qu'ensuite. Une suite de tests en échec arrive en milliers de tokens quand vingt lignes portent le diagnostic.

Le routage baisse le prix par token, pas le nombre de tokens. Et la fenêtre de pruning de 40K est généreuse : sur une session chargée, beaucoup de sorties brutes restent actives, et facturées, avant d'être écartées.

C'est ce manque que Tokenade comble sur Kilo. Il s'installe comme plugin (~/.config/kilo/plugins/tokenade.ts) et compacte chaque résultat d'outil avant que le modèle ne le voie, MCP compris. Il écrit aussi un court fichier de règles dans ~/.kilo/rules/tokenade.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.

Que couvre Tokenade sur Kilo Code ?

Sorties de commandes, recherche web, résultats MCP, recherche de code, déduplication des relectures, documents et masquage des secrets sont couverts automatiquement. Le contexte est partiel.

Le plugin voit chaque résultat d'outil, mais pas la requête sortante. L'historique n'est donc pas élagué quand le cache de prompt expire. La matrice de compatibilité le marque Partial+ : partiel avec le binaire seul, complet une fois le proxy LLM configuré pour Kilo.

En pratique, le partage des rôles est net. Tokenade réduit ce que renvoie chaque outil. La compaction et le pruning de Kilo gèrent ce qui reste à mesure que la session grandit. La fiche technique destinée aux agents se trouve sur tokenade.net/agents/kilo-code.md.

Comment l'appliquer dès aujourd'hui

1. Passez le sélecteur de modèle sur Auto Efficient et gardez Auto Frontier pour l'architecture et le débogage.
2. Définissez un modèle de compaction dans kilo.jsonc ou Settings → Models, pour que les résumés ne tournent pas sur votre modèle frontier.
3. Ajoutez des règles de refus de lecture ou un .kilocodeignore pour les sorties de build, la couverture et les fixtures.
4. Remplacez les mentions @folder par des mentions @file.
5. Désactivez les serveurs MCP inutiles dans ce workspace.
6. Installez Tokenade pour que les résultats d'outils arrivent compactés. Les leviers valables pour tous les outils sont dans réduire l'usage des tokens d'un agent de code IA.

Les erreurs à éviter

Tout faire tourner sur Auto Frontier. C'est le bon niveau pour un raisonnement difficile, et le mauvais pour renommer une variable. La doc de Kilo elle-même conseille de commencer par Efficient.

Désactiver le pruning pour « garder le contexte ». Les vieilles sorties d'outils restent alors dans la fenêtre jusqu'à la compaction complète, facturées à chaque tour. Si l'agent perd des détails, resserrez plutôt la tâche.

Prendre la compaction pour de la prévention. Le résumé d'une session gonflée reste un résumé que vous avez payé, après avoir payé le gonflement. Coupez d'abord ce qui entre.

Laisser doom_loop sur allow. Les boucles sans surveillance sont l'endroit où de petites inefficacités deviennent une vraie facture. La valeur ask par défaut existe pour une raison.

FAQ

Kilo Code est-il basé sur OpenCode ?

Oui. Kilo présente son CLI comme un fork d'OpenCode et maintient sa propre distribution basée sur OpenCode, partagée avec l'extension VS Code reconstruite. Les bonnes habitudes de coût se transposent, mais Kilo ajoute le routage Auto Model, une compaction réglable dans kilo.jsonc et des garde-fous de dépense.

Comment faire compacter Kilo Code plus tôt ?

Définissez compaction.threshold_percent dans kilo.jsonc, par exemple 80 pour compacter à 80 % de la fenêtre du modèle. La marge de sécurité réservée s'applique toujours et peut déclencher la compaction avant. Vous pouvez aussi lancer /compact à tout moment.

La compaction coûte-t-elle elle-même des tokens dans Kilo ?

Oui : le résumé est écrit par un appel au modèle sur votre historique. C'est pourquoi Kilo permet de choisir un modèle de compaction séparé, sous Settings → Models ou via agent.compaction.model dans kilo.jsonc. Pointez-le vers un modèle moins cher que le principal.

Kilo Code utilise-t-il le prompt caching ?

Oui. Kilo indique appliquer le prompt caching automatiquement chez les fournisseurs compatibles, et les lectures en cache sont facturées moins cher que les tokens d'entrée classiques. Aucun réglage n'est nécessaire.

Tokenade fonctionne-t-il avec Kilo Code ?

Oui. tokenade install ajoute un plugin Kilo qui compacte chaque résultat d'outil, MCP compris, ainsi qu'un fichier de règles. L'élagage du contexte est partiel avec le plugin seul et devient complet avec le proxy LLM. Le détail figure dans la matrice de compatibilité.

À lire aussi :

• Réduire l'usage des tokens d'un agent de code IA : le guide valable pour tous les outils
• Réduire l'usage des tokens dans opencode : l'agent d'origine, avec opencode stats
• opencode vs Kilo Code : lequel convient à votre façon de travailler
• Usage des outils MCP économe en tokens : pourquoi les manifestes d'outils inutilisés coûtent quand même