FinOps for Tokens: Attributing AI Spend to the Feature That Caused It

Your cloud bill can tell you, down to the tag, that a forgotten S3 bucket cost $14,000 last month. Ask the same question of your LLM bill — which feature burned $40,000 in tokens — and the honest answer at most companies is a shrug. The provider invoice has one line per model per API key, three teams share the key, and the "AI costs" row in the finance spreadsheet is allocated by headcount, vibes, or whoever complained least in the last planning cycle.

This is not a small bookkeeping annoyance. When nobody can name the feature behind a dollar of token spend, two failure modes follow. Cheap features get throttled because they share a budget line with an expensive one. And genuinely wasteful features survive forever, because their cost is invisible — smeared across a shared key, a shared cache, and a shared agent loop that serves six different product surfaces.

The FinOps Foundation's 2026 survey found that 98% of organizations now actively manage AI spend, up from 63% a year earlier and 31% the year before — the fastest adoption curve the foundation has ever recorded. Everyone is suddenly doing "FinOps for AI." Far fewer have noticed that the core primitive of cloud FinOps — the resource tag — doesn't exist in the token world, and that three specific mechanics of modern LLM usage actively destroy attribution.

Why the cloud FinOps playbook breaks on tokens

Cloud cost allocation works because spend attaches to resources, and resources are durable, nameable things. An EC2 instance exists for months; you tag it once and every hour it runs inherits the tag. The billing export arrives with the tag column already populated.

Token spend attaches to calls. A call lives for four seconds, belongs to no resource, and appears on the invoice only as an aggregate: this API key, this model, this many input and output tokens, this many dollars. If you didn't record which feature made the call at the moment it happened, that information is gone. There is no retroactive tagging, no "describe-instances" you can run next week to reconstruct who did what.

That inversion changes the engineering problem. Cloud FinOps is mostly a reporting problem — the data exists, you have to organize it. Token FinOps is a telemetry problem — the data doesn't exist unless your code emits it, per request, forever. Which means the attribution system lives in your request path, is maintained by product engineers rather than a central FinOps team, and decays every time someone ships a new call site without the tags.

And even perfect per-call tagging only gets you halfway, because three common cost-efficiency mechanisms take spend that used to be per-call and make it collective.

The three attribution killers

Shared prompt caches. Prompt caching is the single biggest lever on inference cost — cached input tokens are billed at roughly 10% of the base rate on Anthropic and at half rate or better on OpenAI. But the accounting is genuinely weird. On Anthropic, cache writes cost a premium — 1.25× the standard input rate for a five-minute TTL — while subsequent reads cost 0.1×. So the first feature to touch a shared system prompt pays a surcharge to build a cache that every other feature then reads at a 90% discount. The first caller subsidizes everyone else.

If your dashboard naively attributes cost-per-call, the feature that happens to run first after each cache expiry looks 10× more expensive than an identical feature that runs second. None of that difference is real; all of it is cache-turn order.

Batched calls. Batch APIs offer around 50% off in exchange for asynchronous processing, so cost-conscious teams aggregate requests — often across features, sometimes across tenants — into a single submission under a single key. The invoice sees one batch. Your six features saw six different workloads. Unless the batching layer records how many tokens each feature contributed to each batch, the discount and the cost both get smeared across whoever shares the pipeline, and the feature that contributed 80% of the tokens shows up as an equal partner with the one that contributed 2%.

Multi-tenant agents. Agentic workloads are where attribution goes from hard to hostile. A recent Microsoft Research study of agentic coding tasks found that runs on the same task can differ by up to 30× in total tokens, that agentic tasks consume on the order of 1,000× more tokens than ordinary chat or code-reasoning calls, and that input tokens — not output — dominate the bill, outnumbering output tokens by 20–25×. Worse for anyone hoping to budget: frontier models cannot predict their own token usage (correlation around 0.39), and human expert estimates of task difficulty barely correlate with actual spend either.

Now put one agent loop behind six product features. The loop accumulates context across tool calls, so the marginal cost of the feature that asked the fifth question includes the conversational baggage of the first four. A retry storm triggered by one feature's flaky tool inflates the input-token bill of everything that shares the loop. Per-call attribution is technically accurate and economically meaningless.

The metering discipline: tag at the call site, count from the response

The fix is unglamorous and has three layers, and skipping any of them is how dashboards end up confidently wrong.

First, propagate identity into every call. Every LLM request needs to carry, at minimum: feature, tenant or customer, environment, and team or cost center. The FinOps Foundation's practitioner guidance is that five dimensions — team, project, environment, model, and cost center — cover 95% of chargeback use cases. The mechanics matter less than the enforcement: an LLM gateway (LiteLLM, Helicone, Portkey, or your own proxy) that issues a virtual key per feature is the most robust pattern, because a tag attached to the key flows onto every request the key makes. Nobody has to remember to pass metadata, and a request with no valid key simply doesn't go through.

Tagging that depends on every engineer remembering a parameter will hit 60% coverage and stall. Tagging enforced at the gateway hits 100% on day one.

Second, count tokens from the API response, never from estimates. The response's usage block — and its OpenTelemetry GenAI semantic-convention equivalents, gen_ai.usage.input_tokens and gen_ai.usage.output_tokens — is the authoritative meter. Client-side tokenizer estimates drift across model versions and miss system-prompt overhead; response-based counting lands within 1–3% of the actual invoice. Record input and output separately (they price differently, often by 4–5×), and record cache-read, cache-write, and batch-discounted tokens as their own categories rather than folding them into "input." Store the counts and the tags; do not warehouse raw prompts and completions alongside them — you'll turn your billing pipeline into a sensitive-data liability for no attribution benefit.

Third, meter at the span level, not the request level. For agents, the unit that maps to a feature isn't the API call — it's the traced task: this agent run, on behalf of this feature, made eleven model calls and four tool calls, costing $0.87 total. OpenTelemetry's GenAI conventions exist precisely so each model call becomes a span with token attributes, and the trace ties spans to the originating request. Without span-level metering you can say what the agent fleet cost; with it you can say what this task for this feature cost — which is the number every downstream decision needs.

Allocation is a policy decision, not a measurement problem

Here's the part engineering teams consistently get wrong: once the metering is honest, the remaining disputes are not technical. Who absorbs the cache-write premium? How do you split a batch discount? What do you do with the shared context an agent accumulates? There is no measurement that answers these — they're accounting policy, and the goal is simple and consistent, not perfectly fair.

Workable defaults, in rough order of how often they're the right call:

• Cache writes: socialize them. Fold write premiums into a small overhead rate on all cached-read traffic, so the feature that happens to repopulate the cache after each expiry isn't punished for its timing. Attributing writes to the first caller is precise and perverse.
• Batch discounts: pro-rate by token contribution. Each feature in a batch pays its token share of the discounted total. This requires the batching layer to keep per-item provenance — build that in on day one, because retrofitting it means replaying history you didn't record.
• Shared agent context: charge the task, amortize the setup. System prompts, tool schemas, and retrieved context that exist regardless of which feature asked get treated like the cache-write overhead; tokens the feature's own question generated get charged directly.
• Provisioned throughput: if you've bought dedicated capacity shared across use cases, the FinOps Foundation's formula — effective rate scaled by (2 − utilization) times tokens consumed — spreads the fixed cost so that low utilization visibly inflates everyone's unit price, which is exactly the signal you want purchasing decisions to see.

Write these rules down before the first chargeback conversation, not during it. The moment real budgets move, every team becomes a motivated auditor of your allocation methodology, and "we decided this in advance and apply it uniformly" is the only defensible position.

Showback first, then chargeback — and watch unit cost, not total spend

Resist the urge to bill teams immediately. The standard sequencing works: run showback — reports that say what each feature would have been charged, with no money moving — for four to six weeks. Showback flushes out the tagging gaps, the untagged legacy call sites, and the allocation edge cases while the stakes are low. Once tag coverage is reliably above ~80% and the numbers stop surprising people, graduate to chargeback, where the costs actually land in team budgets.

Then change what you alert on. Total AI spend is a terrible signal — it goes up when the product succeeds, and a 40% month-over-month increase might be great news. The number that catches real problems is unit cost per feature: cost per task, per conversation, per document processed. A retrieval change that doubles context length, a prompt edit that breaks cache-prefix alignment, an agent that starts retrying a broken tool — none of these move total spend enough to page anyone on day one, but all of them show up immediately as cost-per-task drift on the feature that caused them.

Finally, budget for the variance you now know exists. Given 30× run-to-run spread on agentic tasks and models that can't forecast their own consumption, deterministic budgets are fiction. Practitioner guidance for 2026 agentic workloads is to carry a 20–40% reserve above modeled spend and report burn against it explicitly — treating tokens like a utility with weather, not like a SaaS seat count.

The feature that can name its cost gets to ship

Token FinOps is usually pitched as cost control, which makes it sound like the department of no. In practice the causality runs the other way. Teams that can attribute spend to features are the teams that can defend spend: they can show that the expensive agent feature drives retention worth 12× its token bill, kill the one that doesn't, and reinvest the difference. Teams that can't attribute anything end up with blanket cost-cutting mandates that throttle the winners along with the waste.

The playbook is mundane: enforce identity at a gateway, count tokens from responses at span level, publish allocation rules for caches and batches before money moves, run showback until the tags are trustworthy, and alert on unit cost drift. None of it is research. All of it has to be in place before the quarter when your AI bill becomes the line item the CFO asks about — because by then, the calls you needed to tag have already happened, and that data is gone.