Tokenomics
Developers don't leave their terminal to check token usage anymore. One month. One designer. Shipped.
50+
Developers using daily
1 month
Concept to shipped
5
AI providers
v2.5
Current version
“AI developers need to know if they have headroom for a long coding session. That data exists — it's just in the wrong place. The only signal was an error in the terminal, mid-session, after you'd already hit the wall.”
My role
Solo designer. Product vision, UX design, information design, AI-assisted SwiftUI implementation, distribution pipeline, documentation.
Where judgment was required
The moments that shaped the product.
A split composition. Left side: a page of the UX doc — the 'Weather App Model' section visible with the key architectural decision highlighted. Right side: the shipped popover matching the doc's description. A connecting arrow or visual alignment between doc spec and shipped UI. Caption zone: 'Spec written before implementation. Shipped code matched it.'
A UX spec that predicted the shipped architecture
Before building multi-provider support, I wrote a full UX document specifying the 'Weather App Model,' worst-of-N menu bar logic, a sublabelOverride escape hatch, and a tabbed popover. The shipped code matched the spec. Design documentation that leads engineering — not follows it — is rare. This case study proves it can happen on a solo project.
Two rings rendered at exactly the same fill percentage (50%) side by side. Left ring: no pace dot, just the arc. Right ring: pace dot visible at a different angular position (behind the fill arc). Below each: small label 'raw data' vs. 'actionable signal.' The rings should be rendered at approximately 3x the actual menu bar size so the dot reads clearly.
The pace dot: from data to decision in one visual element
A ring at 50% fill is raw data — it tells you where you are. The pace dot marks where fill should be right now if consumption were perfectly even. That transforms utilization into a decision: am I burning ahead of pace, or do I have headroom? This is an original information design element, not a UI component. A developer would have shown you the number. This shows you what the number means.
Two screenshots of the reset label in the popover. Left: 'Resets Friday' with a subtle visual marker indicating it IS Friday. Right: 'Resets today.' Same day, two versions of the same line.
Two lines of Swift. One edge case that ships wrong if you're not paying attention.
On Friday, showing 'Resets Friday' is technically correct and practically useless. This edge case only becomes visible when you think from the user's temporal context, not the system's. The fix is two lines of Swift. The insight — that a day label has to be relative to now, not literal — is what separates a shipped product from a deployed prototype.
The popover About view, or a small label diagram. Left column: provider-specific language ('7-day window,' 'model context window,' 'daily request cap'). Right column: behavioral language ('nearest limit,' 'broader context'). An arrow connecting each left-side label to its right-side equivalent.
When the label breaks, describe the behavior instead
When the outer ring means '7-day window' for Claude, 'model context window' for Codex, and 'daily request cap' for Gemini, provider-specific labels break. The solution: 'nearest limit' and 'broader context' — labels that describe what the ring does, not what the provider calls it. That's content architecture. The 320pt popover is the wrong surface for a lookup table.
Terminal output of the release pipeline running, with key stages visible (signing, notarization, Cask update). The craft of shipping visualized as a designed system, not a script.
Distribution is a design problem
The gap between 'working prototype' and 'product strangers can install' is where most side projects die. The 10-stage automated release pipeline — code signing, notarization, Homebrew Cask, Sparkle auto-update, GitHub Releases — exists to eliminate the installation friction that stops adoption. Deciding to solve the distribution problem is a product strategy decision, not an engineering one.
Process
Developers leaving the terminal to check usage in a browser — a glanceability gap.
Apple Activity Rings are culturally pre-loaded. No legend required. The pace dot adds the missing temporal dimension.
Single-provider MVP, then multi-provider expansion without rebuilding views.
Homebrew Cask, code signing, notarization, Sparkle auto-update. Product strangers can install.
What Shipped
50+
Daily users
5
AI providers
v2.5
Current version
0
View layer rewrites
Shipped via Homebrew Cask and GitHub Releases — code signed, notarized, auto-updating. 50+ developers use it daily. Five AI providers supported without rewriting the view layer. Currently at v2.5 with an active roadmap. Open source.
- 50+ developers use it daily — adopted without a single marketing effort
- Five AI providers supported: zero changes to the view layer for each addition
- 10-stage automated release pipeline from source to installed app
- Shipped in one month, solo, from observation to product strangers download
What I Learned
The difference between data and signal is the most undervalued problem in information design. A ring at 50% is a number with a shape. The pace dot is a judgment: you are ahead of pace, or you have room. Those are not the same thing, and the distance between them is where most dashboards fail. The second lesson came from multi-provider expansion — when provider-specific labels stopped working across five different API conventions, the solution was behavioral language that describes what the ring does rather than what the provider calls it. That's content architecture, not copywriting. It only becomes visible as a design problem when your system scales past the first use case.
What this demonstrates