Menschen nach 42,8 Milliarden verwendeten Tokens sortieren

 (github.com/junhoyeo)
18 Punkte von junhoyeo 2025-12-23 | 1 Kommentare | Auf WhatsApp teilen

TL;DR: https://github.com/junhoyeo/tokscale

Hintergrund

  • Angefangen mit Claude Code, das in der ersten Hälfte dieses Jahres veröffentlicht wurde, begannen verschiedene LLM-Provider wie OpenAI Codex CLI und Google Gemini CLI ernsthaft damit, Agentic Coding Tools bereitzustellen. Trotzdem habe ich die meisten Aufgaben weiterhin selbst erledigt
  • Nachdem mir ein Freund jedoch sein OpenCode-Setup gezeigt hatte, habe ich es viel aktiver genutzt. Wenn man mehrere Agenten parallel laufen lässt, sie sich gegenseitig reviewen lässt oder Erkundung/Implementierung/Validierung trennt (also: je mehr Tokens man verbraucht ...), steigt die Leistung spürbar. Später veröffentlichte dieser Freund sein Setup als Open Source unter dem Namen Oh-My-OpenCode und bekam damit 2.5k+ Stars (https://github.com/code-yeongyu/oh-my-opencode)
  • In dem einen Monat nach dem Treffen mit meinem Freund habe ich über 5 Milliarden Tokens verbraucht und bin zum Fanatiker geworden (ich schöpfe derzeit das wöchentliche Nutzungslimit meines Claude-Max-Plan-Kontos komplett aus; tatsächlich habe ich sogar einmal einen Zweitaccount erstellt und wurde gesperrt). Dabei habe ich auch gemerkt, dass überraschend wenige Menschen agentische Workflows nutzen

Der Anfang der Idee

  • Ich bin auf ein Token-Usage-Tracking-Tool für Claude Code namens ccusage gestoßen

  • Nachdem ich einen Artikel über den „weltweit tokenstärksten Claude-Code-Entwickler“ (Jinhyeong!) gelesen hatte, fragte ich mich: „Woher wusste man, dass er bei der Token-Nutzung auf Platz 1 ist?“ Bei der Suche fand ich eine kleine Website namens viberank (https://github.com/sculptdotfun/viberank), ein Leaderboard auf Basis von Daten aus ccusage (ich weiß nicht, ob sie noch gepflegt wird)

  • Beide Projekte unterstützten jedoch keine Daten anderer Clients wie OpenCode, Codex CLI (ccusage nur teilweise) oder Gemini CLI

  • Zufällig hatte ich auch den Duschgedanken, dass es cool wäre, die erzeugte Token-Menge als GitHub-Contribution-Graph darzustellen. Entwickler sind an GitHub gewöhnt, und ich persönlich finde, es ist ein Format, in dem man sich leicht Ziele setzen kann, um sich selbst anzutreiben

    • Isometric Contributions (https://github.com/jasonlong/isometric-contributions) – eine Open-Source-Chrome-Erweiterung, die es schon seit ganzen 10 Jahren gibt. Sie rendert den GitHub-Contribution-Graphen in 3D-Isometrie → von dort habe ich die Idee für den 3D-Graphen übernommen
    • Für den GitHub-Contribution-Graphen habe ich mich von verschiedenen Color-Themes inspirieren lassen
    • Im Frontend wurde die 3D-isometrische Darstellung mit obelisk.js (https://github.com/nicklockwood/obelisk.js) umgesetzt

  • Ursprünglich mag ich es, in kurzer Zeit hacky Produkte zu bauen, Reaktionen zu testen und Aufmerksamkeit zu bekommen (siehe meinen früheren Artikel)

  • Also beschloss ich, eine Plattform zu bauen, die sich als CLI/TUI mit bunx (dem Bun-Pendant zu npx) unkompliziert ausführen lässt und bei der man Daten an einen API-Server submitten, teilen und seinen Namen im Leaderboard platzieren kann

Projektname: Tokscale

  • Inspiriert von der Kardashev-Skala (Kardashev Scale) (https://ko.wikipedia.org/wiki/Kardashev-Skala)

  • Sie ist eine Skala, die das technologische Niveau von Zivilisationen anhand ihres Energieverbrauchs klassifiziert (Typ I = Planet, II = Stern, III = Galaxie)

  • In der KI-Ära sind Tokens die neue Energie. Das Konzept ist, die Reise vom „planetary developer“ bis zum „galactic code architect“ zu visualisieren

  • Elon Musk sagte einmal: „Electricity is money“

    • Im Zeitalter von AI und Rechenzentren liegt die Leistungsgrenze nicht beim Compute, sondern bei der verfügbaren Stromversorgung
    • Wichtiger als GPU-Leistung sind Strombeschaffung, Kühlung und Effizienz

  • Was passiert, wenn man das auf das Niveau einzelner Entwickler herunterbricht?

    • Das, wofür wir beim Einsatz von LLM-APIs bezahlen = Tokens
    • Wer mehr Tokens und diese effizienter nutzt, produziert mehr Code
    • Tokens werden zur persönlichen Energieeinheit im KI-Zeitalter

  • Wenn AI eine Maschine ist, die Strom in Geld verwandelt, dann sind Agentic Coding Tools Maschinen, die Tokens in Code verwandeln

  • Daher Tokscale = Token + Kardashev Scale

    • Das Konzept ist, die Reise vom „planetary developer“ bis zum „galactic code architect“ zu visualisieren
    • Das Niveau der AI-Nutzung von Entwicklern wird anhand ihres Token-Verbrauchs gemessen

TUI-Implementierung

  • Die Terminal-UI wurde mit OpenTUI (https://github.com/sst/opentui) gebaut
  • OpenTUI ist ein von SST entwickeltes TUI-Framework. Anders als Reacts Ink basiert es auf Solid.js und bietet mit einer nativen Zig-Engine zero-flicker Rendering (kürzlich OpenCode und
  • 4 Views (Overview, Models, Daily, Stats) + Tastatur-/Maus-Navigation
  • 9 Color-Themes für den Contribution-Graphen: Green, Halloween, Teal, Blue, Pink, Purple, Orange, Monochrome, YlGnBu (Themes aus der GitHub-Contribution-Graph-Community)
  • Charts werden mit Unicode-Blockzeichen (▁▂▃▄▅▆▇█) gerendert und pro Modell in unterschiedlichen Farben gestapelt dargestellt

Datenimport ist langsam → natives Rust-Modul

  • Am Anfang habe ich JSON-Dateien in TypeScript geparst, aber das war viel zu langsam
  • Mit napi-rs (https://napi.rs/) wurde auf nativen Rust-Code umgestellt
  • Etwa 8,5x Performance-Gewinn erzielt:
  • Auch der Speicherverbrauch sank um etwa 45 % (Streaming-Parsing, zero-copy String-Verarbeitung)
  • Für OpenTUI wurde bunx unterstützt und npx fallengelassen; die Bun-Runtime ist jetzt Pflicht
    • Aus der TypeScript-CLI wird mit Bun.spawn ein Subprozess gestartet, der mit dem nativen Rust-Modul kommuniziert und JSON-Daten über stdin/stdout austauscht
  • (Da ich OpenCode so viel nutze, ist sogar das auf meiner Maschine inzwischen etwas langsam geworden TT)

Problem mit Datenaufbewahrung

  • Agentic Coding Tools bezeichnen ihre gesamte Historie als Session und speichern sie in versteckten Verzeichnissen, die mit . beginnen
    • Claude Code: ~/.claude/projects/ (JSONL)
    • OpenCode: ~/.local/share/opencode/storage/message/ (einzelne JSON-Dateien)
    • Codex CLI: ~/.codex/sessions/ (eventbasiertes JSONL)
    • Gemini CLI: ~/.gemini/tmp/*/chats/ (JSON)
  • Claude Code und Gemini CLI haben standardmäßig eine Retention-Zeit von 30 Tagen; danach werden Session-Daten gelöscht
  • Nachdem die Leute das erfahren hatten, fanden viele das schade. In der README habe ich ausführlich beschrieben, wie man das deaktiviert
    • Claude Code: "cleanupPeriodDays": 9999999999 in ~/.claude/settings.json ergänzen
  • OpenCode und Codex CLI bewahren alle Session-Dateien dauerhaft auf (es gibt nicht einmal eine Löschfunktion)

Cursor-IDE-Integration

  • Ich nutze sie inzwischen nicht mehr, aber eine Zeit lang habe ich Cursor IDE verwendet (und auch das sind wertvolle Daten, also musste es integriert werden)
  • Cursor unterstützt keine lokalen Session-Dateien, sondern CSV-Exports per API, wodurch ich an die Daten kommen konnte
  • Über die Developer Tools fand ich heraus, dass man sich mit dem Session-Token (WorkosCursorSessionToken) authentifizieren kann
    • zu finden im Network-Tab im Cookie-Header von cursor.com/api/*-Requests oder
    • direkt kopierbar unter Application → Cookies
  • Das wurde in der Form tokscale cursor login | status | logout umgesetzt, damit es sauber verwaltet werden kann

GitHub-Integration (OAuth)

  • Implementiert mit Device-Flow-Authentifizierung
  • tokscale login → Browser öffnet sich → Code eingeben → Token ausgestellt
  • Mit tokscale submit werden Nutzungsdaten ins Leaderboard hochgeladen
  • Die eingereichten Daten durchlaufen eine Level-1-Prüfung (mathematische Konsistenz, keine zukünftigen Daten, Duplikatserkennung usw.)

Berechnung der Token-Preise

  • Preisinformationen in Echtzeit werden aus der Pricing-Datenbank von LiteLLM (https://github.com/BerriAI/litellm) geholt
  • Disk-Cache mit 1 Stunde TTL unter ~/.cache/tokscale/pricing.json
  • Separate Berechnung für Input/Output/Cache Read/Cache Write/Reasoning Tokens wird unterstützt
  • Tiered Pricing wird ebenfalls unterstützt (ab 200k Tokens)

Wrapped 2025

  • Funktion zur Erzeugung eines jährlichen Review-Bilds, inspiriert von Spotify Wrapped (freut euch aufs Jahresende)
  • tokscale wrapped erzeugt ein PNG-Bild
  • Bild-Rendering mit @napi-rs/canvas (https://github.com/Brooooooklyn/canvas), SVG→PNG-Konvertierung mit @resvg/resvg-js (https://github.com/nicklockwood/resvg-js)
  • Die Schriftart Figtree wird von Google Fonts heruntergeladen und gecacht
  • Enthalten sind: Gesamtzahl der Tokens, Top 3 Modelle, Top 3 Clients, Top 3 Agenten, Anzahl der Nachrichten, aktive Tage, Kosten, Streak, Contribution-Graph

Aktueller Bottleneck & offene Fragen

  • Es ist langsam und schwergewichtig, die Daten jedes Mal lokal einzusammeln und dann in die Datenbank hochzuladen
  • Aktuell prüfe ich eine diff-basierte Optimierung für inkrementelle Submissions. Dabei sollen Hashes pro Datum erzeugt werden, sodass nur geänderte Teile hochgeladen werden (wobei offen bleiben soll, dass historische Daten nachträglich geändert werden können)

Fast der gesamte Code wurde von Oh-My-OpenCode zusammengeschustert

  • Wirklich fast der gesamte Code wurde vom Agenten geschrieben
  • Über 423 Commits, inklusive README in 4 Sprachen (EN, KO, JA, ZH-CN)
  • Ich habe mehrere Screenshots auf GitHub hochgeladen, damit alles hübsch aussieht (hier muss ich zugeben, dass etwas menschliche Handarbeit drinsteckt, aber ich bin sicher, dass ich während des gesamten Projekts nicht einmal 30 Minuten lang direkt im IDE saß und selbst programmiert habe)

Verwandte Beiträge

1 Kommentare

 
roxie 2025-12-26

Mich würde interessieren, wie oft Sie dem LLM bis zur Fertigstellung des Projekts ungefähr Anweisungen gegeben haben.