AI Agent Cost Attribution: Chargeback and Showback for Multi-Tenant AI Spend

A platform team that resells or exposes AI agent functionality to multiple customers eventually asks a question its aggregate dashboard cannot answer: who is spending this money, and are we charging them enough to cover it? Total monthly LLM spend is a useful number for a finance review. It is close to useless for deciding whether Tenant A's usage-based plan is profitable, whether Tenant B is abusing a free tier, or whether a shared background feature is quietly subsidized by every other customer.

This article is about attribution, not reduction. It does not repeat how to measure cost per successful task — that article defines the unit-economics denominator this one assumes — and it does not re-explain the tactics in reducing LLM costs without hurting quality or the interactive cost calculator built for finding and cutting cost drivers. Attribution is a different job: taking the total your provider bills you and correctly assigning every dollar of it to the tenant, team, or feature that actually caused it, then reconciling that number against what you bill the customer back.

The boundary is deliberate. This article does not cover how to lower total spend, how to price a plan, or how to build a general FinOps practice for cloud infrastructure. It covers the mechanics of turning one pooled AI provider invoice into a set of tenant-level ledgers you can trust enough to bill from, alert on, and defend in a support ticket.

At a glance

This guide is for an engineer or platform lead building or operating a multi-tenant AI agent product — one where more than one customer, team, or workspace shares the same underlying model access. It helps you turn one invoice into per-tenant numbers you can chargeback, showback, or cap before those numbers become a billing dispute.

The Attribute → Aggregate → Reconcile → Enforce model

Use Attribute → Aggregate → Reconcile → Enforce as the operating sequence:

1. Attribute: tag every billable event with a tenant identity at the moment it happens, not after the fact.
2. Aggregate: roll tagged events into a per-tenant, per-period ledger at a granularity you can actually compute.
3. Reconcile: compare the metered ledger against what the tenant was actually billed, and surface the gap.
4. Enforce: apply budgets, soft warnings, and hard caps before an unprofitable tenant becomes next month's write-off.

Decision rule: Attribute at the span, aggregate at the tenant, reconcile against the invoice, enforce before the invoice is wrong. Skipping a stage does not remove the problem — it just moves it one stage downstream, where it is more expensive to fix.

The model is intentionally narrower than general cost management. It assumes you already know your total spend and want to know whose it is — not how to lower it.

Why aggregate spend hides the real problem

A single "total AI spend this month" number answers exactly one question well: did the bill go up. It cannot answer the three questions that actually matter to a platform team that sells agent access to others.

The three questions a pooled number can't answer

First, which tenant caused a spend change — a 20% month-over-month increase could be one enterprise customer running a legitimate new workflow, or it could be a single free-tier account stuck in a retry loop, and the two require completely different responses. Second, is each tenant's plan actually profitable — a flat-fee plan that looked fine at the pricing table can lose money the moment a customer's usage pattern shifts, and averaging across all tenants hides exactly which one flipped. Third, who is allowed to see whose spend — once you can compute a tenant's cost, that number becomes sensitive: a customer should see their own usage, not a competitor's, and internal support staff need enough visibility to help without exporting every customer's prompt history.

Tag cost at the span, not after the fact. Every technique in this article follows from that one constraint. If tenant identity is not present at the moment a model call or tool call happens, no amount of after-the-fact analysis can fully recover it — you can approximate, allocate, or guess, but you cannot attribute with confidence.

The Attribute → Aggregate → Reconcile → Enforce model in practice

A break in any stage propagates forward: a missing tag becomes a wrong ledger becomes an incorrect invoice.

Carry one workspace through every stage

The rest of this article carries one illustrative example forward: a platform with three paying tenants and one free tier, sharing a single provider account. Tenant A is on a Team plan — a $249/month flat fee that includes 4,000 successful agent runs, with overage billed at $0.05 per run above that. Tenant B is on the free tier. Tenant C is an Enterprise customer on a usage-based contract billed monthly against actual metered cost plus a fixed margin. Tenant D shares a background summarization feature with every other tenant on the platform. None of these figures are drawn from a real customer or a verified vendor price sheet — they are illustrative assumptions, clearly labeled where they appear, chosen to be internally consistent so the arithmetic in each stage is checkable.

Stage 1: Attribute cost at the span, not after the fact

Attribution means resolving a tenant identity for every unit of billable work at the moment that work happens, and recording it beside the cost — not reconstructing it later from logs, IP addresses, or best-effort joins against a separate billing table.

What a tagged cost event needs

A workable cost event needs, at minimum: which span or run it belongs to, which tenant it resolves to, which feature or workflow triggered it, what kind of billable unit it represents (a model call, a tool call, an embedding call, a retry), how many units were consumed, the per-unit price at the time of the call, and whether it is billable to the tenant at all — internal QA runs, shadow traffic, and retries you choose to absorb should be recorded but flagged as non-billable so they do not silently inflate a customer's ledger.

// Illustrative: a tenant-tagged cost event recorded once per billable operation.
type CostEvent = {
  spanId: string;
  runId: string;
  tenantId: string;          // required — every event must resolve to exactly one tenant
  feature: string;           // e.g. "summarize", "research-agent", "shared-digest"
  kind: "model_call" | "tool_call" | "retry" | "embedding";
  provider: string;
  unitCount: number;         // tokens, tool invocations, or embedding units
  unitCostUsd: number;       // resolved from the provider price table at call time
  costUsd: number;           // unitCount * unitCostUsd, computed once and stored
  billableToTenant: boolean; // false for internal QA, shadow traffic, absorbed retries
  recordedAt: string;
};

export function attributeCost(event: CostEvent): CostEvent {
  if (!event.tenantId) {
    throw new Error(
      `Cost event on span ${event.spanId} has no tenantId — reject it, do not default to "unknown"`,
    );
  }
  return event;
}

The function above is deliberately unforgiving. Reject cost you cannot attribute; do not default it to "unknown". An "unknown" bucket feels safer than an error in the moment, but it quietly grows into exactly the unattributed slice shown in the hero diagram above — spend nobody can bill, explain, or investigate. It is far cheaper to fix a missing tenant identity at the point where a span is created, when the request context still has it, than to try to infer it later from a timestamp and a rough correlation.

Field note: The most common place attribution breaks is a shared authentication or gateway layer that strips tenant context before forwarding a request to the model provider. If the component that calls the model cannot see which tenant asked for the call, no downstream analysis can recover that fact with confidence — fix the gateway before building the ledger.

Stage 2: Aggregate into a per-tenant ledger

Aggregation rolls individual tagged cost events into a per-tenant total at a chosen period — typically daily, with a monthly rollup for billing. Using Tenant A's Team plan as the worked example: assume an average successful agent run consumes roughly 3,200 input tokens and 900 output tokens against an illustrative $3-per-million-input / $15-per-million-output model price, plus an average of 1.4 tool calls per run at an illustrative $0.004 each, with 8% of runs requiring one retry that adds roughly 40% extra model cost on the retried subset.

Tenant A ran 5,600 successful agent runs this month. At roughly $0.0305 per run, Tenant A's metered internal cost is approximately $170.80. That figure is the aggregate output of Stage 2 — a real, tenant-scoped number, computed from tagged events, that did not exist in the pooled $14,208 invoice total until it was built.

Where shared costs enter the ledger

Not every cost event maps cleanly to one tenant. Tenant D's shared background summarization feature runs once and serves every tenant that subscribes to the digest, which means a single model call has to be split across several ledgers using an explicit allocation rule — proportional to document count, active seats, or an even split — rather than assigned wholesale to whichever tenant happened to trigger the run. The choice of rule matters and is covered in more depth in the trade-offs section below; the point for aggregation is narrower: a shared cost that is silently dropped from every ledger is worse than one that is imperfectly allocated, because a dropped cost is invisible to reconciliation while an imperfectly allocated one is at least visible and adjustable.

Stage 3: Reconcile metered cost against billed revenue

Reconciliation is the stage most teams skip, because it requires connecting two systems that are usually owned by different people: the metering pipeline that knows what a tenant actually cost, and the billing system that knows what a tenant was actually charged. Skipping it means you can answer "how much did we spend" and "how much did we invoice," but never the question that actually protects margin: did this tenant's plan cover what they cost us?

Chargeback moves money, showback moves behavior

The two most common reconciliation postures answer different questions and require different infrastructure.

Chargeback moves money; showback moves behavior. A platform does not have to choose one exclusively — Tenant A's flat Team plan is a showback candidate internally (the platform team watches whether Tenant A's usage threatens plan margin) while the overage above 4,000 runs is a chargeback line item on the actual invoice. Tenant C's Enterprise usage-based contract is chargeback by design: the metered ledger is the bill.

Reconciling Tenant A for the month: metered cost was approximately $170.80. Billed revenue was the $249 flat fee plus overage — 5,600 runs used against 4,000 included, so 1,600 runs at $0.05 each, or $80 — for total billed revenue of $329. Gross margin on Tenant A this month: $329 − $170.80 = $158.20, roughly 48%. That is the number a monthly-average dashboard would never surface, because it lives at the tenant grain, not the platform grain.

-- Illustrative: monthly per-tenant reconciliation, not a specific vendor's schema.
SELECT
  tenant_id,
  plan_tier,
  SUM(cost_usd) FILTER (WHERE billable_to_tenant) AS metered_cost_usd,
  billed_revenue_usd,
  billed_revenue_usd - SUM(cost_usd) FILTER (WHERE billable_to_tenant) AS gross_margin_usd
FROM cost_events
JOIN tenant_billing USING (tenant_id, billing_month)
WHERE billing_month = '2026-08'
GROUP BY tenant_id, plan_tier, billed_revenue_usd
ORDER BY gross_margin_usd ASC;

Ordering by ascending margin puts the tenants most likely to be losing money at the top of the result — exactly the review order a finance or platform owner needs. Reconcile against the invoice, not the dashboard: a metering pipeline that has never been checked against an actual provider bill can drift for months without anyone noticing, because the dashboard it feeds looks internally consistent even when it is wrong.

Stage 4: Enforce budgets before the invoice is wrong

Enforcement is where attribution earns its keep operationally. A tenant-level ledger that only informs a monthly report is showback with extra steps; enforcement means using that ledger to change what happens in production before the period closes.

Free-tier abuse is where attribution breaks first

Tenant B, on the free tier, has no revenue line to reconcile against — every dollar of metered cost is pure downside until enforcement stops it. Free tiers are also where the most adversarial usage concentrates: automated scripts probing for capability, a single account looping a failing tool call, or a workflow accidentally configured to retry indefinitely. The free tier is where attribution first breaks, because it is the plan with the least financial pressure keeping usage in check and often the least monitoring, since nobody is watching a $0 invoice line the way they watch an Enterprise contract.

A workable enforcement policy defines a soft cap — a threshold that triggers a notification and a review, without interrupting the tenant — and a hard cap — a threshold that blocks further billable usage until a human or an automated policy lifts it. For Tenant B, an illustrative policy might set a soft cap at 500 free-tier runs per month (roughly the level a legitimate evaluation user would reach) and a hard cap at 750, past which further requests are rejected with a clear message rather than silently continuing to accumulate cost.

Decision rule: Set the soft cap where a legitimate power user would still be comfortable, and the hard cap where continuing to serve requests stops being a product decision and starts being a subsidy. If you cannot articulate why the hard cap sits where it does, it is arbitrary, and an arbitrary cap either blocks real users or fails to block abuse.

A budget cap that only alerts is not a budget cap. This does not mean every cap should be a hard block — a paying Enterprise tenant crossing their contracted usage is a sales conversation, not an outage — but the enforcement mechanism has to be capable of blocking when the policy calls for it, or the "cap" is decoration.

Choose metering granularity without drowning in overhead

Every stage above assumes you can record a cost event per span. That is the most precise granularity available and also the most expensive to compute, store, and query at scale. The right granularity depends on what decision the ledger needs to support.

Granularity you cannot afford to compute is not a real option. Span-level attribution sounds strictly better than run-level, but if the pipeline that computes it cannot keep up with production volume, it degrades into a backlog that nobody trusts — at which point a slower, cheaper run-level ledger that is actually current is more useful than a precise one that is three days behind. A practical default is run-level aggregation for every tenant, with span-level detail retained for a shorter window specifically to support dispute resolution and enforcement decisions, rather than trying to keep full span-level history forever for every tenant.

Real-time alerts vs. batch reconciliation

A related granularity choice is temporal: how often does the ledger actually get computed and compared against billing.

The practical answer is usually layered rather than singular: real-time or near-real-time checks for hard-cap enforcement on the highest-risk plans (typically free tier and any plan without a credit card on file), hourly or daily aggregation for the ledgers that feed dashboards and showback, and monthly reconciliation as the authoritative pass that gets compared against the actual provider invoice and the actual billing system output. Monthly-only reconciliation is not wrong for a low-risk, low-volume product — it is wrong as the only layer once free-tier abuse or usage-based overage becomes a real financial exposure.

Protect the tenant boundary

A working attribution system creates a new category of sensitive data: per-tenant cost detail. That detail needs the same access discipline as any other tenant-scoped data, and it is easy to overlook because cost data does not feel as sensitive as prompt content or customer records.

Who can see whose spend

A tenant should be able to see their own usage and cost, at whatever granularity your product exposes — this is often the showback surface customers actually value most, more than an internal-only report they never see. A tenant should never be able to query another tenant's cost, even indirectly through a shared aggregate that could be reverse-engineered by comparing totals before and after their own usage changes. Internal roles need graduated access: support staff may need enough visibility to explain a bill without seeing prompt content, while finance needs full ledger access without needing trace-level detail, and only a narrow set of roles should be able to see cost data joined with actual prompt or output content, since that combination is far more sensitive than either alone.

Security note: Treat tenantId as a row-level scoping key on every cost query, the same way you would scope any other tenant-owned data — never as an optional filter a client can omit to see everything. The AI agent security checklist covers this same boundary discipline for tool access and data handling; cost data deserves the identical default-deny posture, not a lighter one because it "is just numbers."

Isolation is a promise about who can query whose spend, not just about who can see a UI element. An API endpoint that returns cost data without checking the caller's tenant scope is a data leak, even if no dashboard currently exposes it — the query capability itself is the risk.

Trade-offs, pooled resources, and where this breaks down

Attribution is not free, and it does not solve every version of this problem equally well.

Tenant B's free-tier usage and Tenant D's pooled shared-feature cost are the two negative-margin cases a platform-wide average would have hidden.

Allocating a shared or pooled resource

The hardest case in this whole model is a resource genuinely shared across tenants: a nightly digest job, a shared vector index refresh, a platform-level anomaly detector running over everyone's traces. There is no allocation rule that is objectively correct — proportional-to-usage rewards tenants who use the shared feature more, even-split rewards tenants who use it less, and cost-of-service (charging based on data volume or seat count rather than call count) can better match the underlying driver but requires more instrumentation to compute. Pooled resources need an allocation rule, not a shrug: pick one, document why, and revisit it when the shared feature's usage pattern changes enough that the original rule stops making sense. Tenant D's negative margin in the diagram above is a legitimate finding under an even-split rule — it means Tenant D uses the shared feature less than its even share of the cost, which is exactly the kind of signal that should prompt a rule change, not a shrug.

Three further limits are worth naming plainly. First, attribution cannot fix a pricing problem — if Tenant A's plan is priced below the cost of serving a typical customer on that plan, an accurate ledger will show that clearly, but the fix is a pricing or packaging decision, not a metering one. Second, retroactive attribution is approximate at best — once a cost event has been recorded without a tenant tag, any later attempt to assign it is an estimate, useful for a rough monthly report but not defensible in a billing dispute. Third, attribution overhead is a real cost — a metering pipeline that adds meaningful latency to every model call, or that becomes expensive enough to store that it rivals the AI spend it is tracking, has crossed from "operational necessity" into "its own cost problem," and the granularity table above exists specifically to help avoid that outcome.

Make the call: a practical checklist

Before treating a tenant-level cost ledger as authoritative enough to bill from, alert on, or defend in a support conversation, confirm the following:

• [ ] Every billable cost event carries a required tenantId resolved at write time, with no silent "unknown" fallback.
• [ ] The aggregation granularity (span, run, or daily rollup) matches what the highest-stakes decision on top of it actually needs.
• [ ] At least one full monthly reconciliation has been run against the real provider invoice, and the gap is understood, not just tolerated.
• [ ] Every shared or pooled cost has an explicit, documented allocation rule — not a silent drop and not an arbitrary assignment to whichever tenant happened to trigger it.
• [ ] Free-tier and any no-payment-method plans have both a soft cap that alerts and a hard cap that actually blocks further billable usage.
• [ ] Tenant-scoped cost queries are access-controlled the same way any other tenant-owned data is, with no endpoint that can return cross-tenant totals to a non-privileged caller.

Reversible caps beat heroic dashboards: a soft-cap-then-hard-cap policy that a platform owner can adjust in minutes will do more to protect margin than a beautifully designed dashboard that requires someone to notice a problem, understand it, and manually intervene before damage accumulates. Start with the smallest version of Attribute → Aggregate → Reconcile → Enforce that covers your highest-risk tenant class — usually the free tier, or whichever plan has the least financial friction — and extend it to the rest of the tenant base once that smallest version has survived one real reconciliation cycle.

Frequently asked questions