O TokenRats começou com amigos comparando como usavam IA. Alguns de nós consumiam muitos tokens. Outros deixavam parte da capacidade do Claude Code sem uso e não entendiam o que fazíamos para gastar tanto.

Usávamos assinaturas, então cada experimento não parecia uma nova cobrança de API. A pergunta era como aproveitar melhor a capacidade que já tínhamos.

Pensei no GymRats: um motivo compartilhado para aparecer e uma competição amigável. E se fizéssemos algo parecido para construir com IA?

Um incentivo para experimentar

Nosso grupo tem advogados, engenheiros, fundadores e economistas. Queria que cada um encontrasse mais lugares em que a IA pudesse ajudar na própria vida. Um ranking privado oferecia algo pequeno e visível para comparar.

O uso de tokens tornava o experimento fácil de medir. Era uma forma de incentivar tentativas, criar hábitos e conversar sobre o que estávamos aprendendo. O resultado útil estava no que cada pessoa fazia com essa prática.

Vinte minutos antes de embarcar

A experiência que realmente me prendeu aconteceu em um domingo à noite, voltando para São Paulo. Faltava cerca de meia hora para meu voo e eu estava testando uma nova versão do Claude Opus. A capacidade do agente de coordenar outros agentes parecia um avanço enorme.

Passei aproximadamente vinte minutos conversando sobre a ideia e preparando o projeto. Escrevemos um roadmap detalhado, separando o que podia acontecer em paralelo, o que precisava de uma sequência e o que dependia de decisões anteriores. Também registramos as escolhas de tecnologia e o propósito maior do produto.

Isso virou o roadmap, o plano técnico e a missão do projeto. Eu queria que os agentes compartilhassem uma definição do que estavam construindo antes de começar o código.

Então dei uma instrução um pouco brincalhona: trabalhar com subagentes e usar quantos tokens fossem necessários. Combinava com o espírito do TokenRats.

O agente trabalhou por mais de uma hora, aproximadamente o tempo do voo. Quando pousei, havia uma landing page funcionando, bem-acabada e muito próxima da visão que eu tinha descrito.

Aquele voo produziu a primeira landing page funcional. Construir o produto a partir dela também exigiu resolver as partes menos visíveis: coletar o uso, conectar contas, atualizar rankings e tornar a sincronização repetida confiável.

O trabalho ganhou visibilidade

Compartilhar o projeto no LinkedIn foi gratificante por si só. As pessoas fizeram perguntas, questionaram a proposta e passaram a acompanhar o que eu construía.

Isso também levou a uma mudança maior. As publicações ajudaram o time de AI Deployment da Enter a me encontrar. Eles se interessaram pelo projeto e pela minha trajetória e, depois, me convidaram para integrar a equipe.

Da sessão local ao ranking compartilhado

O produto conecta uma aplicação web a uma pequena ferramenta de linha de comando:

Entrar com GitHub e conectar a ferramenta local por um fluxo de aprovação no navegador.
Sincronizar o uso das ferramentas de programação, manualmente ou por um processo em segundo plano.
Entrar em um grupo e comparar a atividade em um período escolhido.
Acompanhar rankings, sequências de dias ativos e desafios como incentivo para continuar experimentando.

O código atual inclui parsers para Claude Code, Codex e Cursor. A sincronização local extrai registros de uso e envia contagens e metadados das sessões. Prompts e respostas não fazem parte desse registro enviado.

A atividade do Cursor é estimada a partir dos eventos locais disponíveis ao parser. Seus totais são estimativas. Os valores em dólares representam um valor estimado de uso, e não quanto alguém efetivamente pagou pela assinatura.

O sistema por trás do experimento

O repositório é um monorepo TypeScript. A aplicação web, a API, a ferramenta de linha de comando e os parsers compartilham um pacote de contratos de dados.

Parte	Implementação
Interface web	Next.js e React, com Tailwind CSS.
API	Hono executado em Cloudflare Workers.
Armazenamento	Cloudflare D1 para sessões, usuários, grupos e agregações diárias.
Sincronização local	CLI em TypeScript com parsers para cada ferramenta.
Contratos compartilhados	Tipos TypeScript e schemas Zod usados pelo sistema.
Atualizações dos grupos	Server-sent events por um Durable Object de cada sala.

apps/web           → perfis, grupos, rankings
apps/api           → autenticação, ingestão, consultas
packages/cli       → descoberta, login, sincronização
packages/parsers   → logs locais para registros de uso
packages/contracts → tipos e validação compartilhados

Um detalhe importante é o que acontece quando a mesma sessão é sincronizada novamente. As sessões crescem enquanto a pessoa trabalha. A ingestão atualiza os totais armazenados e aplica apenas o aumento às agregações diárias, sem contar a sessão inteira duas vezes. Assim, os rankings consultam essas agregações sem percorrer cada sessão bruta.

As atualizações ao vivo verificam a participação no grupo antes de conectar o navegador ao fluxo de eventos da sala. A competição privada foi a razão inicial do produto, então esse limite faz parte da experiência.

Os contratos compartilhados também tornaram o trabalho dos agentes mais prático. Tarefas separadas podiam avançar no CLI, na interface e na API com uma definição comum das informações que passavam entre elas.

O que ficou dessa experiência

Saí daquele voo com outra percepção do que eu podia construir. Investir tempo no propósito, nos limites e na sequência do trabalho deu aos agentes direção suficiente para avançar enquanto eu estava longe.

O TokenRats continua sendo um projeto pessoal que mantenho. Seu efeito mais duradouro em mim foi o hábito que ele incentiva: experimentar a ideia, dar uma forma clara a ela e descobrir o que é possível colocar de pé.