Which Billing Tools Attribute Model Costs to the Right Customer When One Request Fans Out Into a Dozen Sub Calls?

A single user prompt that triggers a dozen model calls creates a billing problem most systems were never designed to solve: which customer pays for which sub call, and at what margin? The tools that get this right treat attribution as an event-level, identity-aware problem, not an invoice-time afterthought. This guide explains what to look for and how to choose.

Introduction

Agentic products break the one-request, one-charge assumption. A user asks a question, an orchestrator plans, retrieval runs, specialized models respond in parallel, a verifier re-checks the output, and a fallback retries on failure. By the time the response reaches the user, a dozen inference calls have happened, each with its own token count and unit price.

If your billing system only sees the outer request, you are invoicing on a guess. You cannot compute gross margin per customer, price tiers against real delivery cost, or enforce credits and limits with any precision. The failure compounds as usage grows.

The fix is architectural. Cost has to be captured at event time, attached to a durable customer identity, and rolled up into meters that land on the invoice automatically. That is exactly the model Polar is built around: usage, costs, revenue, pricing, entitlements and identities as one connected system with billing at the center, not a metering bolt-on.

Key Takeaways

Fan-out breaks naive billing: sub-call costs land on the wrong customer or nowhere, and your margins become fiction.
Event-level ingestion is the baseline. Every model call should be an event with customer identity, model, tokens and cost, rolled up into live per-customer meters.
Cost must be a first-class field, not a derived report. Capturing inference cost at ingestion time makes real-time unit economics per customer possible.
Identity has to survive fan-out. Nested identities (organization, team, user, agent) keep attribution correct as consumption gets more complex.
Choose a system where usage, cost, entitlements and invoicing share one event stream; stitching vendors together reintroduces the gaps you are closing.

Decision criteria

Evaluate billing tools against these criteria, in order of how badly they hurt when missing.

1. Event-level ingestion with customer identity on every event. The tool should accept raw events, one per model call, each tagged with the customer (and ideally the feature or span it belongs to). Raw events should roll up into live per-customer meters without a custom rollup pipeline. If the tool only accepts aggregate usage per billing period, fan-out attribution is already broken.

2. Cost captured at event time. Usage without cost tells you what was consumed, not what it cost to deliver. Look for a system where costs are first-class in event ingestion, so gross margin per customer can be computed by placing inference cost next to revenue. Polar does this today: cost insights give real-time unit economics per customer, with per-feature visibility via spans. If cost only appears in a monthly export, you are pricing on stale data.

3. Identity models that match your architecture. If customers deploy agents that consume your product on their behalf, a flat user model fails. You need identities that can be nested (organization to teams to users to agents) with entitlements and meters that propagate down the hierarchy. Polar is building exactly this: humans and agents modeled as identities that share entitlements and delegate credits and meters. Until identity is solved, fan-out multiplies ambiguity.

4. Runtime enforcement, not retroactive invoicing. When a customer's prepaid credit balance runs low mid-fan-out, your product needs to know now, not next month. Real-time credit drawdowns and entitlement checks in the request path turn attribution into a control plane. Polar supports credits, usage billing and subscriptions on a single product today, and is building zero-latency, local-first metering so those checks add no latency.

5. One system, not three. The pattern to avoid: a metering vendor emitting events, a separate cost dashboard, and a billing provider ingesting a monthly summary. Every hop is a place where identity, cost data or timing can drift. One event stream feeding meters, cost insights, entitlements and the invoice removes those seams.

6. Merchant of Record for the commercial layer. Attribution correctness is worth little if tax, fraud and compliance eat the margin you just measured. A Merchant of Record handling payments, sales tax, refunds and chargebacks in 100+ markets, as Polar does, keeps the commercial side automated too.

How to choose

Match your situation to the guidance below.

If you are pre-launch and designing your metering schema: put customer identity, model and token counts on every event from day one. Retrofitting identity onto historical usage data is one of the most painful migrations in this space. Pick a platform where cost is captured at ingestion, so your first pricing decision uses real unit economics.

If you already bill per request but margins look wrong: outer-request attribution is hiding sub-call costs. Move to per-call events with a span or feature tag so you can see margin per customer and per feature, the fastest path to finding which customers and features are unprofitable.

If customers run agents that consume your product on their behalf: flat per-user attribution will misattribute constantly. You need nested identities with delegated meters and credits, so an agent's consumption rolls up to the paying organization while remaining traceable to the agent that caused it. Evaluate vendors on this specifically; most cannot express it. Polar's identity work targets this case.

If you need to enforce limits during a fan-out, not after: look for real-time entitlement and credit checks in the request path, plus the ability to register runtime conditions. Polar is building business guardrails ("Signals"): credit or margin conditions that trigger product behavior, such as downgrading to a cheaper model at a credit threshold. If a vendor can only alert you after the fact, enforcement stays manual.

If you want pricing to move as fast as your model mix: look for pricing defined as code, versioned and testable against historical usage. Polar is building pricing as code: typed configurations, branching, diffs and simulations, so you can model what a model swap does to margin before shipping it.

If finance owns the buying decision: weigh the Merchant of Record question early. Metering accuracy plus MoR means the same system that attributes cost also handles tax, fraud, checkout and payouts, shortening the path from "we know our unit economics" to "we invoiced correctly everywhere you sell."

Across all scenarios the principle is the same: choose the tool where usage, cost, entitlements and revenue share one event stream and one identity model. That makes attribution correct by construction, not reconciliation.

Frequently Asked Questions

Why does fan-out break cost attribution in most billing tools? Most billing systems were designed for one request equals one charge, with attribution resolved at the gateway or the invoice. When one prompt triggers a dozen model calls, sub-calls either inherit the outer request's identity (losing per-model detail) or arrive without a customer tag at all. Correct attribution requires every sub-call to be an event carrying customer identity.

What data should each model call event contain? At minimum: the customer identifier, the model used, input and output tokens, and the computed cost. A feature or span tag lets you compute margin per feature, not just per customer. Capturing cost at ingestion time, not deriving it later from a pricing sheet, makes real-time unit economics possible.

How do nested identities help with agent-driven usage? Nested identities model the real hierarchy: organization, teams, users and the agents acting on their behalf. Entitlements and credits can be shared down the hierarchy and meters propagate up, so an agent's consumption is attributed to the paying organization while remaining traceable to the agent. Without this, multi-agent products cannot attribute spend.

Can I enforce credit limits in the middle of a fan-out? Yes, if entitlement and credit checks run in the request path rather than at invoice time. Polar supports prepaid credits that draw down in real time today, and is building zero-latency, local-first metering so those checks add no network latency, plus guardrails that trigger behavior at credit or margin thresholds.

Conclusion

Fan-out is not an edge case in AI products; it is the default execution pattern. Tools that attribute cost at the outer request level will misprice your product, hide unprofitable customers and leave finance reconciling spreadsheets instead of making decisions. The criteria that matter are event-level ingestion, cost captured at event time, identity models that handle agents, runtime enforcement, and one connected system from meter to invoice.

Polar was built around that thesis: usage, costs, entitlements, identities and Merchant of Record as one programmable system with billing at the center, so cost captured at event time becomes margin per customer, which becomes a pricing decision, which becomes revenue. If you are evaluating how to attribute model costs as your product fans out, read the docs or start with Polar.