Classer les personnes qui consomment 42,8 milliards de tokens

TLDR: https://github.com/junhoyeo/tokscale

Contexte

• Depuis Claude Code, lancé au premier semestre de cette année, plusieurs fournisseurs de LLM ont commencé à proposer sérieusement des outils de coding agentique (Agentic Coding Tool), comme OpenAI Codex CLI ou Google Gemini CLI. Malgré cela, je faisais encore la plupart des choses moi-même
• Mais après qu’un ami m’a partagé sa configuration OpenCode, je me suis mis à l’utiliser bien plus activement. En faisant tourner plusieurs agents en parallèle pour qu’ils se relisent entre eux, ou en séparant exploration / implémentation / validation (autrement dit, plus on consomme de tokens...), les performances augmentent de façon visible. Ensuite, cet ami a publié sa configuration en open source sous le nom de Oh-My-OpenCode et a obtenu plus de 2,5k étoiles (https://github.com/code-yeongyu/oh-my-opencode)
• En un mois après avoir rencontré cet ami, j’ai utilisé plus de 5 milliards de tokens et je suis devenu un véritable fanatique (je remplis au maximum la limite hebdomadaire d’utilisation de mon compte Claude Max plan ; en fait, j’ai même créé un compte secondaire qui a fini suspendu). J’ai aussi découvert qu’il y avait moins de gens que je ne le pensais qui exploitent vraiment les workflows agentiques

Le début de l’idée

• J’ai découvert ccusage, un outil de suivi de la consommation de tokens de Claude Code

• Après avoir lu un article sur le « développeur n°1 mondial en consommation de Claude Code » (Jinhyeong !), je me suis demandé : « Comment sait-on qu’il est n°1 en consommation de tokens ? » En cherchant, j’ai trouvé un petit site appelé viberank (https://github.com/sculptdotfun/viberank), un leaderboard construit à partir de données récupérées via ccusage (je ne sais pas s’il est encore maintenu aujourd’hui)

• Mais aucun de ces deux projets ne prenait en charge les données d’autres clients comme OpenCode, Codex CLI (prise en charge partielle dans ccusage), Gemini CLI, etc.

• J’avais aussi eu cette idée sous la douche : ce serait bien d’afficher le volume de tokens générés sous forme de graphe de contributions GitHub. Les développeurs sont familiers avec GitHub, et je trouve personnellement que c’est un format qui permet de se fixer facilement des objectifs pour se pousser soi-même

  • Isometric Contributions (https://github.com/jasonlong/isometric-contributions) — une extension Chrome open source vieille de 10 ans. Elle rend le graphe de contributions GitHub en 3D isométrique → c’est de là que vient l’idée du graphe 3D
  • Pour le graphe de contributions GitHub, je me suis inspiré de différentes idées de thèmes de couleurs
  • Côté frontend, le rendu 3D isométrique est implémenté avec obelisk.js (https://github.com/nicklockwood/obelisk.js)

• À la base, j’aime créer rapidement des produits un peu bricolés, voir les réactions et attirer l’attention (voir mon article précédent)

• J’ai donc décidé de créer une plateforme sous forme de CLI/TUI, exécutable simplement avec bunx (l’équivalent de npx dans l’écosystème Bun), qui permet de soumettre des données à un serveur API pour les partager et faire apparaître son nom dans le leaderboard

Nom du projet : Tokscale

• Inspiré de l’échelle de Kardashev (Kardashev Scale) (https://ko.wikipedia.org/wiki/Kardashev_cheokdo)

• C’est une échelle qui classe le niveau technologique des civilisations selon leur consommation d’énergie (type I = planète, II = étoile, III = galaxie)

• Dans l’ère de l’IA, je pense que les tokens sont la nouvelle énergie. Le concept est de visualiser le parcours qui mène de « planetary developer » à « galactic code architect »

• Elon Musk a dit : « Electricity is money »

  • À l’ère de l’IA et des data centers, la limite de performance n’est plus le calcul mais l’approvisionnement électrique
  • Plus que la performance des GPU, ce sont l’accès à l’électricité, le refroidissement et l’efficacité qui deviennent l’avantage concurrentiel

• Si on ramène ça au niveau du développeur individuel ?

  • Ce que nous payons quand nous utilisons une API de LLM = des tokens
  • Plus on utilise de tokens, et de manière efficace, plus on produit de code
  • Les tokens deviendront l’unité personnelle d’énergie à l’ère de l’IA

• Si l’IA est une machine qui transforme l’électricité en argent, alors les outils de coding agentique sont des machines qui transforment les tokens en code

• Donc Tokscale = Token + Kardashev Scale

  • Le concept est de visualiser le parcours qui mène de « planetary developer » à « galactic code architect »
  • Mesurer le niveau d’usage de l’IA d’un développeur via sa consommation de tokens

Implémentation du TUI

• Le terminal UI est construit avec OpenTUI (https://github.com/sst/opentui)
• OpenTUI est un framework TUI développé par SST ; contrairement à Ink de React, il repose sur Solid.js et fournit un rendu zero-flicker grâce à un moteur natif en Zig (récemment OpenCode et
• 4 vues (Overview, Models, Daily, Stats) + navigation clavier / souris
• 9 thèmes de couleurs appliqués au graphe de contributions : Green, Halloween, Teal, Blue, Pink, Purple, Orange, Monochrome, YlGnBu (des thèmes créés par la communauté du graphe de contributions GitHub)
• Les graphiques sont rendus avec des caractères de bloc Unicode (▁▂▃▄▅▆▇█). Ils sont affichés en pile avec une couleur différente pour chaque modèle

La récupération des données était lente → module natif Rust

• Au début, j’analysais les fichiers JSON en TypeScript, mais c’était beaucoup trop lent
• Passage à du code natif Rust avec napi-rs (https://napi.rs/)
• Environ 8,5x d’amélioration des performances :
  • Exploration des fichiers : ~500ms → ~50ms (10x)
  • Parsing JSON : ~800ms → ~100ms (8x, avec simd-json (https://github.com/simd-lite/simd-json))
  • Agrégation : ~200ms → ~25ms (8x, traitement parallèle avec rayon (https://github.com/rayon-rs/rayon))
• Environ 45 % de mémoire économisée aussi (parsing en streaming, traitement zero-copy des chaînes)
• Support de bunx adapté à OpenTUI, abandon de npx. Le runtime Bun devient obligatoire
  • Depuis le CLI TypeScript, Bun.spawn lance un sous-processus qui communique avec le module natif Rust, et les données JSON transitent via stdin/stdout
• (Comme j’utilise beaucoup trop OpenCode, même ça a fini par devenir lent sur ma machine T_T)

Problème de rétention des données

• Les outils de coding agentique appellent l’ensemble de l’historique une session et le stockent dans des répertoires cachés commençant par un point
  • Claude Code: ~/.claude/projects/ (JSONL)
  • OpenCode: ~/.local/share/opencode/storage/message/ (JSON individuels)
  • Codex CLI: ~/.codex/sessions/ (JSONL basé sur des événements)
  • Gemini CLI: ~/.gemini/tmp/*/chats/ (JSON)
• Claude Code et Gemini CLI ont une période de rétention par défaut de 30 jours ; une fois écoulée, les données de session sont supprimées
• Quand les gens l’ont appris, beaucoup ont trouvé ça dommage. J’ai donc détaillé dans le README comment désactiver cela
  • Claude Code: ajouter "cleanupPeriodDays": 9999999999 dans ~/.claude/settings.json
• OpenCode et Codex CLI conservent tous les fichiers de session de manière permanente (il n’y a même pas de fonction de suppression)

Intégration de Cursor IDE

• Je ne l’utilise plus maintenant, mais j’ai utilisé Cursor IDE pendant un certain temps (et comme c’est aussi une donnée précieuse pour moi, il fallait l’intégrer)
• Cursor ne fournit pas de fichiers de session locaux, mais un export CSV via API, ce qui permettait de récupérer les données
• J’ai découvert qu’on pouvait s’authentifier via le token de session (WorkosCursorSessionToken) accessible depuis les outils de développement
  • Dans l’onglet Network, dans l’en-tête Cookie des requêtes cursor.com/api/*
  • Ou en le copiant directement via Application → Cookies
• J’ai créé une interface propre sous la forme tokscale cursor login | status | logout

Intégration GitHub (OAuth)

• Implémentée avec le mode d’authentification Device Flow
• tokscale login → ouverture du navigateur → saisie du code → émission du token
• tokscale submit permet d’envoyer les données de consommation vers le leaderboard
• Les données soumises passent une validation de niveau 1 (cohérence mathématique, absence de dates futures, détection des doublons, etc.)

Calcul du prix des tokens

• Les informations de tarification en temps réel sont récupérées depuis la base de données de prix de LiteLLM (https://github.com/BerriAI/litellm)
• Cache disque avec TTL d’1 heure dans ~/.cache/tokscale/pricing.json
• Prise en charge d’un calcul séparé pour les tokens d’entrée / sortie / lecture de cache / écriture de cache / inférence
• Prise en charge aussi de la tarification par paliers (tiered pricing, au-delà de 200k tokens)

Wrapped 2025

• Fonction de génération d’image récapitulative annuelle inspirée de Spotify Wrapped (à attendre en fin d’année)
• tokscale wrapped génère une image PNG
• Rendu de l’image avec @napi-rs/canvas (https://github.com/Brooooooklyn/canvas), conversion SVG→PNG avec @resvg/resvg-js (https://github.com/nicklockwood/resvg-js)
• Téléchargement et mise en cache de la police Figtree depuis Google Fonts
• Contenu inclus : total des tokens, top 3 des modèles, top 3 des clients, top 3 des agents, nombre de messages, nombre de jours actifs, coût, série d’activité (streak), graphe de contributions

Goulot d’étranglement actuel & réflexion

• Le fait de tout rebalayer en local à chaque fois est lent, et devoir ensuite uploader vers la base de données reste lourd
• J’étudie actuellement une optimisation de soumission incrémentale basée sur les diff. L’idée serait de créer des hash par date pour n’uploader que les parties modifiées (tout en laissant la possibilité que des données d’anciennes dates soient modifiées)

Tout le code a été pondu par Oh-My-OpenCode

• Vraiment, presque tout le code a été écrit par des agents
• Plus de 423 commits, avec un README en 4 langues (EN, KO, JA, ZH-CN)
• J’ai mis plusieurs captures d’écran sur GitHub pour rendre le tout plus joli (là, je reconnais qu’il y a eu un peu de travail humain, mais je peux affirmer avec certitude que, sur toute la durée du projet, je n’ai pas passé ne serait-ce que 30 minutes à coder en ouvrant directement l’IDE)

[roxie]

Je me demande à peu près combien de fois vous avez donné des instructions au LLM jusqu’à l’achèvement du projet.