A friendly competition that changed how I build

TokenRats began with friends comparing how they used AI. Some of us were spending a lot of tokens. Others were letting their Claude Code allowance go unused and could not understand what we were doing with so much of it.

We were using subscriptions, so each experiment did not feel like another API bill. The question was how to use more of the capacity we already had.

I thought of GymRats: a shared reason to show up and a little competition between friends. What if we did the same thing for building with AI?

A nudge to experiment

Our group includes lawyers, engineers, founders, and economists. I wanted each person to find more places where AI could help in their own life. A private ranking gave us something small and visible to compare.

Token use made the experiment easy to measure. It was a way to encourage people to try things, build habits, and talk about what they were learning. The useful outcome was what someone did with that practice.

Twenty minutes before boarding

The experience that really hooked me happened while I was returning to São Paulo on a Sunday evening. I had about half an hour before my flight and was trying a new Claude Opus release. The agent’s ability to coordinate other agents felt like a large step forward.

I spent roughly twenty minutes talking through the idea and preparing the project. We wrote a detailed roadmap, marking which tasks could run in parallel, which had to run in sequence, and which depended on earlier decisions. We also wrote down the technology choices and the larger purpose of the product.

Those became the project’s roadmap, technical plan, and mission. I wanted the agents to have a shared definition of what they were building before they started writing code.

Then I gave a deliberately playful instruction: work with subagents and use as many tokens as needed. It suited the spirit of TokenRats.

The agent kept working for more than an hour, about the length of the flight. When I landed, there was a working landing page that felt polished and closely matched the vision I had described.

That flight produced the first working landing page. Building the product beyond it meant solving the less visible problems too: collecting usage, connecting accounts, updating rankings, and making repeated synchronization reliable.

The work became visible

Sharing the project on LinkedIn was rewarding in its own right. People asked questions, challenged the idea, and paid attention to what I was building.

It also led to a larger change. My posts helped Enter’s AI Deployment team find me. They became interested in the project and my background, and later invited me to join.

From a local session to a shared ranking

The product connects a web app to a small command-line tool:

1. Sign in with GitHub and connect the command-line tool through a browser approval flow.
2. Synchronize usage from local coding tools, either manually or with a background watcher.
3. Join a group and compare activity over a selected period.
4. Follow rankings, streaks, and challenges as an incentive to keep experimenting.

The current code includes parsers for Claude Code, Codex, and Cursor. The local synchronization path extracts usage records and uploads counts and session metadata. Prompts and completions are not part of that upload record.

Cursor activity is estimated from the local events available to the parser. Its totals are estimates. Dollar figures in the product represent estimated usage value; they are not a statement of what a subscriber actually paid.

The system behind the experiment

The repository is a TypeScript monorepo. The web app, API, command-line tool, and parsers share a package of data contracts.

Part	Implementation
Web interface	Next.js and React, with Tailwind CSS.
API	Hono running on Cloudflare Workers.
Storage	Cloudflare D1 for sessions, users, groups, and daily aggregates.
Local synchronization	A TypeScript CLI with parsers for each supported tool.
Shared contracts	TypeScript types and Zod schemas used across the system.
Live group updates	Server-sent events through a Durable Object for each room.

apps/web          → profiles, groups, rankings
apps/api          → authentication, ingestion, queries
packages/cli      → discovery, login, synchronization
packages/parsers  → local logs to usage records
packages/contracts → shared types and validation

One important detail is what happens when the same session is synchronized again. Sessions grow while someone is working. The ingestion code updates stored totals and applies the increase to daily aggregates, rather than counting the whole session twice. Rankings can then read those aggregates without scanning every raw session.

Live room updates check membership before connecting a browser to the room’s event stream. Private competition was the original reason for the product, so the group boundary matters to the experience.

The shared contracts also made the agent workflow more practical. Separate tasks could work on the CLI, interface, and API with an agreed shape for the information passing between them.

What stayed with me

I left that flight with a different sense of what I could build. Spending time on the purpose, the boundaries, and the sequence of work gave the agents enough direction to make useful progress while I was away.

TokenRats is still a personal project I maintain. Its most lasting effect on me has been the habit it encourages: try the idea, give it a clear shape, and see what you can make work.