opencode : tokens par seconde, comment les voir

Fait partie du pilier réduire l'usage des tokens d'un agent de code, en complément du guide spécifique à opencode.

opencode affiche-t-il les tokens par seconde ?

Non. Aucun affichage tokens/seconde n'est intégré à opencode en septembre 2026, et la demande de fonctionnalité qui le réclame est ouverte depuis près de neuf mois. C'est la réponse courte, et elle mérite d'être posée nettement : les résultats de recherche sur cette question sont pleins de pages qui décrivent une fonctionnalité qui n'existe pas. opencode rapporte les tokens et le coût après coup, via opencode stats. Il ne rapporte pas de débit pendant que le modèle répond. Trois moyens existent aujourd'hui pour obtenir ce chiffre : attendre la pull request qui l'ajoute, installer un plugin TUI communautaire, ou le calculer soi-même avec un chronomètre et un compteur de tokens. Les trois fonctionnent. Un seul vous apprend quelque chose d'utile sur votre facture, et ce n'est pas celui que la plupart des gens cherchent.

Où en est la demande officielle ?

Ouverte, populaire, non fusionnée. Il s'agit de l'issue #5374, « [FEATURE]: show tokens / second ». Elle a été ouverte le 11 décembre 2025 et reste ouverte, avec 109 réactions et 20 commentaires à l'heure où ces lignes sont écrites. Pour une demande d'une ligne dans un dépôt de cette taille, c'est beaucoup d'accord sur peu de chose. L'implémentation existe aussi. La pull request #12721, « feat(tui): add tokens per second to response footer », ajoute le débit au pied de réponse du TUI. Ouverte le 8 février 2026, dernière activité le 30 août 2026, toujours ouverte. L'état des lieux est donc : tout le monde la veut, quelqu'un l'a écrite, elle n'est pas passée. Si votre pied de réponse affiche déjà un débit, c'est que cette PR a été fusionnée après la rédaction de cette page. Regardez-le avant d'installer quoi que ce soit.

Comment obtenir un compteur tokens/seconde aujourd'hui ?

En installant opencode-tps-meter, un plugin communautaire qui place un débit en direct et une barre visuelle dans le TUI. Il est publié sur npm sous @johannus22/opencode-tps-meter. La dernière version est la 0.1.2, publiée le 8 avril 2026, et rien n'a bougé depuis. Trois versions au total. Un fork séparé, ChiR24/opencode-tps-meter, vise les deux générations d'opencode en binaires côte à côte. Deux conséquences découlent de ces dates, et elles comptent plus que la fonctionnalité elle-même :

Aucun des deux n'est un plugin officiel. Ils s'accrochent au TUI, ils sont maintenus par des individus, et la surface de plugins d'opencode n'est pas un contrat de stabilité. Traitez-les comme n'importe quelle extension tierce placée sur le chemin de votre éditeur.
La 0.1.2 est figée depuis cinq mois. Ce n'est pas automatiquement un problème pour un composant de cette taille, mais un plugin TUI qui n'a pas été recompilé contre cinq mois de versions amont est un plugin dont il faut attendre qu'il casse à la prochaine mise à jour, pas un dont il faudra s'étonner.

Si vous voulez le chiffre sans ajouter de dépendance, un chronomètre suffit. Chronométrez une réponse, lisez le nombre de tokens de cette réponse dans opencode stats --days 1, divisez. C'est grossier, ça donne un échantillon unique plutôt qu'une moyenne en direct, et pour la comparaison que la plupart des gens veulent vraiment — le fournisseur A est-il plus rapide que le B sur le même prompt — c'est parfaitement suffisant.

Pourquoi le débit ne dit rien du coût d'une session ?

Parce que les tokens par seconde mesurent à quelle vitesse les tokens arrivent, et votre facture mesure combien sont arrivés. C'est la partie qu'on saute, et c'est la raison pour laquelle le chiffre déçoit ceux qui installent le compteur en espérant qu'il aide sur la dépense. Un modèle à 120 tok/s qui relit onze fois les quatre mêmes fichiers coûte plus cher qu'un modèle à 40 tok/s qui les lit une fois. Le rapide a fini plus tôt et coûté trois fois plus. Débit et coût ne sont pas seulement des chiffres différents, ils vont fréquemment en sens inverse : les fournisseurs qui servent le plus vite sont souvent ceux que vous payez au prix fort, et un modèle plus lent qui demande moins de tours peut terminer la session en ayant dépensé moins. Le débit flatte pour une seconde raison. On le cite généralement sur les tokens de sortie, parce que c'est le flux qu'on regarde arriver. Or dans le trafic d'un agent, l'entrée domine la sortie d'environ un ordre de grandeur : chaque lecture de fichier, chaque sortie de commande, chaque tour de conversation renvoyé est entrant. Un compteur qui surveille le flux de sortie regarde passer le petit côté de votre facture. La formulation honnête est donc : les tokens par seconde répondent à « quel fournisseur répond le plus vite ». Si la question dessous était « pourquoi ça coûte autant », c'est le mauvais instrument, et la répartition entrée/sortie d'opencode stats est le bon. Le détail des flags est dans le guide sur l'usage des tokens opencode.

Que faut-il mesurer à la place ?

La répartition entrée/sortie d'abord, puis les appels d'outils qui produisent l'entrée. Lancez opencode stats --days 7 --tools 20. Deux nombres décident de tout le reste :

Le ratio entrée/sortie. Pour presque toute charge de travail agentique, l'entrée domine. Cela tranche où l'effort vaut la peine : sur ce que l'agent lit, pas sur ce qu'il écrit.
Le classement des outils. Les appels d'outils sont l'endroit où les tokens entrent dans le contexte. Les trois premiers de cette liste sont votre facture.

Ce que stats ne peut pas faire, c'est vous dire que 300k des 800k tokens de lecture de la semaine dernière étaient les mêmes fichiers récupérés encore et encore. Il est rétrospectif et agrégé. Attraper la répétition demande une vue en direct de la session, ce qui relève d'une autre catégorie d'outillage : le cas général est traité dans comment mesurer l'usage des tokens d'un agent.

Comment appliquer ça dès aujourd'hui

Regardez d'abord le pied de réponse. Si la PR #12721 a été fusionnée depuis, vous avez déjà le chiffre et aucun plugin n'est nécessaire.
Si vous voulez un débit en direct, installez @johannus22/opencode-tps-meter en acceptant qu'il soit non officiel et figé en 0.1.2.
Si vous ne voulez qu'une comparaison ponctuelle entre fournisseurs, chronométrez une réponse à la main. Un chiffre, zéro dépendance.
Puis arrêtez de regarder le débit. Lancez opencode stats --days 7 --tools 20 et lisez la répartition entrée/sortie.
Attaquez le premier outil du classement. En pratique, ce sont les lectures de fichiers entiers ou les sorties de commande non filtrées — filtrer la sortie des commandes est en général le gain le plus rapide.

Ce qui cloche en pratique (anti-patterns)

Optimiser pour le débit. Le mode d'échec, c'est de basculer vers le fournisseur au plus haut tok/s et de voir la facture mensuelle monter. Ça arrive parce que le compteur est visible et continu là où la facture arrive une fois par mois : le chiffre rapide capte une attention qu'il ne mérite pas. Lire le débit comme un indicateur de santé. Un tok/s bas signifie que le fournisseur est lent en ce moment. Il ne signifie pas que la session se passe mal, et un tok/s élevé ne signifie pas qu'elle se passe bien. Une session qui patine — relit, replanifie, relance la même commande en échec — peut afficher un excellent débit du début à la fin. Installer le plugin pour répondre à une question de coût. Si vous avez cherché ça à cause d'une facture surprenante, le compteur n'aidera pas, et les vingt minutes passées à l'installer sont vingt minutes non passées sur opencode stats. Prendre un plugin TUI non officiel pour un acquis. Il est en 0.1.2, publié en avril 2026, inchangé depuis. Calibrez vos attentes en conséquence.

À lire aussi :

Réduire l'usage des tokens d'un agent de code — le pilier
Comment réduire l'usage des tokens dans opencode — les flags, les leviers, les coûts
Comment mesurer l'usage des tokens d'un agent — attraper la répétition qu'un total rétrospectif cache