428億トークンを使う人たちを並べてみる

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

背景

• 今年上半期にリリースされたClaude Codeを皮切りに、OpenAI Codex CLI、Google Gemini CLIなど、複数のLLMプロバイダーが本格的にエージェント型コーディングツール（Agentic Coding Tool）を提供し始めた。それにもかかわらず、ほとんどの作業は自分でやっていた
• しかし友人がOpenCodeのセットアップを共有してくれてから、はるかに積極的に使うようになった。複数のエージェントを並列で回して相互にレビューさせたり、探索/実装/検証を分離して作業すると（つまり、トークンを多く使えば使うほど…）、性能が目に見えて上がる。その後、友人は自分のセットアップをオープンソースとして公開し、Oh-My-OpenCodeという名前で2.5k+スターを獲得した（https://github.com/code-yeongyu/oh-my-opencode）
• 友人に会ってから1か月で50億個以上のトークンを使い、すっかり熱狂的ユーザーになった（Claude Max planアカウントの週次使用上限を毎回きっちり使い切っていて、実はサブアカウントを作って停止も食らった）。思ったよりエージェント型ワークフローを活用している人が少ないこともわかった

アイデアの始まり

• ccusageというClaude Codeトークン使用量追跡ツールを知った

• 「Claude Code使用量世界1位の開発者」（Jinhyeongさん!）を扱った記事を読んで、「どうやってトークン使用量1位だとわかったんだろう？」と思って検索したところ、ccusageから取得したデータで作られたリーダーボード、viberank（https://github.com/sculptdotfun/…

• しかし両プロジェクトとも、OpenCode、Codex CLI（ccusageは一部対応）、Gemini CLIなど、他のクライアントのデータには対応していなかった

• ちょうど、トークン生成量をGitHubのContribution Graphで見せたら良さそうだというシャワー中の思いつきもあった。開発者はGitHubに慣れているし、自分を鼓舞する目標を立てやすい形だと個人的に思ったからだ

  • Isometric Contributions (https://github.com/jasonlong/isometric-contributions) - なんと10年前のオープンソースChrome拡張。GitHub contribution graphを3Dアイソメトリックでレンダリングしてくれる → ここから3Dグラフのアイデアを得た
  • GitHub contribution graphでは、さまざまなカラーテーマのアイデアを参考にした
  • フロントエンドではobelisk.js (https://github.com/nicklockwood/obelisk.js)で3Dアイソメトリックレンダリングを実装

• もともと短時間でハッキーなプロダクトを作って反応を見て注目を集めるのが好き（以前の投稿参照）

• CLI/TUI形式でbunx（Bunエコシステムにおけるnpx相当）から気軽に実行でき、APIサーバーへsubmitしてデータを共有し、リーダーボードに名前を載せられるプラットフォームを作ると決めた

プロジェクト名: Tokscale

• カルダシェフ・スケール（Kardashev Scale）(https://ko.wikipedia.org/wiki/カーダシェフ・スケール)から着想を得た

• 文明の技術レベルをエネルギー消費量で分類する尺度（タイプI = 惑星、II = 恒星、III = 銀河）

• AI時代において、トークンは新しいエネルギーだという発想。「planetary developer」から「galactic code architect」まで上っていく旅を可視化しようというコンセプト

• イーロン・マスクは**「電力はお金だ（Electricity is money）」**と言った

  • AI・データセンター時代において、性能の限界は演算ではなく電力供給量にある
  • GPU性能よりも、電力確保・冷却・効率が競争力になる

• これを個人開発者レベルに落とし込むと？

  • LLM APIを使うときに私たちが支払うもの = トークン
  • より多く、より効率的にトークンを使う側が、より多くのコードを生産する
  • トークン = AI時代の個人向けエネルギー単位になるだろう

• AIが電気をお金に変える機械なら、エージェント型コーディングツールはトークンをコードに変える機械

• だからTokscale = Token + Kardashev Scale

  • 「planetary developer」から「galactic code architect」まで上っていく旅を可視化しようというコンセプト
  • トークン消費量で開発者のAI活用レベルを測定

TUI実装

• OpenTUI (https://github.com/sst/opentui)を使ってターミナルUIを作成
• OpenTUIはSSTが開発したTUIフレームワークで、ReactのInkと違ってSolid.jsベース、かつネイティブZigエンジンによるzero-flickerレンダリングを提供する（最近OpenCode と
• 4つのビュー（Overview, Models, Daily, Stats）+ キーボード/マウスナビゲーション
• Contribution Graphに適用される9種類のカラーテーマ: Green, Halloween, Teal, Blue, Pink, Purple, Orange, Monochrome, YlGnBu（GitHub contribution graphコミュニティが作ったテーマ）
• チャートはUnicode block文字（▁▂▃▄▅▆▇█）でレンダリング。モデルごとに異なる色で積み上げて表示

データ取得が遅い → Rustネイティブモジュール

• 最初はTypeScriptでJSONファイル群をパースしていたが、これが遅すぎた
• napi-rs (https://napi.rs/)を使ってRustネイティブコードに移行
• 約8.5倍の性能向上を達成:
  • ファイル探索: ~500ms → ~50ms (10x)
  • JSONパース: ~800ms → ~100ms (8x, simd-json (https://github.com/simd-lite/simd-json) 使用)
  • 集計: ~200ms → ~25ms (8x, rayon (https://github.com/rayon-rs/rayon) 並列処理)
• メモリも約45%削減（ストリーミングパース、zero-copy文字列処理）
• OpenTUIに合わせてbunxをサポートし、npxは廃止。Bunランタイム必須に変更
  • TypeScript CLIでBun.spawnを使ってnative Rustモジュールと通信するサブプロセスを起動し、stdin/stdoutでJSONデータをやり取りする構成
• （OpenCodeを使いすぎて、自分のマシンではこれでも遅くなってきたけど T_T）

データ保持の問題

• エージェント型コーディングツールは、全履歴を**セッション(session)**と呼び、.で始まる隠しディレクトリに保存する
  • Claude Code: ~/.claude/projects/ (JSONL)
  • OpenCode: ~/.local/share/opencode/storage/message/ (個別JSON)
  • Codex CLI: ~/.codex/sessions/ (イベントベースJSONL)
  • Gemini CLI: ~/.gemini/tmp/*/chats/ (JSON)
• Claude CodeとGemini CLIにはデフォルトで30日の保持期間があり、過ぎるとセッションデータが削除される
• これを知って惜しがる人が多かった。READMEに無効化方法を詳しく記載した
  • Claude Code: ~/.claude/settings.jsonに"cleanupPeriodDays": 9999999999を追加
• OpenCodeとCodex CLIは、すべてのセッションファイルが永続保存される（削除機能自体がない）

Cursor IDE連携

• 今はもう使っていないが、しばらくCursor IDEを使っていた時期があった（これも大切な自分のデータなので連携すべき）
• Cursorはローカルセッションファイルではなく、APIベースのCSV exportをサポートしていたのでデータを取得できた
• 開発者ツールを通して、セッショントークン（WorkosCursorSessionToken）があれば認証できることがわかった
  • Networkタブでcursor.com/api/*リクエストのCookieヘッダーから探すか
  • Application → Cookiesから直接コピー
• tokscale cursor login | status | logoutの形にして、すっきり管理

GitHub連携（OAuth）

• Device Flow認証方式で実装
• tokscale login → ブラウザ起動 → コード入力 → トークン発行
• tokscale submitで使用量データをリーダーボードにアップロード
• 提出データはLevel 1検証を通る（数理的一貫性、未来日付なし、重複検知など）

トークン価格計算

• LiteLLMの価格データベース (https://github.com/BerriAI/litellm) からリアルタイム価格情報を取得
• 1時間TTLで~/.cache/tokscale/pricing.jsonにディスクキャッシュ
• 入力/出力/キャッシュ読み取り/キャッシュ書き込み/推論トークンをすべて個別に計算可能
• 段階課金（tiered pricing, 200kトークン以上）にも対応

Wrapped 2025

• Spotify Wrappedに着想を得た年次レビュー画像生成機能（年末をお楽しみに）
• tokscale wrappedを実行するとPNG画像を生成
• @napi-rs/canvas (https://github.com/Brooooooklyn/canvas)で画像をレンダリングし、@resvg/resvg-js (https://github.com/nicklockwood/resvg-js)でSVG→PNG変換
• FigtreeフォントをGoogle Fontsからダウンロードしてキャッシュ
• 含まれる内容: 総トークン、Top 3モデル、Top 3クライアント、Top 3エージェント、メッセージ数、活動日数、コスト、連続記録（streak）、contribution graph

現在のボトルネックと悩み

• 毎回ローカルから収集するため遅く、データベースにアップロードしなければならないのも重い
• 現在はdiffベースのincremental submission最適化を検討中。日付ごとにハッシュを作って変更分だけアップロードする方式を採用したい（過去日付データが修正される余地を残すため）

コードはほぼすべてOh-My-OpenCodeが書いた

• 本当に、ほぼすべてのコードをエージェントが書いた
• 423件以上のコミット、4言語README（EN, KO, JA, ZH-CN）を含む
• GitHubにスクリーンショットを何枚も載せて見栄えよく整えた（ここは人の手が一部入っていると認めるが、プロジェクト全体を作る間にIDEを直接開いてコーディングした時間が30分にも満たなかったことは確かだ）

[roxie]

プロジェクト完成までに、LLM にだいたい何回くらい指示を出したのか気になります