How to Attribute LLM Costs to Individual Customers for Usage-Based Billing

Why the provider reports cannot do this alone

Anthropic's Usage and Cost documentation says the Cost API can group by workspace or description, and that its time buckets are daily only. The Usage API can filter by API key, workspace, model, service tier, and a few other dimensions, but a customer is not one of them. The same page notes that usage from the default workspace has a null workspace ID, and that Console playground usage has a null API key ID.

OpenAI's Costs reference lists group_by fields of project_id, user_id, line_item, api_key_id, and api_source. It also says support for combining user_id with project_id grouping depends on the organization and the requested time range. These fields identify who in your organization made the call, which is useful for internal chargeback and not the same thing as your own end customer.

You can force a mapping by giving each customer a workspace, project, or key. That works for a handful of enterprise accounts. Anthropic's own documentation points out that breaking costs down across many API keys carries performance limits, so it does not scale to thousands of tenants.

Build the ledger at the call site

The reliable pattern is one row per request, written by your application or your gateway: timestamp, customer ID, feature, model, and the token counts from the response usage object. Add the cached and uncached input split if you use prompt caching, because the two are priced differently.

A gateway can do part of this for you. LiteLLM's proxy documentation describes a customers feature that tracks spend against the user value passed to /chat/completions, without creating a key for every user. It also supports a budget object for customers, and it states that customer budgets are global per deployment, with spend tracked against the customer ID alone. If you do not run a gateway, write the row in your own middleware.

• Pass a stable customer ID on every call, never an email address that can change.
• Store raw token counts, not only dollars, so you can reprice when rates change.
• Tag background work (evals, retries, summarization jobs) with a feature field so internal spend does not land on a customer.

Worked example: cost per request and a usage price

The rates below are hypothetical, chosen to show the arithmetic. Say a request averages 3,000 input tokens and 500 output tokens, at $3.00 per million input and $15.00 per million output.

• Input: 3,000 x $3.00 / 1,000,000 = $0.0090.
• Output: 500 x $15.00 / 1,000,000 = $0.0075.
• Cost per request: $0.0165, or $16.50 per 1,000 requests.
• A customer making 4,000 requests a month costs $66.00. On a flat $49 plan that is a $17.00 loss before any other cost.
• To hold a 40% gross margin on LLM cost, price at $16.50 / (1 - 0.40) = $27.50 per 1,000 requests, so that same customer is billed $110.00.

Reconcile the ledger to the provider total

Your ledger is an estimate until it matches the invoice. Each day, sum the ledger and compare it with the provider cost report for the same day. Anthropic states that Priority Tier costs are not available in the cost endpoint, and both daily cost reports only cover usage the endpoint can see, so expect a gap and measure it rather than assume zero.

Say the ledger totals $1,000.00 for a day and the provider reports $1,030.00. The $30.00 gap is 3%. Either carry it as unallocated overhead, or spread it across customers in proportion to their share of ledger spend. Pick one rule, document it, and keep it fixed so invoices stay explainable. A gap that grows week over week usually means a call path is missing the logging middleware.