How to Attribute Token Spend to Features and Teams

There are three capture points and they are not mutually exclusive.

SDK wrapper (start here). One function wraps your model client, injects the tags from the calling context and writes the row. It is the smallest change and the most portable: the tagging happens at the call site, where the feature label is still known, rather than in raw logs where the call appears as an opaque provider request with only model and token count (Braintrust). The downside is discipline: any code path that bypasses the wrapper is invisible.

API gateway or proxy. Every request passes through one control point, so tagging and budget controls apply across all providers and all services without reimplementing logic per application (Maxim AI). Gateways built on the OpenAI-compatible pattern accept per-request metadata objects and project a curated subset to metric labels, keeping high-cardinality fields on the trace only (TrueFoundry). The cost is that the application must still send the feature label; the gateway cannot invent it.

Provider usage APIs. Provider-side usage and cost endpoints aggregate by API key or project and support grouping by model, project and API key (OpenAI cookbook). Use these for reconciliation, not attribution. They are the source of truth for what you were charged; your cost table is the source of truth for why.

A sensible split: gateway for enforcement and cross-provider normalization, SDK wrapper for business tags, provider API for a nightly reconciliation job that compares your computed total against the invoice and flags drift above a tolerance you set (a few percent is a common starting point).

Do not parse text logs after the fact. Write a structured row per call to a table designed for aggregation. The pipeline pattern that works at startup-to-mid scale is streaming pre-aggregation: traces to minute counters to hourly rollups to daily rows keyed by team, app and model, with ClickHouse or TimescaleDB comfortably handling it on a single VM (TrueFoundry).

A minimal schema in SQL:

CREATE TABLE llm_calls (
  ts            TIMESTAMP NOT NULL,
  request_id    TEXT,
  feature_id    TEXT NOT NULL,
  team          TEXT NOT NULL,
  customer_id   TEXT,
  environment   TEXT NOT NULL,
  model         TEXT NOT NULL,
  prompt_version TEXT,
  input_tokens  INT NOT NULL,
  output_tokens INT NOT NULL,
  cached_tokens INT DEFAULT 0,
  latency_ms    INT,
  success       BOOLEAN NOT NULL,
  cost_usd      NUMERIC(12,6) NOT NULL
);

Cost is computed at span close from usage attributes and a versioned pricing table, because cache reads, cache writes and image or audio inputs each carry a separate price line (TrueFoundry). Store cost_usd rather than computing it in every query: pricing changes, and you want historical rows to keep the price that applied when they were written. Keep the pricing table itself in version control with an effective date, so a re-run is reproducible.

The formula per call is simple:

cost = input_tokens   * input_rate
     + output_tokens  * output_rate
     + cached_tokens  * input_rate * cache_multiplier

where cache_multiplier reflects the provider's cache read discount, which is substantial: Anthropic bills cache reads at 0.1x the input rate and OpenAI at roughly 0.5x on cached input (Morph, Worklytics). If you ignore the cached and uncached split you will systematically overstate spend on cache-heavy workloads and understate the value of adding caching.

Build these in this order. Each answers a different question and each has a specific way of misleading you.

Cost by feature per day. Sort descending, show the top 10 and roll the rest into "other." The insight is rarely the number; it is the slope. A feature whose cost grows 20 percent week over week while its request count is flat is getting more expensive per request, which points at context growth, a prompt change, or a model swap.

Cost per successful request. This is the metric to optimize, because an agent that solves a problem in one expensive call can be cheaper than one that grinds through ten cheap ones (BigData Boutique). Track it per feature, per prompt version, and per model. A fall in unit cost after a routing change is the evidence you need to keep the change.

Cost by team for chargeback. Monthly grain, tied to agreed budgets. Split shared platform spend (evaluation runs, shared retrieval, gateway overhead) explicitly and in writing, or it defaults to whoever has the most traffic.

A worked example makes the unit economics concrete. Suppose a support classification feature handles 1,000,000 requests a month, averaging 800 input tokens and 120 output tokens per call on a mid-tier model priced at $1.00 per million input and $5.00 per million output, figures read from the pricing table in Worklytics. Input is 800,000,000 tokens, or $800. Output is 120,000,000 tokens, or $600. Total $1,400 a month, or $0.0014 per request. If a prompt change pushes input to 1,200 tokens, input cost becomes $1,200 and the feature costs $1,800: a 29 percent rise with zero change in request volume. Without per-request tagging that $400 would surface only as a slightly larger invoice line.

Attribution dashboards fail in predictable ways. These are the guardrails that keep the analysis honest.

Count retries as their own line. Transient provider errors trigger SDK retries with exponential backoff; the application logs the successful response, so retry tokens may never surface in application logs (Braintrust). Token spend hides in four places: retries, long context, verbose output and over-large models. Track each as its own line item so a retry storm during an upstream incident appears as a distinguishable spike rather than a gradual trend (BigData Boutique).

Separate input from output. Output tokens cost more on most models, so a prompt that triggers a 3,000-token response is a different problem from one that produces 50 tokens (NeuralTrust). A blended "cost per call" hides the difference between a verbosity problem and a context problem.

Watch compounding, not just totals. Every unnecessary token in an agent conversation is paid for on every subsequent turn: 100 wasted tokens in turn one of a 30-turn session costs 3,000 tokens overall, which at $5 per million input tokens is $0.015 of waste per session, or $450 a month across 1,000 sessions a day (Morph). Feature-level totals will show this as steady growth; unit cost per request is where you catch it.

Reconcile against the invoice monthly. Your computed total should land within a few percent of the provider bill. Larger gaps mean untagged calls (a script using a raw key, an evaluation job, a notebook someone left running) and those gaps are themselves findings.

Do not attribute shared infrastructure to the loudest feature. Caching, routing and evaluation runs are shared costs. The gateway's own budget and usage controls belong at the platform layer, not folded into a product feature's unit cost, because doing so makes every optimization decision look better or worse than it is (Maxim AI).

Treat attribution as continuous, not a one-off audit. Inference prices fall while consumption rises, so the cost curve bends upward unless something actively controls it; the same cost-accountability loop FinOps applies to cloud applies to tokens (Maxim AI). A monthly review of the three dashboards is the cheapest control you have.

Once the table exists, the optimization levers become measurable rather than theoretical: model routing, semantic caching, output limits, batching at the provider's discounted asynchronous rate, and context compaction each move a specific line on a specific dashboard (Morph, NeuralTrust). Attribution first, then cuts, then verification on the same unit-cost chart. If you are running several providers and would rather spend the engineering time on features than on per-provider instrumentation, Quanta Inference exposes text, image, video, audio and embedding models through one OpenAI-compatible key with prepaid USD pricing, which simplifies the pricing table your cost job has to maintain.

1. Day 1: define the schema and a pricing table. Pick the fields, name the owner of each tag, and load per-model input, output and cache rates into a small table with effective dates.
2. Day 2: wrap the client. One function that takes a context object (feature, team, customer, environment, prompt version), calls the model, and writes the row. Fail open: a logging error must never break a user request.
3. Day 3: backfill from provider usage APIs for the current billing period so the first dashboard is not empty, grouping by model and project to reconstruct what you can (OpenAI cookbook).
4. Day 4: build the feature-by-day chart and the unit cost chart. Keep both to lines and tables; resist the pie chart.
5. Day 5: reconcile. Compare your total to the invoice, list and name every gap, and tag the scripts and jobs that caused them.
6. Week 2: add the chargeback view and soft budget alerts per team at a threshold the team agrees to, then a hard cap only after a soft alert has fired at least once without a false positive.

The order matters. Chargeback before reconciliation produces arguments about numbers nobody trusts; unit cost before feature totals produces optimization of the wrong thing.