Mengurutkan orang-orang yang menghabiskan 42,8 miliar token

 (github.com/junhoyeo)
18 poin oleh junhoyeo 2025-12-23 | 1 komentar | Bagikan ke WhatsApp

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

Latar belakang

  • Dimulai dari Claude Code yang dirilis pada paruh pertama tahun ini, berbagai LLM Provider seperti OpenAI Codex CLI dan Google Gemini CLI mulai serius menyediakan agentic coding tool. Meski begitu, sebagian besar pekerjaan tetap saya lakukan sendiri
  • Namun, setelah seorang teman membagikan setup OpenCode miliknya, saya jadi menggunakannya jauh lebih aktif. Menjalankan beberapa agen secara paralel agar saling mereview, atau memisahkan eksplorasi/implementasi/verifikasi dalam alur kerja (dengan kata lain, semakin banyak token yang dipakai...) membuat performanya meningkat secara nyata. Setelah itu teman saya merilis setup-nya sebagai open source dengan nama Oh-My-OpenCode dan mendapatkan 2.5k+ bintang (https://github.com/code-yeongyu/oh-my-opencode)
  • Dalam sebulan setelah bertemu teman itu, saya memakai lebih dari 5 miliar token dan berubah jadi fanatik (saya menghabiskan penuh batas penggunaan mingguan akun Claude Max plan, bahkan sempat membuat akun cadangan lalu kena suspend). Saya juga sadar bahwa ternyata belum banyak orang yang memanfaatkan agentic workflow

Awal ide

  • Saya mengetahui tool pelacak penggunaan token Claude Code bernama ccusage

  • Setelah membaca tulisan tentang "developer pengguna Claude Code nomor 1 di dunia" (Jinhyung-nim!), saya berpikir, "Bagaimana mereka tahu dia nomor 1 dalam penggunaan token?" Saat mencari, ternyata ada situs kecil bernama viberank (https://github.com/sculptdotfun/viberank), sebuah leaderboard yang dibuat dari data yang diambil dari ccusage (saya tidak tahu apakah masih dipelihara sekarang)

  • Namun, kedua proyek tersebut tidak mendukung data dari klien lain seperti OpenCode, Codex CLI (ccusage mendukung sebagian), Gemini CLI, dan sebagainya

  • Kebetulan saya juga sempat punya shower thoughts bahwa akan menarik jika jumlah token yang dihasilkan ditampilkan dalam bentuk GitHub Contribution Graph. Developer juga sudah akrab dengan GitHub, dan menurut saya format seperti ini memudahkan untuk menetapkan target yang bisa dipakai untuk memacu diri sendiri

  • Saya memang suka membuat produk hacky dengan cepat, melihat reaksinya, lalu menarik perhatian (lihat tulisan sebelumnya)

  • Saya pun memutuskan membuat platform berbentuk CLI/TUI yang bisa dijalankan ringan lewat bunx (padanan npx di ekosistem Bun), lalu mengirimkan data ke API server untuk dibagikan dan menaikkan nama ke leaderboard

Nama proyek: Tokscale

  • Terinspirasi dari Kardashev Scale (https://ko.wikipedia.org/wiki/Kardashev_jeokdo)

  • Ini adalah skala yang mengklasifikasikan tingkat teknologi peradaban berdasarkan konsumsi energinya (Tipe I = planet, II = bintang, III = galaksi)

  • Saya melihat token sebagai energi baru di era AI. Konsepnya adalah memvisualisasikan perjalanan naik dari "planetary developer" hingga "galactic code architect"

  • Elon Musk pernah berkata "Electricity is money"

    • Di era AI dan data center, batas performa bukan lagi komputasi, melainkan pasokan listrik
    • Bukan sekadar performa GPU, melainkan kemampuan mendapatkan listrik, pendinginan, dan efisiensi yang menjadi daya saing

  • Jika ini ditarik ke level developer individu?

    • Yang kita bayar saat memakai LLM API = token
    • Pihak yang memakai token lebih banyak dan lebih efisien akan menghasilkan lebih banyak kode
    • Token akan menjadi satuan energi pribadi di era AI

  • Jika AI adalah mesin yang mengubah listrik menjadi uang, maka agentic coding tool adalah mesin yang mengubah token menjadi kode

  • Karena itu Tokscale = Token + Kardashev Scale

    • Konsepnya adalah memvisualisasikan perjalanan naik dari "planetary developer" hingga "galactic code architect"
    • Mengukur tingkat pemanfaatan AI seorang developer berdasarkan konsumsi token

Implementasi TUI

  • TUI terminal dibuat menggunakan OpenTUI (https://github.com/sst/opentui)
  • OpenTUI adalah framework TUI yang dikembangkan oleh SST; berbeda dari Ink milik React, OpenTUI berbasis Solid.js dan menyediakan rendering zero-flicker dengan engine Zig native (baru-baru ini OpenCode dan
  • 4 view (Overview, Models, Daily, Stats) + navigasi keyboard/mouse
  • 9 tema warna untuk contribution graph: Green, Halloween, Teal, Blue, Pink, Purple, Orange, Monochrome, YlGnBu (tema-tema ini dibuat oleh komunitas GitHub contribution graph)
  • Chart dirender menggunakan karakter blok Unicode (▁▂▃▄▅▆▇█). Ditampilkan bertumpuk dengan warna berbeda untuk tiap model

Mengambil data itu lambat → modul native Rust

  • Awalnya saya mem-parsing file-file JSON dengan TypeScript, tetapi terlalu lambat
  • Saya beralih ke kode native Rust menggunakan napi-rs (https://napi.rs/)
  • Berhasil mendapatkan peningkatan performa sekitar 8.5x:
  • Memori juga berkurang sekitar 45% (streaming parsing, pemrosesan string zero-copy)
  • Disesuaikan dengan OpenTUI, ditambahkan dukungan bunx dan npx dihapus. Bun runtime menjadi wajib
    • Pada TypeScript CLI, Bun.spawn digunakan untuk menjalankan subprocess yang berkomunikasi dengan modul Rust native, lalu bertukar data JSON melalui stdin/stdout
  • (Karena saya terlalu sering memakai OpenCode, bahkan ini pun terasa lambat di mesin saya uu)

Masalah retensi data

  • Agentic coding tool menyebut seluruh riwayat sebagai session, dan menyimpannya di hidden directory yang diawali dengan titik
    • Claude Code: ~/.claude/projects/ (JSONL)
    • OpenCode: ~/.local/share/opencode/storage/message/ (JSON individual)
    • Codex CLI: ~/.codex/sessions/ (JSONL berbasis event)
    • Gemini CLI: ~/.gemini/tmp/*/chats/ (JSON)
  • Claude Code dan Gemini CLI memiliki periode retensi default 30 hari; setelah itu, data session dihapus
  • Setelah tahu ini, banyak orang merasa sayang jika data itu hilang. Di README saya tulis detail cara menonaktifkannya
    • Claude Code: tambahkan "cleanupPeriodDays": 9999999999 ke ~/.claude/settings.json
  • OpenCode dan Codex CLI menyimpan semua file session secara permanen (bahkan tidak ada fitur hapus)

Integrasi Cursor IDE

  • Sekarang saya sudah tidak memakainya lagi, tetapi sempat menggunakan Cursor IDE selama beberapa waktu (dan ini juga data berharga saya, jadi harus diintegrasikan)
  • Cursor mendukung ekspor CSV berbasis API, bukan file session lokal, sehingga datanya bisa diperoleh
  • Saya mengetahui bahwa autentikasi dimungkinkan jika memiliki session token (WorkosCursorSessionToken) melalui developer tools
    • Bisa ditemukan di header Cookie dari request cursor.com/api/* pada tab Network, atau
    • Disalin langsung dari Application → Cookies
  • Saya membuatnya dalam bentuk tokscale cursor login | status | logout agar pengelolaannya rapi

Integrasi GitHub (OAuth)

  • Diimplementasikan dengan metode autentikasi Device Flow
  • tokscale login → browser terbuka → masukkan kode → token diterbitkan
  • Data penggunaan diunggah ke leaderboard dengan tokscale submit
  • Data yang dikirim akan melewati verifikasi Level 1 (konsistensi matematis, tidak ada tanggal masa depan, deteksi duplikasi, dll.)

Perhitungan harga token

  • Mengambil informasi harga real-time dari database harga milik LiteLLM (https://github.com/BerriAI/litellm)
  • Cache disk dengan TTL 1 jam di ~/.cache/tokscale/pricing.json
  • Mendukung perhitungan terpisah untuk input/output/cache read/cache write/reasoning token
  • Juga mendukung tiered pricing (lebih dari 200k token)

Wrapped 2025

  • Fitur pembuatan gambar ulasan tahunan yang terinspirasi dari Spotify Wrapped (nantikan di akhir tahun)
  • Menjalankan tokscale wrapped akan menghasilkan gambar PNG
  • Rendering gambar menggunakan @napi-rs/canvas (https://github.com/Brooooooklyn/canvas), dan konversi SVG→PNG menggunakan @resvg/resvg-js (https://github.com/nicklockwood/resvg-js)
  • Font Figtree diunduh dari Google Fonts lalu di-cache
  • Isi yang disertakan: total token, Top 3 model, Top 3 klien, Top 3 agen, jumlah pesan, jumlah hari aktif, biaya, streak, contribution graph

Bottleneck saat ini & hal yang sedang dipikirkan

  • Setiap kali harus mengambil dari lokal sehingga lambat, dan kewajiban mengunggah ke database juga terasa berat
  • Saat ini sedang mempertimbangkan optimasi incremental submission berbasis diff. Rencananya memakai pendekatan membuat hash per tanggal lalu hanya mengunggah bagian yang berubah (agar tetap membuka kemungkinan data tanggal lampau ikut berubah)

Semua kode ditulis oleh Oh-My-OpenCode

  • Benar-benar hampir semua kode ditulis oleh agen
  • Termasuk lebih dari 423 commit dan README dalam 4 bahasa (EN, KO, JA, ZH-CN)
  • Saya juga mengunggah banyak screenshot ke GitHub agar tampil menarik (untuk bagian ini saya akui ada sedikit sentuhan manusia, tetapi saya yakin total waktu saya benar-benar membuka IDE dan menulis kode langsung selama membuat seluruh proyek ini bahkan tidak sampai 30 menit)

Bacaan terkait

1 komentar

 
roxie 2025-12-26

Saya penasaran kira-kira berapa kali perintah diberikan kepada LLM sampai proyeknya selesai.