Cost Attribution for LLM Features: Tracking Spend by Team, Feature, and User Without Guesswork

Most teams find out an LLM feature is expensive the same way: a monthly bill arrives that's three times what anyone expected, and nobody can say which feature, team, or customer caused it. Unlike a decade of cloud billing tooling that lets you tag a VM or a bucket by owner, LLM spend usually flows through a single API key and a single invoice line — so the first real cost question ("which feature is expensive, and is it worth it?") often can't be answered without weeks of log archaeology.

The fix isn't a smarter dashboard after the fact. It's tagging spend at the point the call is made, the same way teams learned to tag cloud resources for chargeback.

Tag the request, not just the model

Every outbound LLM call should carry metadata that survives all the way to a record you control: which feature initiated it, which internal team owns that feature, and — where privacy rules allow — a hashed identifier for the account. Most providers expose a metadata or user field for exactly this; if that field doesn't feed into billing exports, wrap your own client so every call logs {feature, team, requestId, tokensIn, tokensOut, model} as a first-class event, independent of the invoice. Reconciling that log against the provider's bill monthly catches drift — unaccounted retries, background jobs, an accidentally verbose system prompt — far faster than staring at one number that only moves in one direction.

Retries deserve their own line item. A flaky downstream call that silently retries three times bills three times, and if that cost isn't attributed to the caller and the retry policy, it looks like organic growth instead of a bug. Attribute a retried call to the same requestId as the original, and trend "retry cost" as its own metric — it should be close to zero, and when it isn't, that's a directly actionable signal instead of noise buried in a monthly total.

Separate cost per call from cost per outcome

A feature that costs twice as much per call but resolves in one round trip instead of three is cheaper in practice — but per-call tracking alone will flag it as the pricier option. Once requests are tagged by feature, compute cost per successfully completed task, not cost per token or per call: token counts reward small, cheap-looking calls even when a workflow needs five of them to finish what a longer single call would do in one. It's the same reasoning that eventually pushes teams away from "requests per second" as a health metric and toward "successful transactions" — the unit of cost should match the unit of value delivered.

None of this requires new infrastructure most teams don't already have. It requires deciding, before the next invoice lands, that every call should be able to answer "who asked for this and why," and building that into the client wrapper everyone already uses to talk to the model — rather than trying to reconstruct the answer from raw logs after someone asks why the bill doubled.