May 5, 2026 · live-spend
I built live-spend over a weekend because I was wasting money and time checking three different provider dashboards.
I use OpenAI, Anthropic, and OpenRouter constantly. Each one reports usage differently, and none of them gives me a simple live view while I’m actively working. I was always checking cost after the fact, which is the worst possible timing.
Project: https://github.com/ericdahl-dev/live-spend
Why this matters
If you’re iterating fast with AI, cost isn’t a monthly reporting problem. It’s a runtime problem.
You need to know if you’re burning too fast right now, not tomorrow morning.
Without that feedback loop, you keep expensive experiments running longer than you should and you make routing decisions based on stale data.
What I actually built
The first version is intentionally small and boring:
- polls every 30 seconds
- shows one card per provider
- displays OpenAI spend, Anthropic token usage, and OpenRouter credits
- calculates a simple hourly pace from today’s totals
- keyboard controls:
rto refresh,qto quit
That’s it.
No dashboards. No account system. No “platform” story.
The practical approach
I optimized for something I’d actually keep open all day:
- terminal-first
- low friction
- clear signal
- no setup drama
Under the hood it’s one polling loop, provider-specific adapters, and a normalized state model for the UI. The UI layer doesn’t need to understand each provider’s weird API shape. It just renders what’s available.
This is probably good enough for a first version, and it keeps future changes cheap.
Tradeoffs and annoying parts
Here’s the thing: cross-provider metrics are not perfectly apples-to-apples.
- OpenAI gives spend
- Anthropic usage is token-centric
- OpenRouter exposes credit-oriented numbers
So you still need a little judgment when reading the screen.
The other gotcha is resilience. Internal tools die fast if they assume perfect config. Missing keys and flaky endpoints are normal, so degraded mode matters:
- missing key -> explicit
unconfigured - failed request -> visible error
- working providers keep updating
If you skip this, you’ll stop trusting the tool.
What I’d do next
I wouldn’t overbuild it. I’d add only what improves decisions:
- optional burn-rate alerts
- short trend windows
- clearer labels so mixed metrics are harder to misread
- lightweight daily snapshots
The main takeaway is simple: build the smallest loop that changes behavior.
For me, that loop is now real:
- See usage live
- See pace
- Cut waste sooner