Poniendo en fila a la gente que usa 42.8 mil millones de tokens

 (github.com/junhoyeo)
18 puntos por junhoyeo 2025-12-23 | 1 comentarios | Compartir por WhatsApp

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

Contexto

  • Empezando por Claude Code, lanzado en la primera mitad de este año, varios proveedores de LLM como OpenAI Codex CLI y Google Gemini CLI comenzaron a ofrecer en serio herramientas de codificación agéntica (Agentic Coding Tool). Aun así, la mayoría del trabajo seguía haciéndolo yo directamente
  • Pero después de que un amigo me compartió su setup de OpenCode, empecé a usarlo mucho más activamente. Si haces correr varios agentes en paralelo para que se revisen entre sí, o separas exploración/implementación/verificación (es decir, mientras más tokens uses...), el rendimiento sube de forma notable. Después, ese amigo publicó su setup como open source y consiguió más de 2.5k estrellas con el nombre Oh-My-OpenCode (https://github.com/code-yeongyu/oh-my-opencode)
  • Tras conocer a ese amigo, en un mes usé más de 5 mil millones de tokens y me volví un fanático total (estoy llenando al máximo el límite semanal de uso de una cuenta Claude Max plan; de hecho hasta me suspendieron por hacer una cuenta secundaria). También me di cuenta de que hay menos gente de la que esperaba aprovechando workflows agénticos

El inicio de la idea

  • Conocí ccusage, una herramienta para rastrear el uso de tokens de Claude Code

  • Leí un texto sobre el "desarrollador número 1 del mundo en uso de Claude Code" (¡Jinhyung-hyung!) y pensé: "¿cómo supieron que era el número 1 en uso de tokens?". Buscando, encontré un pequeño sitio llamado viberank (https://github.com/sculptdotfun/viberank), un leaderboard hecho con datos tomados de ccusage (no sé si aún se mantiene)

  • Pero ninguno de los dos proyectos soportaba datos de otros clientes como OpenCode, Codex CLI (ccusage solo lo soporta parcialmente), Gemini CLI, etc.

  • Justo además había tenido una de esas ideas de ducha: estaría bueno mostrar la generación de tokens como un gráfico de contribuciones de GitHub. Los desarrolladores ya están acostumbrados a GitHub y, personalmente, me parecía un formato fácil para fijarse metas y exigirse a uno mismo

  • Originalmente me gusta hacer productos medio hacky en poco tiempo, ver la reacción y atraer atención (ver texto anterior)

  • Decidí crear una plataforma en formato CLI/TUI que pudiera ejecutarse fácilmente con bunx (el equivalente a npx en el ecosistema Bun), y que permitiera compartir datos enviándolos a un servidor API para aparecer en el leaderboard

Nombre del proyecto: Tokscale

  • Inspirado en la escala de Kardashev (Kardashev Scale) (https://ko.wikipedia.org/wiki/Kardashev_cheokdo)

  • Es una escala que clasifica el nivel tecnológico de una civilización según su consumo de energía (Tipo I = planetaria, II = estelar, III = galáctica)

  • La idea es que, en la era de la IA, los tokens son una nueva forma de energía. El concepto es visualizar el viaje desde "planetary developer" hasta "galactic code architect"

  • Elon Musk dijo que "la electricidad es dinero (Electricity is money)"

    • En la era de la IA y los centros de datos, el límite del rendimiento ya no es el cómputo sino el suministro eléctrico
    • Más que el rendimiento de la GPU, la ventaja competitiva está en asegurar energía, enfriamiento y eficiencia

  • ¿Y si bajamos eso al nivel de un desarrollador individual?

    • Lo que pagamos al usar una API de LLM = tokens
    • Quien usa más tokens, y de forma más eficiente, produce más código
    • Los tokens se volverán la unidad personal de energía en la era de la IA

  • Si la IA es una máquina que convierte electricidad en dinero, las herramientas de codificación agéntica son máquinas que convierten tokens en código

  • Por eso Tokscale = Token + Kardashev Scale

    • El concepto es visualizar el viaje desde "planetary developer" hasta "galactic code architect"
    • Medir el nivel de aprovechamiento de IA de un desarrollador según su consumo de tokens

Implementación de la TUI

  • Construí la UI de terminal usando OpenTUI (https://github.com/sst/opentui)
  • OpenTUI es un framework TUI desarrollado por SST que, a diferencia de Ink de React, está basado en Solid.js y ofrece renderizado zero-flicker con un motor nativo en Zig (recientemente OpenCode y
  • 4 vistas (Overview, Models, Daily, Stats) + navegación con teclado y mouse
  • 9 temas de color aplicables al gráfico de contribuciones: Green, Halloween, Teal, Blue, Pink, Purple, Orange, Monochrome, YlGnBu (son temas creados por la comunidad del gráfico de contribuciones de GitHub)
  • Los gráficos se renderizan con caracteres Unicode block (▁▂▃▄▅▆▇█). Se muestran apilados por modelo con colores distintos

Obtener los datos era lento → módulo nativo en Rust

  • Al principio parseaba los archivos JSON con TypeScript, pero era demasiado lento
  • Lo migré a código nativo en Rust usando napi-rs (https://napi.rs/)
  • Logré una mejora de rendimiento de alrededor de 8.5x:
  • También reduje el uso de memoria en aproximadamente 45% (parseo por streaming, manejo zero-copy de strings)
  • Para ajustarlo a OpenTUI, añadí soporte para bunx y eliminé npx. Ahora Bun runtime es obligatorio
    • La estructura es que desde el CLI en TypeScript se usa Bun.spawn para ejecutar un subproceso que se comunica con el módulo nativo en Rust, intercambiando datos JSON por stdin/stdout
  • (Eso sí, como uso demasiado OpenCode, incluso esto ya se me volvió lento en mi máquina T_T)

Problema de retención de datos

  • Las herramientas de codificación agéntica llaman sesión (session) al historial completo y lo guardan en directorios ocultos que empiezan con .
    • Claude Code: ~/.claude/projects/ (JSONL)
    • OpenCode: ~/.local/share/opencode/storage/message/ (JSON individuales)
    • Codex CLI: ~/.codex/sessions/ (JSONL basado en eventos)
    • Gemini CLI: ~/.gemini/tmp/*/chats/ (JSON)
  • Claude Code y Gemini CLI tienen por defecto un período de retención de 30 días; cuando se cumple, los datos de sesión se eliminan
  • Cuando la gente se enteró de esto, a muchos les dio pena perder esos datos. Dejé en el README instrucciones detalladas para desactivarlo
    • Claude Code: agregar "cleanupPeriodDays": 9999999999 a ~/.claude/settings.json
  • OpenCode y Codex CLI conservan permanentemente todos los archivos de sesión (ni siquiera tienen función de borrado)

Integración con Cursor IDE

  • Aunque ya no lo uso, durante un tiempo sí usé Cursor IDE (y esos también son datos valiosos, así que había que integrarlos)
  • Cursor no ofrece archivos de sesión locales, sino exportación CSV vía API, y así pude obtener los datos
  • Descubrí mediante las herramientas de desarrollador que se podía autenticar con el token de sesión (WorkosCursorSessionToken)
    • Puede encontrarse en el header Cookie de las solicitudes cursor.com/api/* en la pestaña Network
    • O copiarse directamente desde Application → Cookies
  • Lo convertí en algo limpio de manejar con tokscale cursor login | status | logout

Integración con GitHub (OAuth)

  • Implementado con autenticación Device Flow
  • tokscale login → se abre el navegador → se ingresa el código → se emite el token
  • Con tokscale submit se suben los datos de uso al leaderboard
  • Los datos enviados pasan por validación de Nivel 1 (consistencia matemática, sin fechas futuras, detección de duplicados, etc.)

Cálculo del precio de tokens

  • Obtiene información de precios en tiempo real desde la base de datos de precios de LiteLLM (https://github.com/BerriAI/litellm)
  • Caché en disco con TTL de 1 hora en ~/.cache/tokscale/pricing.json
  • Soporta cálculo separado de tokens de entrada/salida/lectura de caché/escritura de caché/razonamiento
  • También soporta precios por tramos (tiered pricing, más de 200k tokens)

Wrapped 2025

  • Función para generar una imagen de resumen anual inspirada en Spotify Wrapped (espérenla a fin de año)
  • Al ejecutar tokscale wrapped se genera una imagen PNG
  • Renderiza la imagen con @napi-rs/canvas (https://github.com/Brooooooklyn/canvas) y convierte SVG→PNG con @resvg/resvg-js (https://github.com/nicklockwood/resvg-js)
  • Descarga y cachea la fuente Figtree desde Google Fonts
  • Incluye: total de tokens, Top 3 modelos, Top 3 clientes, Top 3 agentes, cantidad de mensajes, días de actividad, costo, racha (streak), gráfico de contribuciones

Cuello de botella actual y dudas

  • Cada vez hay que raspar los datos localmente, así que es lento, y además subirlos a la base de datos resulta pesado
  • Ahora mismo estoy evaluando una optimización de envíos incrementales basada en diff. Quiero adoptar un enfoque de generar hashes por fecha y subir solo lo que cambió (dejando abierta la posibilidad de que se modifiquen datos de fechas pasadas)

Todo el código lo armó Oh-My-OpenCode

  • De verdad, casi todo el código lo escribió el agente
  • Más de 423 commits, incluyendo README en 4 idiomas (EN, KO, JA, ZH-CN)
  • Subí varias capturas a GitHub para que se viera bonito (aquí sí admito que hubo un poco de mano humana, pero puedo asegurar que, durante toda la creación del proyecto, el tiempo total que pasé codificando directamente con el IDE abierto no llegó ni a 30 minutos)

Lecturas relacionadas

1 comentarios

 
roxie 2025-12-26

Me da curiosidad saber aproximadamente cuántas veces le dieron instrucciones al LLM hasta completar el proyecto.