LLM spend has a property that traditional infrastructure spend does not: it scales with user behavior, not with provisioning decisions. Nobody has to approve a bigger instance for your Claude bill to triple; a popular new feature, a retry loop gone wrong, or one team pasting whole documents into prompts will do it silently. The defense is boring and effective: attribute every token to an owner, set budgets, and alert on forecasts rather than on damage already done.
Attribution first: tag everything from day one
A budget you cannot attribute is a number you can only worry about. Before alerts, make sure every Claude request can be traced to a team, an application, and an environment. One advantage of running Claude through your cloud provider is that its native cost tooling applies: cost allocation tags on AWS, labels on Google Cloud, and tags with cost management views on Azure all work the same way for Claude consumption as for any other service in your estate. Separate accounts, projects, or subscriptions per environment (dev, staging, production) give you the coarsest and most reliable attribution boundary; tags and labels refine it.
Cloud-level attribution has a floor, though: it tells you which account or tagged resource spent the money, not which feature or customer did. For that finer grain, log the token usage returned in every Claude response alongside your own request metadata (feature name, tenant, environment) and aggregate it yourself. Teams that route all LLM traffic through an internal gateway get this attribution almost for free, because the gateway sees every request and can stamp it consistently.
Budgets and alerts that fire before the surprise
All three hyperscalers offer budget tools that alert when actual or forecasted spend crosses a threshold. Two configuration choices matter more than the rest. First, alert on the forecast, not only the actual: an alert that fires when the month's projected spend exceeds budget gives you weeks to react, whereas an actual-spend alert at 100% is a post-mortem invitation. Second, set multiple thresholds with different audiences: the owning team at an early threshold, engineering management at a middle one, finance at a high one. A single alert to a shared inbox trains everyone to ignore it.
Catching anomalies daily, not monthly
Monthly budgets catch drift; they are too slow for incidents. The failure modes that hurt (a retry storm doubling request volume, a prompt change that silently triples input tokens, an unbounded agent loop) show up in hours. A lightweight daily check covers this: compare yesterday's token consumption per feature against its trailing seven-day average and page the owning team when the ratio is unreasonable. Because you are comparing token counts rather than dollars, this check also works within introductory pricing periods and committed-use discounts, where dollar signals can mislead.
Watch the input-to-output ratio per feature as well. A stable feature has a characteristic shape; if input tokens per request jump while requests stay flat, someone changed a prompt or started attaching bigger documents. That is a conversation, not necessarily a problem, but you want it to happen the week it changes.
Who looks at this, and when
Tooling without cadence decays. A workable minimum: the owning engineering team reviews per-feature spend weekly as part of an existing ritual; engineering management reviews the cross-team picture monthly; and every alert has a named owner with a runbook, even if the runbook is three lines. When an anomaly alert fires, the first questions are always the same: did request volume change, did tokens per request change, or did the model mix change? Logging those three dimensions separately means the answer takes minutes.
Where to go next
For the organizational layer on top of this plumbing, read FinOps for LLMs: Making Claude Spend Accountable. For the request-level logging that powers fine-grained attribution, see Observability for Claude Apps, and check the launch checklist on the main guide.