Comment réduire l'usage des tokens dans opencode

opencode fonctionne avec votre propre clé API : chaque token gaspillé vous est facturé directement. Voici ce qui pilote la facture et les contrôles intégrés qui valent la peine.

Profile photo of Paul Irolla

Par Paul Irolla

Founder · AI & developer tools · Tokenade

Ph.D. in AI · builds token-optimization tooling for AI coding agents

Voir la page de l'auteur
8 min de lecture
Résumer avec l'IA
Citer cette page
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.

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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

  1. 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.
  2. Basculez le travail exploratoire sur l'agent plan et gardez build pour le moment où vous savez ce que vous modifiez.
  3. 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).
  4. 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.
  5. 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 :

Classé n°1 au Token-Harness Optimizer Leaderboard.

Tokenade est classé n°1 au Token-Harness Optimizer Leaderboard — un benchmark de bout en bout des optimiseurs de tokens, mesuré sur de vraies sessions de code. Installez-le une fois, il agit sur chaque prompt. Compatible avec Claude Code, Cursor, Codex, Copilot et plus.