Attributing AI agent spend to the process that actually made the call

You open the provider dashboard, see yesterday's spend is triple normal, and have no way to answer the only question that matters: which of the four things you had running caused it. The answer is process-level attribution — tagging every outbound request with the PID (or a stable process identity) of whatever made it, before it leaves your machine, so the ledger can be grouped by process instead of just by model or by day.

Most people never get this because the attribution has to happen upstream of the API call, and almost nothing in a normal setup sits upstream of the API call. The provider's own usage page only knows about your API key. It has no idea whether the request came from Claude Code running a long refactor, Cursor's background indexer, or a Codex session you forgot was still open in another window. If you have three coding agents open at once — which is common now that agentic CLIs are cheap to spin up — the bill is a merged stream with the seams sanded off.

Why the model-level view isn't enough

Provider dashboards group by API key, sometimes by model, occasionally by a custom header if you remembered to set one. None of that tells you about the process. A single API key can be shared by every agent on your machine, which is the default case for most developers who set OPENAI_API_KEY or ANTHROPIC_API_KEY once in their shell profile and never touch it again. Once that's true, the model-level breakdown collapses three different tools into one undifferentiated stack of tokens.

This matters because agent cost spikes are rarely evenly distributed. In my own usage, one runaway agentic loop — a retry storm where an agent kept re-reading the same 40k-token file on every turn because a tool call was silently failing — accounted for most of a day's spend by itself, while two other sessions running in parallel were cheap and boring. Without process attribution, that loop is invisible inside the daily total. You'd see the total was high and have no lead on why.

What actually has to be logged

A request ledger that supports real attribution needs more than tokens and cost. At minimum:

• Process identity — PID, parent process name, or a stable label per launched agent
• Timestamp with enough resolution to reconstruct a session's shape, not just a daily bucket
• Model actually used, since tiering or fallback can change this mid-session
• Real cost per call, computed from the provider's own rate for that model and token count, not an estimate
• Latency, because a process burning money slowly usually looks different from one burning it in a retry burst

The process field is the one that's missing almost everywhere. Token counters and cost trackers are common; process-scoped ones are rare, because they require sitting between the agent and the network rather than parsing logs after the fact.

Two ways to get there

The straightforward route is a local proxy that every agent's traffic passes through. Set each CLI's base URL (or, better, a system-wide proxy plus a trusted local certificate so you don't have to touch per-tool config at all) to point at something running on localhost. That process sees the outbound request, knows which PID opened the connection, and can stamp the ledger before forwarding upstream. This is architecturally simple but only works if you actually route every agent through it — a proxy that catches two of your three tools still leaves a blind spot.

The other route is log parsing after the fact: pull each tool's own usage export (several coding CLIs write local session logs) and reconcile them against the provider's billing API by timestamp. This works without touching your network path at all, which is its real advantage — it's non-invasive and low-risk. The cost is that reconciliation is fragile. Timestamps drift, retried requests can double-count, and any tool that doesn't write a usable local log is a silent gap in the total. It's a reasonable first pass if you only have one agent and want a rough weekly number; it stops being trustworthy the moment you're trying to catch a spike in near real time across several tools at once.

Where Probe0 fits

I built Probe0 because I kept hitting exactly this gap — a bill that moved and no way to say which terminal did it. It's a local proxy for AI coding agents, currently macOS-only and in private beta, with no server component: everything runs on your machine. You install one proxy and a certificate once, and every coding agent CLI you have — Claude Code, Codex, Cursor — routes through it without per-tool configuration, because it sits at the OS network layer rather than requiring each tool to be told about it individually.

The Recording module keeps the full request ledger: model, tokens, real cost, latency, and which process made each call. That last field is the point of this whole piece — it's what turns 'my spend went up' into 'the Codex session in tab 3 re-ran the same 12k-token prompt 40 times.' Probe0 also has a Spend Guard that can cap spend per run or per day and pause before you find out from the invoice, which is the natural next step once attribution tells you where the leak is.

To be direct about the limits: this is a single-developer, single-machine tool. It isn't a team gateway, it doesn't aggregate spend across a company's seats, and it only sees traffic from coding-agent CLIs on the box it's installed on, not a hundred-provider catalog of every API you might call. If you need org-wide attribution across a team, a hosted gateway with centralized logging is the right shape of tool, and it's a different problem than the one this post is about.

A five-minute check you can run today

Before installing anything, you can get a partial answer with what you have. Close every agent except one, run a representative task, and note the provider's usage delta. Repeat per tool. It's slow, it doesn't catch concurrent sessions, and it won't catch a spike that happens because two agents were open at once — but it will tell you, in isolation, whether one tool is simply heavier than the others per unit of work. That's often enough to know where to look first, even before you have a ledger that can answer the question for you automatically.

The invoice tells you what model got called. It never tells you which terminal tab called it.