How do I charge each customer for the LLM cost of my AI agent?

Rius gives you each customer’s LLM cost as a list-price estimate, by workspace per customer or by user.id on each span, and you apply your own pricing to it. Cost is priced on every LLM call from the model and token counts, so you never send a price. Because the figures are estimates at standard rates, use them as the input to your pricing, not as an exact bill.

How it works

Rius prices every LLM span when it arrives, from the requested model and its token counts, including prompt-cache reads and writes. It then rolls that cost up per trace, per agent, per end user and per workspace. Two shapes give you a per-customer number:

• A workspace per customer. Every trace belongs to exactly one workspace, set by the API key it was sent with. The workspace’s own monitoring view then shows that customer’s spend, cost by model and token totals, with no tagging to maintain. Keys, alerts and shared views are scoped to the workspace too, so a leaked key exposes one customer.
• An end user per span. Within one workspace, set user.id on your spans (in Python with rius.user(...), in TypeScript with withUser). The Users page shows each end user’s total cost and average cost per trace, and you can sort by Cost to find your most expensive customers. Prefer an opaque id to an email.

A plain customer_id span attribute identifies the customer on a trace, but it does not drive analytics, so it gives you no per-customer cost rollup.

What list-price estimates mean for billing

Prices come from LiteLLM’s public model-price catalog, in US dollars. Rius applies each model’s standard rates. It does not apply long-context tiers, batch, flex or priority pricing, or any discount you negotiated, so your provider invoice will differ from the figure in Rius. Cost is fixed on a span when it is written, so a later price change does not rewrite past calls.

A call whose model is not in the catalog, or that reported no token usage, gets an empty cost, not zero. A customer’s total adds up only the calls that were priced. Check the cost-by-model chart, which shows how many LLM calls were priced, before you charge from a total.

Set it up

1. Pick the shape. Choose a workspace per customer if you need isolation, per-customer alerts and per-customer cost rollups. Check your plan’s workspace count in the plan details first, because creating a workspace past the limit is refused. Choose user.id if all customers share one workspace and you only need to rank and total them.

2. Create the workspace and its key. In the console, choose Create workspace… from the workspace switcher (organization admins only), name it after the customer, then create an API key in Settings → API keys inside it. The key is shown once, so store it in your secret store, keyed by customer.

3. Send each customer’s traces with that customer’s key. With one deployment per customer, two environment variables are enough:

   export RIUS_API_KEY="ri_..."          # this customer's workspace key
   export RIUS_SERVICE_NAME="support-agent"  # the agent, same name across customers

4. Route by request if one runtime serves many customers. Register the keys once, then wrap each request in its customer’s scope. Enter the scope at the request boundary, before the root span starts, because one trace belongs to one workspace.

   import rius
    
   rius.init(
       api_key=ops_key,  # spans outside any scope go to your own workspace
       service_name="support-agent",
       workspaces={"acme": key_acme, "globex": key_globex},
   )
    
   with rius.workspace("acme"):
       handle(request)  # every span of the request lands in acme's workspace

5. Read each customer’s cost. Open the customer’s workspace and read its monitoring view for the period, or open the Users page and sort by Cost. Run one task first and confirm the LLM calls show a cost in the span detail.

6. Total across customers by script. The console has no cross-workspace rollup, so connect the Rius MCP server and have a client call list_workspaces and then workspace_metrics_overview for each one. list_users sorted by cost covers the per-user shape.

The full pricing and rollup behavior is in Track LLM and agent cost, and the workspace setup is in Multi-tenant agent observability.

What you get

• A per-customer cost figure, per workspace or per end user, with the model, tokens and cost on every LLM call behind it.
• Cost by model for each customer, so you can see which model drives their spend.
• Isolation when you use workspaces: separate API keys, separate alerts, and read-only shared views you can hand a customer as a report of how their agent behaved, without a Rius account.
• A cost alert per workspace, for example on p95 cost per trace, so a runaway customer run is flagged as it happens.
• A scripted all-customers summary through the MCP server, since you see one workspace at a time in the console.

Use the numbers as an estimate of what each customer costs you. Add your own margin, or true up against your provider invoice, before you bill.

When something else fits

• If you must bill customers the exact amount your provider charges, including negotiated or batch discounts, use the provider’s invoice as the source of truth. Rius shows list-price estimates only and has no custom model prices.
• If customers do not need isolation and you only want a ranking, user.id on a single workspace is simpler than a workspace per customer.

Related