Tools that tell you which process actually made the expensive call, ranked
One axis here, stated up front so you can disagree with it before you read the list. When a call costs more than you expected, can the tool tell you which process on your machine made it, without you having modified that process? Not which model. Not which API key. Which running program. Almost every tool below can give you a per-model total, and several give you far richer traces than I do once you instrument your own code. But the agent CLIs on my laptop are not my code. Claude Code, Codex and Cursor do not tag their outbound calls with anything I chose, so any tool whose attribution depends on headers or SDK spans I inject is going to lose on this specific axis and win on others.
- 1SProbe0I built the ledger around this column. Because the proxy runs on the same machine as the agents and terminates the connection locally, every row records the originating process alongside model, tokens, real cost and latency. Nothing gets instrumented, no header gets added to Claude Code. One proxy plus a certificate installed once, and Codex and Cursor show up in the same ledger. macOS only, private beta, single-developer scope.
- 2ALiteLLMSelf-hostable proxy with virtual keys, tags and per-key spend tracking. If you issue a separate key per agent CLI and set each tool to use its own key, you get attribution that is nearly as good, and LiteLLM covers far more providers than I do. The catch is that the granularity is the key, not the process, so two Claude Code windows sharing a key collapse into one line.
- 3AHeliconeProxy-based observability with custom properties and session grouping, plus a self-hosted option. Attribution is excellent when you control the client and can set the property headers. For a third-party CLI you cannot edit, you are back to inferring from key and user agent.
- 4BLangfuseOpen source, self-hostable tracing with sessions, users and metadata on every trace. The trace model is genuinely better than mine for multi-step application debugging. It expects you to instrument the caller, which is exactly the thing you cannot do for a vendor-shipped agent binary.
- 5BOpenLLMetryOpenTelemetry instrumentation for LLM calls, so you inherit OTel resource attributes including process-level ones. Closest thing on this list to real process attribution by design. It applies to applications you instrument, not to closed agent CLIs, and you need a collector and backend before you see anything.
- 6BccusageLocal CLI that reads Claude Code's own JSONL session logs and breaks cost down by session, project and day. Fully offline, no proxy, no certificate, and it is the fastest way to answer where did today go if Claude Code is your only agent. It sees Claude Code and nothing else.
- 7BClaude Code Usage MonitorTerminal dashboard that watches Claude Code usage and burn rate live from local data. Good ambient awareness while a long run is going. Same scope limit as ccusage: one tool, and it reports against plan limits rather than attributing calls across the processes on your machine.
- 8BPortkeyHosted gateway with metadata-based filtering, budgets and guardrails, plus routing features I do not have. Cost views slice by whatever metadata you attach, which again assumes you control the client. Traffic leaves your machine to reach the gateway.
- 9CCloudflare AI GatewaySits in front of provider APIs and gives you logs, caching and analytics per gateway with very little setup. It has no concept of a local process, so the finest attribution available is one gateway per thing you want to separate.
- 10COpenRouterBroad model catalog behind one API, with an activity view broken down by API key. Provisioning a key per tool gets you rough attribution, and the model coverage is far wider than mine. It only sees traffic you deliberately point at OpenRouter.
- 11CVercel AI GatewaySingle endpoint across providers with usage and observability in the Vercel dashboard, aimed at deployed apps. Attribution lands at the project or app level, which is the right unit for production and the wrong unit for a laptop running three agents at once.
- 12CDatadog LLM ObservabilityThe most serious operational tooling on this list by a wide margin, with traces, service tags and alerting wired into everything else you already monitor. Its unit of attribution is a deployed service, and it wants an agent and instrumentation. Nobody is installing this to find out why Cursor spent four dollars on tab completion.
Method: I took the question a developer actually asks when a bill looks wrong, which is which of the things running on this machine did that, and checked whether each tool can answer it without the developer having modified the caller. Tools that can only answer per model, per key or per project are ranked below tools that can answer per caller, even where the lower-ranked tool is more capable overall. That is a narrow axis and I picked it because it is the one I built for, so read the ranking as a statement about fit rather than about quality.
Probe0 wins here for a structural reason rather than a clever one. The proxy is on localhost, so at the moment a connection arrives I can see which process opened it, and that identifier goes into the same ledger row as the token counts and the real cost. There is no server involved and the ledger never leaves the machine. Everything above the ledger, including local routing to Ollama or LM Studio, cheap-model tiering, exact and semantic caching, request coalescing and the spend cap, reports its savings into those same rows, so the attribution column and the savings column agree with each other. That is the whole trick.
Credit where it is due. LiteLLM and Helicone both get very close with per-key or per-property attribution and both can be self-hosted, and both cover more providers than I do. Langfuse and OpenLLMetry have trace models that make mine look thin once you are debugging a multi-step chain in your own code. ccusage is genuinely delightful and costs you nothing to try if Claude Code is your only agent. Datadog is what you want when the question is about a production service with a pager attached rather than a laptop.
Where I lose: there is no team deployment, no shared dashboard, no multi-user gateway, no Linux or Windows build, and the provider list is whatever coding agents call rather than a hundred-plus catalog. If you need per-seat cost reporting across an engineering org, pick something above from the A and B rows and stop reading. If the question is which process on your own machine spent the money, that is the one thing this list is ordered by.