ccusage alternatives that show live spend, not just history
A log reader tells you what a run cost. Something in the request path can change what the next one costs.
Short answer for people who came here from a search box: if you want live spend rather than a morning-after report, you have three categories to choose from. Log readers with a refreshing terminal view (ccusage itself has one, and so does Claude Code Usage Monitor). Hosted gateways and observability platforms that sit in the request path and stream cost into a dashboard (Helicone, Langfuse, LiteLLM, Portkey). And local proxies that sit in the request path on your own machine and can act on what they see, which is the category Probe0 is in.
The distinction that matters is not how often the number refreshes. It is whether the thing watching your spend is downstream of the request or inside it. A log reader can render a counter that updates every second and still be powerless, because by the time the line lands in the log the money is gone. Anything that can pause a run, swap a model, or return a cached answer has to be in the path.
What ccusage is genuinely good at
I want to be fair here, because ccusage is a well-made tool and most of the complaints I see about it are really complaints about what a log reader can be.
It reads the session files Claude Code already writes to disk, adds up token counts by model, and multiplies by published per-model rates. No API keys, no account, no network hop for your prompts. You run it with npx and you have a daily and monthly breakdown in about ten seconds. It has a live block view that tracks the current billing window and refreshes while you work. It is open source, so when a number looks wrong you can go read the arithmetic. The project has been extending beyond Claude Code over time, so check its current README rather than assuming your agent is or is not covered.
For the question "what did last week cost me," that is close to ideal. Zero setup, zero risk, zero ongoing cost. If that is your only question, install ccusage and stop reading. I mean that.
The three things a log reader structurally cannot do
These are not bugs. They fall out of reading a file that something else wrote.
- It cannot intervene. There is no point at which a log reader gets to say no. If an agent enters a retry loop at 2am against an expensive model, ccusage will describe the loop beautifully the next morning.
- It only sees tools that write logs it knows how to parse. Run Claude Code and Codex and Cursor on the same laptop and you are reconciling separate views, or missing some entirely. The number in front of you is a subset of your actual spend, and you cannot tell which subset without checking.
- It infers cost rather than observing it. Token counts times a rate table is a good estimate, but cache reads, cache writes, and negotiated or plan-based pricing all bend the real number. Estimated cost and billed cost drift, and the drift is invisible from inside the estimate.
There is a fourth, softer problem. Per-run attribution gets hazy when several agents and several terminal tabs are working at once. You know the day cost forty dollars. Knowing which process spent it is a different question, and it is usually the one you actually want answered, because that is the one you can act on.
How to pick an alternative
Before comparing products, decide which of these you need. Most people need two or three, not all six, and buying for all six is how you end up with a gateway you have to operate.
- Retrospective accounting. Daily and monthly totals per model. Every option on this page does this.
- Live visibility during a run. A number that moves while the agent works, ideally attributed to the process that caused it.
- Enforcement. A hard cap that warns and then stops, rather than a chart that gets steeper.
- Intervention. Caching, cheaper-model routing, deduplication of identical concurrent calls. This is the only category that lowers the bill rather than describing it.
- Data boundary. Whether your prompts and diffs leave the machine to be counted. For work under NDA this is often the deciding factor, ahead of every feature above.
- Team rollup. Per-seat and per-project spend across a group of developers, with an admin who is not you.
The alternatives, grouped honestly
Other local log readers. Claude Code Usage Monitor is the closest neighbour to ccusage: a terminal dashboard that watches the same local session data and projects forward to when you are likely to run out of your window. Same architectural ceiling, nicer live presentation, and it will tell you a burn rate rather than only a total. If your real problem is "I keep hitting my limit mid-afternoon and I want warning," this is a reasonable stop.
Hosted gateways and observability platforms. Helicone, Langfuse, Portkey, and the LiteLLM proxy all put a service between your code and the provider, then give you per-request cost, latency, traces, and in several cases caching and routing. These genuinely win on things a single-machine tool cannot match: team dashboards, alerting, retention, evaluation tooling, prompt management, provider catalogues that go far beyond what a coding agent calls. Several offer self-hosting if the hosted data boundary is the objection. The cost, and it is a real one for a solo developer, is that you are now running or paying for infrastructure and pointing your agent at a base URL that is not the provider. LiteLLM and Langfuse are open source and self-hostable; the others have free tiers whose exact limits move often enough that you should read their pricing page rather than trust a blog post.
The provider's own view. Anthropic and OpenAI both surface usage in their consoles, and Claude Code can export OpenTelemetry metrics if you already run a metrics stack. Authoritative on billed cost, which is more than any estimator can claim. Slow to update, coarse in attribution, and useless for stopping anything.
Where Probe0 sits
I built Probe0 because I wanted the ccusage answer and the ability to act on it, without sending my prompts to a third party to get either. It is a proxy that runs on your machine. You install it once with a local certificate, and every coding agent CLI on that machine routes through it: Claude Code, Codex, Cursor, without per-tool configuration. There is no Probe0 server. Nothing about your requests leaves the machine except the call to the provider that was going to happen anyway.
Because it is in the path, the ledger records what actually happened rather than what the log implies: model, tokens, real cost, latency, and which process made each call. And because it is in the path, it can do things a reader cannot. Spend Guard takes a hard cap per run or per day, warns, then pauses. Exact Cache serves repeat calls from local disk without touching the network. Semantic Cache matches near-identical prompts against a local vector index with a strict similarity floor, and refuses outright to match anything carrying tool calls, because a wrong hit there corrupts a run in ways that cost more than the call it saved. Request Coalescing collapses simultaneous identical calls into one upstream request. Model Tiering tries a cheap model first. Local Routing sends work to a model already running in Ollama or LM Studio and retries weak answers on the cloud. Every module is individually switchable and reports what it saved, so you can turn one off and watch the number move. Since it knows your real usage, it can also tell you when you are on a plan tier above what you actually consume.
A tool that reports spend is competing on how good the chart is. A tool in the request path is competing on how much smaller the bill got. Those are different products, and only one of them can be wrong in a way that breaks your run.
The honest limits: macOS only, private beta, sign-in through Google or GitHub with an account system that is new. It is not a team gateway, there is no multi-user deployment, and provider coverage is what coding agents call rather than a hundred-provider catalogue. If you need per-seat rollups for eight engineers, use a real gateway. If you are one developer on a Mac who wants live, attributed, enforceable spend without shipping your codebase to a dashboard, that is the case Probe0 was built for.
A reasonable path if you are undecided: keep ccusage for the monthly number, since it costs nothing to keep. Add whichever of the categories above matches the thing that actually annoyed you enough to search for this. If the annoyance was not knowing, a live reader is enough. If it was finding out too late, you need something in the path.