428 करोड़ टोकन इस्तेमाल करने वालों की कतार लगाकर देखना

 (github.com/junhoyeo)
18 पॉइंट द्वारा junhoyeo 2025-12-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें

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

पृष्ठभूमि

  • इस साल की पहली छमाही में रिलीज़ हुए Claude Code से शुरू होकर OpenAI Codex CLI, Google Gemini CLI जैसे कई LLM Provider ने गंभीरता से agentic coding tool उपलब्ध कराने शुरू किए। इसके बावजूद ज़्यादातर काम मैं खुद ही कर रहा था
  • लेकिन एक दोस्त ने अपना OpenCode setup साझा किया, उसके बाद मैं इसे कहीं ज़्यादा सक्रिय रूप से इस्तेमाल करने लगा। कई agents को parallel में चलाकर एक-दूसरे से review करवाना, या exploration/implementation/verification को अलग करके काम करने पर (यानी, जितने ज़्यादा tokens इस्तेमाल करो...) performance साफ़ तौर पर बेहतर होती है। बाद में उसी दोस्त ने अपना setup open source में जारी किया और Oh-My-OpenCode नाम से 2.5k+ stars पाए (https://github.com/code-yeongyu/oh-my-opencode)
  • उस दोस्त से मिलने के बाद एक महीने में 5 अरब से ज़्यादा tokens इस्तेमाल करके मैं लगभग कट्टर समर्थक बन गया (Claude Max plan अकाउंट की साप्ताहिक usage limit पूरी भरकर इस्तेमाल कर रहा हूँ, सच कहूँ to alt account बनाया था और वह suspend भी हो गया)। साथ ही यह भी पता चला कि agentic workflow का इस्तेमाल करने वाले लोग उम्मीद से कम हैं

आइडिया की शुरुआत

  • ccusage नाम का Claude Code token usage tracking tool पता चला

  • "Claude Code usage में दुनिया का नंबर 1 developer" (Jinhyung-nim!) पर एक लेख पढ़कर मन में आया, "इसे कैसे पता चला कि token usage में कोई नंबर 1 है?" खोजने पर पता चला कि ccusage से लाए गए data के आधार पर बना leaderboard viberank (https://github.com/sculptdotfun/viberank) नाम की एक छोटी site थी (अभी maintain हो रही है या नहीं, पता नहीं)

  • लेकिन दोनों projects OpenCode, Codex CLI (ccusage कुछ हद तक support करता है), Gemini CLI जैसे दूसरे clients के data को support नहीं करते थे

  • इसी बीच नहाते समय यह भी ख्याल आया कि token generation को GitHub contribution graph की तरह दिखाया जाए तो अच्छा रहेगा। Developers GitHub UI से परिचित भी होते हैं, और खुद को अनुशासित करने लायक लक्ष्य तय करने के लिए यह format मुझे व्यक्तिगत रूप से अच्छा लगा

    • Isometric Contributions (https://github.com/jasonlong/isometric-contributions) - पूरे 10 साल पुराना open source Chrome extension। यह GitHub contribution graph को 3D isometric में render करता है → यहीं से 3D graph का आइडिया लिया
    • GitHub contribution graph के लिए अलग-अलग color theme ideas से भी प्रेरणा ली
    • frontend में obelisk.js (https://github.com/nicklockwood/obelisk.js) से 3D isometric rendering लागू की

  • मुझे वैसे भी कम समय में जल्दी से एक hacky product बनाकर लोगों की प्रतिक्रिया देखना और attention पाना पसंद है (पिछला लेख देखें)

  • मैंने तय किया कि CLI/TUI फॉर्म में ऐसा platform बनाऊँ जिसे bunx (Bun ecosystem में npx जैसा tool) से बिना झिझक चलाया जा सके, API server पर submit करके data share किया जा सके, और leaderboard पर नाम चढ़ाया जा सके

प्रोजेक्ट का नाम: Tokscale

  • Kardashev Scale (https://ko.wikipedia.org/wiki/Kardashev_Scale) से प्रेरणा ली

  • यह सभ्यता के तकनीकी स्तर को energy consumption के आधार पर वर्गीकृत करने का scale है (Type I = ग्रह, II = तारा, III = आकाशगंगा)

  • AI युग में token ही नई energy है, ऐसा सोचा। concept यह है कि "planetary developer" से "galactic code architect" तक जाने की यात्रा को visualise किया जाए

  • Elon Musk ने कहा था "Electricity is money"

    • AI और data center के युग में performance की सीमा computation नहीं बल्कि power supply है
    • GPU performance से ज़्यादा power procurement, cooling और efficiency ही प्रतिस्पर्धात्मक बढ़त है

  • अगर इसे व्यक्तिगत developer स्तर पर उतारें तो?

    • LLM API इस्तेमाल करते समय हम जो चुकाते हैं = tokens
    • जो ज़्यादा और ज़्यादा कुशलता से tokens इस्तेमाल करेगा, वही ज़्यादा code बनाएगा
    • tokens = AI युग की व्यक्तिगत energy unit बनेंगे

  • अगर AI बिजली को पैसे में बदलने वाली मशीन है, तो agentic coding tools token को code में बदलने वाली मशीन हैं

  • इसलिए Tokscale = Token + Kardashev Scale

    • concept यह है कि "planetary developer" से "galactic code architect" तक जाने की यात्रा को visualise किया जाए
    • token consumption के आधार पर developer की AI उपयोग क्षमता को मापा जाए

TUI इम्प्लीमेंटेशन

  • terminal UI बनाने के लिए OpenTUI (https://github.com/sst/opentui) का इस्तेमाल किया
  • OpenTUI, SST द्वारा विकसित TUI framework है। React के Ink से अलग, यह Solid.js आधारित है और native Zig engine के साथ zero-flicker rendering देता है (हाल में OpenCode और
  • 4 views (Overview, Models, Daily, Stats) + keyboard/mouse navigation
  • contribution graph पर लागू होने वाली 9 color themes: Green, Halloween, Teal, Blue, Pink, Purple, Orange, Monochrome, YlGnBu (ये GitHub contribution graph community द्वारा बनाई गई themes हैं)
  • charts को Unicode block characters (▁▂▃▄▅▆▇█) से render किया गया। model के अनुसार अलग color में stack करके दिखाया

data लाना धीमा था → Rust native module

  • शुरुआत में TypeScript से JSON files parse की थीं, लेकिन यह बहुत धीमा था
  • napi-rs (https://napi.rs/) का इस्तेमाल करके Rust native code में बदला
  • लगभग 8.5x performance improvement हासिल हुआ:
  • memory usage भी लगभग 45% कम हुई (streaming parsing, zero-copy string processing)
  • OpenTUI के हिसाब से bunx support किया और npx को drop कर दिया। Bun runtime को अनिवार्य बना दिया
    • TypeScript CLI में Bun.spawn का इस्तेमाल करके native Rust module से बात करने वाला subprocess चलाया जाता है, और stdin/stdout से JSON data का आदान-प्रदान होता है
  • (OpenCode इतना ज़्यादा इस्तेमाल कर चुका हूँ कि मेरे machine पर यह भी अब थोड़ा धीमा हो गया है T_T)

data retention समस्या

  • agentic coding tools पूरे history record को session कहते हैं, और इसे . से शुरू होने वाली hidden directory में store करते हैं
    • Claude Code: ~/.claude/projects/ (JSONL)
    • OpenCode: ~/.local/share/opencode/storage/message/ (अलग-अलग JSON)
    • Codex CLI: ~/.codex/sessions/ (event-based JSONL)
    • Gemini CLI: ~/.gemini/tmp/*/chats/ (JSON)
  • Claude Code और Gemini CLI में default 30-day retention period होता है, जिसके बाद session data delete हो जाता है
  • यह जानने के बाद कई लोगों को अफ़सोस हुआ। README में इसे disable करने का तरीका विस्तार से लिखा
    • Claude Code: ~/.claude/settings.json में "cleanupPeriodDays": 9999999999 जोड़ें
  • OpenCode और Codex CLI में सभी session files स्थायी रूप से सुरक्षित रहती हैं (delete feature ही नहीं है)

Cursor IDE इंटीग्रेशन

  • अब मैं इसका इस्तेमाल नहीं करता, लेकिन कुछ समय तक Cursor IDE इस्तेमाल किया था (यह भी मेरा कीमती data है, इसलिए integration होना चाहिए)
  • Cursor local session files के बजाय API-based CSV export support करता है, इसलिए data लिया जा सका
  • developer tools के ज़रिए पता चला कि session token (WorkosCursorSessionToken) होने पर authentication संभव है
    • Network tab में cursor.com/api/* requests के Cookie header में इसे ढूँढ सकते हैं
    • या Application → Cookies से सीधे copy कर सकते हैं
  • इसे tokscale cursor login | status | logout फॉर्म में बनाया ताकि साफ़-सुथरा management हो सके

GitHub इंटीग्रेशन (OAuth)

  • Device Flow authentication method से इम्प्लीमेंट किया
  • tokscale login → browser खुलता है → code enter करें → token जारी
  • tokscale submit से usage data leaderboard पर upload करें
  • submitted data पर Level 1 verification लागू होती है (mathematical consistency, future date न होना, duplicate detection आदि)

token pricing गणना

  • LiteLLM का pricing database (https://github.com/BerriAI/litellm) से real-time pricing information लाई
  • 1-hour TTL के साथ ~/.cache/tokscale/pricing.json में disk cache
  • input/output/cache read/cache write/reasoning tokens सभी के लिए अलग-अलग calculation support
  • tiered pricing (200k tokens से ऊपर) भी support

Wrapped 2025

  • Spotify Wrapped से प्रेरित annual review image generation feature (साल के अंत में इंतज़ार कीजिए)
  • tokscale wrapped चलाने पर PNG image generate होती है
  • @napi-rs/canvas (https://github.com/Brooooooklyn/canvas) से image rendering, @resvg/resvg-js (https://github.com/nicklockwood/resvg-js) से SVG→PNG conversion
  • Google Fonts से Figtree font download करके cache किया
  • शामिल सामग्री: total tokens, Top 3 models, Top 3 clients, Top 3 agents, message count, active days, cost, streak, contribution graph

मौजूदा bottleneck और चिंताएँ

  • हर बार local से scrape करना धीमा है, और database में upload करना भारी पड़ता है
  • अभी diff-based incremental submission optimization पर विचार चल रहा है। हर तारीख़ के लिए hash बनाकर सिर्फ़ बदले हुए हिस्से upload करने का तरीका अपनाने की सोच है (ताकि पिछले दिनों के data में बदलाव की गुंजाइश बनी रहे)

लगभग सारा code Oh-My-OpenCode ने लिखा

  • सचमुच लगभग पूरा code agent ने लिखा
  • 423 से ज़्यादा commits, और 4-language README (EN, KO, JA, ZH-CN) भी शामिल
  • GitHub पर कई screenshots डालकर इसे सुंदर बनाया गया (यह मानता हूँ कि इसमें इंसानी हाथ थोड़ा लगा है, लेकिन पूरे project को बनाते समय IDE खोलकर सीधे coding करने में 30 मिनट भी नहीं लगाए, इस बात का मुझे भरोसा है)

संबंधित पढ़ाई

1 टिप्पणियां

 
roxie 2025-12-26

मुझे जिज्ञासा है कि प्रोजेक्ट पूरा होने तक आपने LLM को लगभग कितनी बार निर्देश दिए।