Comment réduire l'usage des tokens dans opencode

Fait partie du pilier réduire l'usage des tokens des agents de code IA. Cette page est spécifique à opencode : les contrôles intégrés, ce qu'ils couvrent et ce qu'ils ne couvrent pas.

Comment réduire l'usage des tokens dans opencode ?

Commencez par lancer opencode stats pour voir où sont réellement partis les tokens, utilisez l'agent plan pour l'exploration plutôt que build, et laissez la compaction automatique active — puis corrigez le plus gros poste, qui est presque toujours les lectures de fichiers entiers et les sorties de commandes non filtrées. opencode a une propriété qui rend l'exercice à la fois plus urgent et plus simple que sur les outils par abonnement : il fonctionne avec votre propre clé. Aucun forfait n'absorbe votre inefficacité, aucune abstraction de portefeuille ne s'interpose. Chaque token gaspillé apparaît sur la facture de votre fournisseur au prix catalogue. C'est inconfortable, mais la boucle de retour est honnête — ce qu'on ne peut pas dire d'un outil qui vous décompte discrètement d'une allocation. Petite mise au point sur l'identité, car la plupart des articles se trompent : opencode est maintenu par Anomaly (l'équipe anciennement connue sous le nom de SST), le dépôt est anomalyco/opencode, sous licence MIT et écrit en TypeScript. Si vous croisez un billet le décrivant comme « un projet Go de SST », c'est périmé — et il existe un dépôt distinct et sans rapport, opencode-ai/opencode, qui n'est pas celui-ci.

Pourquoi opencode consomme-t-il des tokens ?

Pour la même raison structurelle que tous les agents de code : le modèle est sans état, donc chaque tour renvoie toute la conversation précédente plus tout ce que l'agent a lu. Le tour 20 transporte les tours 1 à 19, chaque fichier ouvert, chaque sortie de commande capturée, chaque définition d'outil chargée. Un « corrige ce test qui échoue », c'est quarante tokens de vos mots et des dizaines de milliers de tokens de contexte. L'intelligence de l'agent ne change rien à cette arithmétique ; le volume que vous lui donnez, si. Un détail propre à opencode mérite d'être sorti ici, parce qu'il joue dans l'autre sens : il est compatible LSP. Un serveur de langage peut répondre à « où ce symbole est-il défini », « quelles sont les références », « quel est ce type » sans que l'agent ouvre et transporte des fichiers entiers. C'est exactement la substitution — la structure plutôt que les corps — que cette page recommande en boucle, et elle est déjà câblée. Reste à savoir si l'agent y recourt plutôt que de retomber sur une lecture de fichier, ce qui dépend de la façon dont vous avez cadré la tâche : la part que vous contrôlez. Ce qui est propre à opencode, c'est la surface. Il est agnostique en modèles, avec plus de 75 fournisseurs via l'AI SDK — réellement utile, mais cela signifie aussi que votre tarif par token est celui que vous avez choisi, et qu'un choix de modèle négligent multiplie chacune des inefficacités ci-dessous. L'intégration LSP et les agents intégrés déterminent, eux, la quantité lue en amont.

Comment voir l'usage des tokens dans opencode, d'abord ?

opencode stats, et il prend quatre flags qui transforment un chiffre unique en diagnostic. Lancé nu, il donne l'usage de tokens et le coût cumulés sur vos sessions. C'est le titre, et seul il vous dit la taille du problème sans vous dire où il est. Ce sont les flags qui le rendent utile :

--days N — restreint aux N derniers jours. Par défaut tout l'historique, ce qui mélange vos habitudes actuelles avec ce que vous faisiez il y a trois mois.
--tools N — combien d'outils lister. C'est celui qui répond à « qu'est-ce qui mange vraiment mon contexte », parce que les appels d'outils sont l'endroit par où les tokens entrent.
--models N — répartition par modèle, masquée sauf demande. Passez un nombre pour le top N. Être agnostique au modèle est l'avantage d'opencode, et c'est le seul moyen de vérifier que vous vous en servez.
--project — filtre par projet. Chaîne vide pour le projet courant.

Lisez d'abord la répartition input/output. Pour presque tout le monde l'input domine l'output d'environ un ordre de grandeur, ce qui décide où l'effort vaut la peine : sur ce que l'agent lit, pas sur ce qu'il écrit. Si vous voulez malgré tout un plafond côté écriture, OPENCODE_EXPERIMENTAL_OUTPUT_TOKEN_MAX fixe le maximum de tokens de sortie par réponse du LLM. C'est une variable expérimentale, donc susceptible de changer ou de disparaître, et elle protège d'une génération qui s'emballe plutôt qu'elle ne déplace la facture du mois. Soyez clair sur ce que stats ne sait pas faire : il est rétrospectif et agrégé. Il vous dira que les lectures vous ont coûté 800k tokens la semaine dernière. Il ne vous dira pas que 300k d'entre eux étaient les quatre mêmes fichiers relus onze fois, qui est le constat qui change vraiment un comportement. Pour ça, il faut regarder une session en direct, ou placer quelque chose entre l'agent et ses outils.

opencode peut-il afficher les tokens par seconde ?

Pas tout seul. C'est une demande de fonctionnalité ouverte, et un plugin communautaire comble le manque aujourd'hui. La demande, c'est l'issue #5374, « show tokens / second », qui réclame que opencode affiche le débit courant et moyen en tokens/s pour comparer fournisseurs et modèles. Elle est toujours ouverte, et la pull request qui y est rattachée l'est aussi : #12721, qui ajoute les tokens par seconde au pied de réponse du TUI. Si vous lisez ceci et que le pied de page affiche déjà un débit, c'est que cette PR a été fusionnée après l'écriture de cette page. En attendant, opencode-tps-meter place un compteur de tokens par seconde en direct, avec barre visuelle, dans le TUI d'opencode. Il est publié sur npm sous @johannus22/opencode-tps-meter (0.1.2), et un fork distinct, ChiR24/opencode-tps-meter, vise les deux générations d'opencode sous forme de binaires côte à côte. Aucun des deux n'est un plugin officiel : traitez-les comme n'importe quelle extension TUI tierce. Il faut être honnête sur ce que ce chiffre vous apporte. Les tokens par seconde mesurent un débit, pas une dépense : ils vous disent quel fournisseur répond le plus vite, pas lequel coûte le moins cher. Un modèle à 120 tok/s qui relit quatre fois le même fichier revient plus cher qu'un modèle à 40 tok/s qui le lit une fois. Si la question derrière « à quelle vitesse ça avance » est en réalité « pourquoi ça coûte autant », c'est la répartition entrée/sortie de opencode stats ci-dessus qu'il faut lire à la place.

Quels contrôles intégrés aident vraiment ?

Quatre, par ordre d'impact approximatif.

opencode stats — affiche l'usage de tokens et les statistiques de coût de vos sessions, filtrables par période, outils, modèles et projet. C'est la première commande à lancer. Chaque recommandation de cette page vaut moins que dix minutes passées sur vos propres chiffres, car la répartition du gaspillage diffère d'une base de code à l'autre.
L'agent plan — opencode embarque deux agents intégrés : build, en accès complet et par défaut, et plan, en lecture seule. Explorer dans plan évite les définitions d'outils d'écriture et les boucles d'édition-échec qui gonflent une session avant même que vous ayez décidé quoi changer.
La compaction automatique du contexte — active par défaut, à laisser ainsi. Vous pouvez la désactiver avec OPENCODE_DISABLE_AUTOCOMPACT ; la raison habituelle de le faire est de déboguer un problème de contexte, pas d'économiser.
OPENCODE_EXPERIMENTAL_OUTPUT_TOKEN_MAX — plafonne les tokens de sortie par réponse. La sortie est le côté cher au token, donc c'est un vrai garde-fou contre une génération qui s'emballe, même si c'est le levier le plus faible en pratique, le trafic d'un agent étant très majoritairement entrant.

Utiles aussi : opencode session list et session delete pour élaguer les anciennes sessions, et OPENCODE_DISABLE_PRUNE si vous devez empêcher opencode de supprimer d'anciennes données — notez que c'est le bouton qui agrandit le contexte, donc laissez-le tranquille sans raison précise. Je n'ai pas trouvé de contrôles de prompt caching documentés dans la documentation d'opencode. Le comportement de cache suivra donc celui de votre fournisseur par défaut, ce qui chez Anthropic signifie des lectures de cache à 10 % du prix d'entrée — assez significatif pour aller vérifier la sémantique de cache de votre fournisseur plutôt que de la supposer.

Quels sont les plus gros leviers propres à opencode ?

Ceux qui empêchent les tokens d'entrer dans la conversation, puisque la compaction n'agit qu'une fois qu'ils y sont.

Lire la structure avant les corps. Un agent qui demande « où est défini le middleware d'authentification » a besoin d'une carte de symboles, pas de quatre fichiers entiers. Les lectures de fichiers complets sont le premier poste de la plupart des sessions, et le plus facile à sur-alimenter parce que lire un fichier donne l'impression d'être gratuit.
Filtrer les sorties de commandes à la source. Une suite de tests en échec, un build verbeux, un log docker : des milliers de tokens dont vingt comptent peut-être. Et ils sont ensuite transportés sur tout le reste de la session.
Choisir le modèle par tâche, pas par session. L'agnosticisme est l'atout d'opencode : servez-vous-en. Le travail de manœuvre — lire et résumer, formater, lister des fichiers — n'a pas besoin de votre palier le plus cher. Chez Claude, Haiku coûte la moitié de Sonnet 5 et un cinquième d'Opus.
Garder des sessions courtes et cadrées. Le coût croît de façon non linéaire avec la profondeur, chaque tour renvoyant tout le précédent. Deux sessions ciblées coûtent moins qu'une seule qui a divagué, à travail égal.
Auditer les définitions d'outils. Chaque outil disponible pour l'agent occupe du contexte, qu'il soit appelé ou non.

Combien coûte réellement une session opencode ?

Assez pour que le seul choix du modèle fasse varier la facture d'un facteur 5, et assez pour que les relectures dominent quel que soit ce choix. Déroulons une session dont la forme parlera à tout le monde : cinquante tours, se terminant sur environ un million de tokens d'entrée transportés au fil de la conversation et quarante mille tokens de sortie écrits. Ce n'est pas un cas extrême — c'est un après-midi normal de travail multi-fichiers. Sur Claude Sonnet 5 à 2 $ le million en entrée et 10 $ en sortie, cela fait 2,00 $ d'entrée et 0,40 $ de sortie : environ 2,40 $, sans cache. Passez la même session sur Opus 4.8 à 5 $/25 $ et vous êtes à 5,00 $ plus 1,00 $, soit 6,00 $. Basculez les portions de manœuvre sur Haiku 4.5 à 1 $/5 $ et le côté entrée est encore divisé par deux. Même travail, même agent, un écart de 5×, décidé entièrement par une ligne de configuration. Deux conséquences tombent de ce calcul. D'abord, l'entrée représente ici environ 83 % de la facture, ce qui explique pourquoi « faire écrire moins le modèle » est le mauvais réflexe : la sortie est cinq fois plus chère au token mais arrive en volumes bien plus faibles. Ensuite, le prompt caching compte davantage que le choix du modèle pour le contexte répété : à 10 % du prix d'entrée chez Anthropic, un préfixe stable relu sur ces cinquante tours coûte un dixième d'une lecture fraîche. L'ordre des opérations est donc : réduire ce qui est lu, puis laisser le cache absorber ce qui se répète légitimement, puis choisir le modèle le moins cher qui fait encore le travail.

Comment appliquer ça dès aujourd'hui

Lancez opencode stats sur la dernière semaine. Notez la répartition entrée/sortie — chez la plupart des gens l'entrée domine d'un ordre de grandeur, ce qui vous dit où viser.
Basculez le travail exploratoire sur l'agent plan et gardez build pour le moment où vous savez ce que vous modifiez.
Vérifiez que la compaction automatique est active (elle l'est par défaut — il suffit de ne pas la désactiver puis l'oublier).
Fixez une politique de modèles : palier bon marché pour le travail de manœuvre, palier cher pour le raisonnement. Avec plus de 75 fournisseurs câblés, ça ne coûte qu'une décision de configuration.
Puis attaquez les lectures. Les leviers indépendants de l'outil sont dans comment réduire l'usage des tokens des agents de code IA, et ils s'appliquent tels quels ici.

Cette dernière étape est ce que Tokenade automatise — il se place entre l'agent et ses outils, récupère au lieu de lire des fichiers entiers, replie les sorties de commandes et de MCP bruyantes à la frontière, sans changer votre façon de travailler. 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.

Ce qui cloche en pratique (anti-patterns)

Prendre la compaction pour la solution. La compaction automatique réduit ce qui est transporté vers l'avant ; elle n'empêche pas la lecture d'un fichier de 3 000 tokens quand vingt lignes suffisaient. C'est de la limitation de dégâts, pas de la prévention. Désactiver l'autocompact pour « garder plus de contexte ». Vous paierez ce contexte à chaque tour suivant. Si l'agent perd un détail important, la réponse est généralement un périmètre plus serré, pas une fenêtre plus grande. Choisir le modèle le plus capable pour tout. Avec votre propre clé, cette décision vous appartient entièrement et vous est facturée entièrement. C'est le moyen le plus rapide de multiplier par cinq un problème de tokens. Lire opencode stats une fois et plus jamais. La répartition évolue avec votre base de code et vos habitudes. C'est un contrôle mensuel de cinq minutes, pas une opération unique.

À lire aussi :

Réduire l'usage des tokens des agents de code IA — le pilier indépendant de l'outil
Réduire l'usage des tokens dans Claude Code — les mêmes leviers sur Claude Code
Alternatives à Claude Code — où opencode se situe parmi les options
Mesurer l'usage des tokens d'un agent — comment lire les chiffres collectés