Tracking spend across multiple Claude projects

Why one aggregate number stops being useful past a certain point

A single combined spend figure is fine when there's one integration to account for. Past that, it tells you very little about what's actually driving cost — a spike in the total could be one project's usage growing organically, a misconfigured retry loop in a completely different project, or a model swap somewhere nobody flagged as a cost-relevant change. Without spend broken out per project, every investigation into "why did the bill go up" starts from zero rather than from a shortlist of likely culprits.

Tagging at the point of the request, not after the fact

The only reliable way to attribute spend per project is tagging or logging that information at the point each request is actually sent, alongside the usage block that request returns — trying to reconstruct attribution after the fact from aggregate billing data alone is much harder and often simply impossible if the underlying requests weren't distinguishable to begin with. Build the attribution into your request-logging layer from the start of a new project, not as something to retrofit once spend has already become large enough to worry about.

Shared infrastructure makes attribution harder, not easier

A shared request-building layer used across several projects is good practice for consistency, but it can quietly erase the per-project distinction that attribution depends on if the shared layer doesn't pass through which project initiated a given call. Confirm that whatever's shared — a common client wrapper, a shared caching layer, a common retry handler — still preserves project-level identification all the way through to wherever spend gets logged, rather than assuming shared code automatically keeps that information intact.

What to actually watch per project

Total spend alone under-informs the investigation; watching burn rate, cache-hit ratio, and average tokens per request per project separately catches problems earlier and more specifically than a single combined total does. A project whose average tokens per request has crept up gradually, or whose cache-hit ratio has quietly declined, is telling you something actionable well before the combined spend figure moves enough to be noticed on its own.

Setting per-project alerts rather than one combined threshold

A single combined spend alert only fires once the total crosses a threshold, by which point a runaway project may have already been overspending for a while, masked by other projects sitting comfortably under their own typical usage. Per-project thresholds, sized to what each project's usage actually looks like normally, catch an anomaly in any one project immediately rather than waiting for it to grow large enough to move the combined total noticeably — which, on a large enough combined base, can take a surprisingly long time.

Making attribution someone's actual responsibility

Attribution tooling that exists but that nobody's specifically responsible for reviewing tends to decay the same way any unowned monitoring does — it keeps recording data correctly while nobody looks at it until a bill prompts someone to go check retroactively. Assigning actual, named ownership of reviewing per-project spend on a regular cadence is what turns attribution from a technical capability into something that actually catches problems while they're still small.

Building the habit before it's urgent

Attribution is far easier to build in from the start of a project than to retrofit once several projects share infrastructure and history without it — treat per-project tagging as part of standing up a new integration, not as a project to prioritise only once spend has already become a concern. The usage tracker can hold separate logs per project if you feed it usage blocks tagged that way, giving you the burn-rate and cache-ratio view per project entirely in your own browser rather than depending on a shared billing dashboard that only shows the combined total.