Tokenomics

I build with Claude Code every day, and I kept hitting my token limit mid-session with no warning. The only signal was an error in the terminal — and by then I'd already hit the wall. A feedback loop that only fires after you've failed isn't a feedback loop. It's a postmortem.

I didn't want a reactive alert. An alert interrupts; it arrives too late and asks for attention I don't have mid-thought. I wanted ambient awareness — something glanceable, with zero interaction, that lived at the edge of my vision while I worked.

The first version rendered two concentric rings in the system menu bar. Inner ring is the 5-hour window; outer ring is the 7-day window. Both readable without a click.

The menu bar was the only right surface, and the choice was deliberate. A notification interrupts. A window forces a context switch. A Dock badge is too easy to ignore. The menu bar is always visible, costs zero interaction to read, and lives exactly where your peripheral vision already roams while you code. I leaned on Apple's Activity Rings because the metaphor is culturally pre-loaded — full means done, and no legend is required. I shipped it single-provider, Claude only, on purpose.

A ring at fifty percent is raw data. It tells you where you are. The pace dot marks where the fill should be right now if you were spending evenly across the window. The gap between the dot and the arc is the whole product.

That gap turns utilization into a decision: am I burning ahead of pace, or do I have headroom for a long run? It's an original information-design element, not a stock control I pulled off a shelf. A developer would have shown you the number. This shows you what the number means.

Friends said: cool, but does it work with my tools? Adding a second and third provider sounded like a feature. It was actually an architecture test — because the providers don't agree on anything. Codex exposes a context window, not a rate limit; its rate field is always 0.0, a CLI bug, so I show the context-window fill that matches what the CLI itself prints. Gemini exposes request counts with no reset timer. Three structurally different data models, one visual language. Does the design hold?

It did, behind a provider protocol with a small escape hatch — and the view layer never got rewritten. An abstraction that holds for one input is a coincidence; one that holds for three is a design principle. Then I added Copilot and Cursor, but instead of asking for a new login I leaned on auth the user already had: Copilot through the existing gh CLI token, Cursor through its own local state. Five providers, install-and-forget.

Ambient awareness shouldn't stop when you leave the editor. So I extended the idea to the desktop people stare at between sessions: widgets. The one number a multi-tool developer actually needs is worst-of-N — the single provider closest to its limit, surfaced without having to check each one.

WidgetKit is a hard-constraint surface: no scrolling, fixed sizes, taps only through URL schemes. The layout had to hold from one provider up to eight or more without breaking rhythm. Constraints like these are design inputs, not obstacles — they force the hierarchy to be honest.

There was a contradiction buried in the product. The value prop was ambient visibility for anyone who uses AI tools — but setup required installing Node.js in Terminal. The person it was built for wasn't the person who could finish setting it up.

So I set a sharper constraint and designed to it. To honor it, Tokenomics now ships its own Node runtime — the way Electron ships Chromium — and runs CLI installs as a hidden subprocess. No Terminal, ever. Each provider is labeled Quick (sign in once) or Guided (we walk you through). I also deleted an earlier 'For developers' tier, because that label quietly tells some users they're not smart enough for part of the product. That's a positioning decision hiding inside a single word.

Then the realization that reframed the whole product: the users who'd benefit most from watching their limits — free- and consumer-tier users — had zero visibility, because consumer plans expose no public API. They were the ones flying blind, and they were the ones I couldn't reach.

But a signed-in browser session already holds every credential needed, and a browser extension is the only legitimate bridge to it. So I built the web companion — an extension that reads the user's own authenticated sessions through real endpoints and passive observation, no scraping. It unlocks browser-only tools the Mac app can't reach, including creative AI: Midjourney (the first usage tracker shipped for it anywhere), plus Suno and Udio. The product now spans roughly fourteen providers across two surfaces.

The onboarding I'd just shipped and called done wasn't done. The extension changed the connection model: a provider could now be reached two ways — through the Mac app or through the browser. First-run suddenly had to teach a paired install (connect the extension, link it to the app) and show which path each provider uses, with a small source icon — a globe for web, a terminal for CLI, a key for API.

I reopened a flow I'd only just stabilized and reworked the model, rather than bolting the extension on as a side door. Bolting it on would have been faster and would have read as a seam forever.

Most side projects die in the gap between 'works on my machine' and 'a stranger can install it.' I treated that gap as part of the design. Two channels, two trust signals: a direct download for discoverability, and a Homebrew cask — brew install rob-stout/tap/tokenomics — for the moment a developer actually decides to commit.

The cask build is code-signed, notarized, and auto-updating, because the install is the first interaction and it sets the tone for everything after. Choosing to solve distribution is a product-strategy decision, not an engineering chore — and deciding which channel meets the user at which moment is squarely a design call.