Colocando em fila as pessoas que usam 42,8 bilhões de tokens

 (github.com/junhoyeo)
18 pontos por junhoyeo 2025-12-23 | 1 comentários | Compartilhar no WhatsApp

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

Contexto

  • Começando pelo Claude Code, lançado no primeiro semestre deste ano, vários provedores de LLM como OpenAI Codex CLI e Google Gemini CLI passaram a oferecer de vez ferramentas de codificação agêntica (Agentic Coding Tool). Mesmo assim, eu ainda fazia a maior parte do trabalho manualmente
  • Porém, depois que um amigo compartilhou a configuração dele do OpenCode, passei a usar isso de forma muito mais ativa. Rodando vários agentes em paralelo para revisarem uns aos outros, ou separando exploração/implementação/verificação no fluxo de trabalho (ou seja, quanto mais tokens você usa...), o desempenho melhora de forma visível. Depois disso, esse amigo publicou a configuração dele como open source e recebeu 2.5k+ estrelas com o nome Oh-My-OpenCode (https://github.com/code-yeongyu/oh-my-opencode)
  • Em um mês depois de conhecer esse amigo, usei mais de 5 bilhões de tokens e virei um fanático (estou preenchendo até o limite semanal de uso da conta do plano Claude Max; na verdade, até criei uma conta secundária e fui suspenso). Também percebi que há menos gente do que eu imaginava aproveitando fluxos de trabalho agênticos

O começo da ideia

  • Conheci uma ferramenta de rastreamento de uso de tokens do Claude Code chamada ccusage

  • Li um texto sobre o "desenvolvedor nº 1 do mundo em uso do Claude Code" (Jinhyeong!) e pensei: "como descobriram que ele é o número 1 em uso de tokens?" Pesquisando, encontrei um pequeno site chamado viberank (https://github.com/sculptdotfun/viberank), um leaderboard feito com dados trazidos do ccusage (não sei se ainda é mantido)

  • Mas nenhum dos dois projetos dava suporte a dados de outros clientes, como OpenCode, Codex CLI (o ccusage dá suporte parcial) e Gemini CLI

  • Por coincidência, eu também tinha tido no banho a ideia de que seria legal mostrar a quantidade de tokens gerados em um gráfico de contribuições do GitHub (Contribution Graph). Como desenvolvedores já estão acostumados com o GitHub, pessoalmente achei que seria um formato fácil para definir metas e se cobrar

    • Isometric Contributions (https://github.com/jasonlong/isometric-contributions) - uma extensão open source para Chrome com nada menos que 10 anos. Ela renderiza o gráfico de contribuições do GitHub em 3D isométrico → peguei daí a ideia do gráfico 3D
    • No gráfico de contribuições do GitHub, usei como referência várias ideias de temas de cores
    • No frontend, implementei a renderização 3D isométrica com obelisk.js (https://github.com/nicklockwood/obelisk.js)

  • Originalmente, gosto de criar rápido um produto meio hacky, ver a reação e chamar atenção em pouco tempo (veja o texto anterior)

  • Decidi criar uma plataforma em formato CLI/TUI que pudesse ser executada facilmente com bunx (o equivalente ao npx no ecossistema Bun), enviar dados para compartilhamento via servidor de API e colocar o nome da pessoa no leaderboard

Nome do projeto: Tokscale

  • Inspirado na Escala de Kardashev (Kardashev Scale) (https://ko.wikipedia.org/wiki/Kardashev_Scale)

  • É uma escala que classifica o nível tecnológico de uma civilização pelo consumo de energia (Tipo I = planeta, II = estrela, III = galáxia)

  • Na era da IA, penso que tokens são a nova energia. O conceito é visualizar a jornada que vai de "planetary developer" até "galactic code architect"

  • Elon Musk disse que "Electricity is money"

    • Na era da IA e dos data centers, o limite de desempenho não é computação, mas a oferta de energia
    • Mais do que desempenho de GPU, o diferencial competitivo está em garantir energia, refrigeração e eficiência

  • E se trouxermos isso para o nível do desenvolvedor individual?

    • O que pagamos ao usar APIs de LLM = tokens
    • Quem usa mais tokens, e com mais eficiência, produz mais código
    • Tokens vão se tornar a unidade pessoal de energia na era da IA

  • Se a IA é uma máquina que transforma eletricidade em dinheiro, então ferramentas de codificação agêntica são máquinas que transformam tokens em código

  • Por isso Tokscale = Token + Kardashev Scale

    • O conceito é visualizar a jornada que vai de "planetary developer" até "galactic code architect"
    • Medir o nível de aproveitamento de IA de um desenvolvedor pelo consumo de tokens

Implementação da TUI

  • Usei OpenTUI (https://github.com/sst/opentui) para criar a interface de terminal
  • OpenTUI é um framework de TUI desenvolvido pela SST; ao contrário do Ink do React, ele é baseado em Solid.js e oferece renderização zero-flicker com engine nativa em Zig (recentemente OpenCode e
  • 4 views (Overview, Models, Daily, Stats) + navegação por teclado/mouse
  • 9 temas de cor aplicados ao gráfico de contribuições: Green, Halloween, Teal, Blue, Pink, Purple, Orange, Monochrome, YlGnBu (são temas criados pela comunidade do gráfico de contribuições do GitHub)
  • Os gráficos são renderizados com caracteres Unicode de bloco (▁▂▃▄▅▆▇█). São exibidos empilhados com cores diferentes por modelo

Buscar os dados estava lento → módulo nativo em Rust

  • No começo, eu fazia parsing dos arquivos JSON em TypeScript, mas isso era lento demais
  • Migrei para código nativo em Rust usando napi-rs (https://napi.rs/)
  • Alcancei uma melhoria de desempenho de cerca de 8,5x:
  • Também reduzi o uso de memória em cerca de 45% (parsing em streaming, tratamento de strings zero-copy)
  • Para combinar com o OpenTUI, passei a dar suporte a bunx e removi npx. O runtime Bun se tornou obrigatório
    • Na CLI em TypeScript, a estrutura é executar um subprocesso que se comunica com o módulo nativo em Rust usando Bun.spawn, trocando dados JSON por stdin/stdout
  • (Como eu uso OpenCode demais, até isso ficou lento na minha máquina T_T)

Problema de retenção de dados

  • Ferramentas de codificação agêntica chamam o histórico completo de sessão (session) e o armazenam em diretórios ocultos que começam com .
    • Claude Code: ~/.claude/projects/ (JSONL)
    • OpenCode: ~/.local/share/opencode/storage/message/ (JSON individual)
    • Codex CLI: ~/.codex/sessions/ (JSONL baseado em eventos)
    • Gemini CLI: ~/.gemini/tmp/*/chats/ (JSON)
  • Claude Code e Gemini CLI têm, por padrão, período de retenção de 30 dias; depois disso, os dados das sessões são apagados
  • Depois que descobriram isso, muitas pessoas ficaram com pena de perder os dados. Escrevi no README, em detalhes, como desativar isso
    • Claude Code: adicionar "cleanupPeriodDays": 9999999999 em ~/.claude/settings.json
  • OpenCode e Codex CLI preservam permanentemente todos os arquivos de sessão (nem sequer existe função de exclusão)

Integração com Cursor IDE

  • Hoje já não uso mais, mas por um tempo usei Cursor IDE (e isso também é um dado valioso meu, então precisava integrar)
  • O Cursor não fornece arquivos de sessão locais; em vez disso, oferece exportação de CSV baseada em API, então foi assim que consegui os dados
  • Descobri, pelas ferramentas de desenvolvedor, que era possível autenticar tendo o token de sessão WorkosCursorSessionToken
    • Dá para encontrá-lo no cabeçalho Cookie de requisições cursor.com/api/* na aba Network
    • Ou copiar diretamente em Application → Cookies
  • Organizei isso de forma limpa como tokscale cursor login | status | logout

Integração com GitHub (OAuth)

  • Implementado com autenticação via Device Flow
  • tokscale login → abre o navegador → inserir código → emissão do token
  • tokscale submit faz upload dos dados de uso para o leaderboard
  • Os dados enviados passam por validação de Nível 1 (consistência matemática, ausência de datas futuras, detecção de duplicatas etc.)

Cálculo de preço dos tokens

  • Busca informações de preços em tempo real no banco de dados de preços do LiteLLM (https://github.com/BerriAI/litellm)
  • Cache em disco com TTL de 1 hora em ~/.cache/tokscale/pricing.json
  • Suporte a cálculo separado para tokens de entrada/saída/leitura de cache/escrita de cache/raciocínio
  • Também dá suporte a preços por faixa (tiered pricing, acima de 200k tokens)

Wrapped 2025

  • Recurso de geração de imagem de retrospectiva anual inspirado no Spotify Wrapped (aguardem o fim do ano)
  • Ao executar tokscale wrapped, é gerada uma imagem PNG
  • Renderização da imagem com @napi-rs/canvas (https://github.com/Brooooooklyn/canvas) e conversão SVG→PNG com @resvg/resvg-js (https://github.com/nicklockwood/resvg-js)
  • A fonte Figtree é baixada do Google Fonts e armazenada em cache
  • Conteúdo incluído: total de tokens, Top 3 modelos, Top 3 clientes, Top 3 agentes, número de mensagens, dias de atividade, custo, streak, gráfico de contribuições

Gargalos atuais e dúvidas

  • Buscar tudo localmente toda vez é lento, e precisar fazer upload para o banco de dados é pesado
  • No momento, estou avaliando uma otimização de submissão incremental baseada em diff. A ideia é gerar hashes por data e enviar apenas as partes alteradas (quero deixar em aberto a possibilidade de que dados de datas passadas sejam modificados)

Quase todo o código foi escrito por Oh-My-OpenCode

  • Sério, quase todo o código foi escrito pelo agente
  • Mais de 423 commits, incluindo README em 4 idiomas (EN, KO, JA, ZH-CN)
  • Coloquei várias capturas de tela no GitHub para ficar bonito (aqui admito que houve um pouco de toque humano, mas tenho certeza de que, durante toda a criação do projeto, o tempo que passei realmente codando com a IDE aberta não chegou nem a 30 minutos)

Leituras relacionadas

1 comentários

 
roxie 2025-12-26

Tenho curiosidade em saber aproximadamente quantos comandos foram dados ao LLM até a conclusão do projeto.