AI Unit Economics: How to Actually Attribute LLM Cost to a Customer or Feature

A provider invoice tells you the total spend for the month. It does not tell you whether that spend came from one enterprise customer running a heavy workflow or from ten thousand free-tier users hitting a feature that should be rate-limited. Without attribution, "AI costs are up" is a fact with no next action attached to it.

The question finance actually asks

Not "what did we spend on OpenAI" but "what does it cost us, per customer, to run feature X" — because that number determines pricing, gross margin, and which features are subsidizing which customers. Answering it requires cost data at the transaction level, joined to customer and feature identifiers, not just a monthly total.

Why provider dashboards don't answer it

Provider billing dashboards are organized by API key and model, not by your product's concept of a customer or a feature. Unless every distinct customer or feature has its own API key (which does not scale), the provider's view of spend has no way to map back to your business logic.

Attribution has to happen at the call, not after

The only reliable pattern is to tag cost at the moment of the LLM call — wrap every request with the customer ID, feature name, and model, and log token counts and cost alongside that context immediately. Trying to reconstruct this after the fact from logs or invoices is lossy and usually wrong.

def call_llm(prompt, *, customer_id, feature, model):
    response = client.messages.create(model=model, messages=prompt)
    log_cost_event(
        customer_id=customer_id,
        feature=feature,
        model=model,
        input_tokens=response.usage.input_tokens,
        output_tokens=response.usage.output_tokens,
        cost=compute_cost(response.usage, model),
    )
    return response

Treat it like accounting, because it is accounting

Cost events at the scale of a real product are financial records, and they benefit from being modeled like one — a structured ledger with accounts (by customer, by feature, by provider), not a wide analytics table that gets reshaped every time someone asks a new question. A proper chart-of-accounts structure makes "cost by customer this month" and "cost by feature this quarter" the same kind of query, not two different ad-hoc scripts.

Multi-provider normalization is not optional

Almost every team ends up using more than one model provider within a year — a cheaper model for high-volume classification, a stronger one for the task that needs it, maybe a second provider for redundancy. Cost attribution that only works for one provider's pricing structure has to be rebuilt the day a second provider shows up. Normalize cost calculation behind a single interface from day one.

The takeaway

AI unit economics is a data modeling problem before it's a dashboard problem. Tag cost at the call, structure it like a ledger, and normalize across providers early — the alternative is finding out your margin on a feature only after a customer complains about the bill.

Christian Chukwuka

Founder & AI Systems Engineer