How do I track LLM cost per customer?

Rius splits LLM cost per customer in two ways: put user.id on your spans and read the Users page, or give each customer a workspace and read that workspace’s usage and cost view. Both start from the model name and token counts your instrumentation already records, because Rius computes the cost itself. A custom attribute such as customer_id is stored on the trace but does not produce a cost rollup.

How it works

Rius prices every LLM span at ingest from the requested model (gen_ai.request.model) and its token counts, including cache reads and writes. It then rolls that cost up per trace, per agent, per end user and per workspace. You never send a price or a cost. For the full pricing method, see Track LLM and agent cost.

The split by customer depends on what identifies the customer:

• End users in one workspace. Set user.id on every span, root span included. Rius groups cost, traces, failures and time to first token by that value on the Users page. A span with no user.id counts as anonymous. Use an opaque id rather than an email.
• One workspace per customer. Every trace belongs to exactly one workspace, set by the API key it is sent with. The workspace’s own usage and cost view is then that customer’s cost, with no tagging to maintain. This route also gives each customer isolated keys and alerts.
• A customer_id attribute. Rius stores it and you can inspect it on a trace, but attributes do not drive analytics, so there are no per-customer cost rollups from it.

Costs are list-price estimates in US dollars, from LiteLLM’s public model-price catalog. A call whose model has no price gets an empty cost, not zero.

Set it up

1. Choose the split. If your customers are end users of one agent product and you do not need enforced isolation, tag end users with user.id. If each customer needs isolated keys, alerts and cost, use one workspace per customer.

2. For end users, set user.id. Wrap each request in rius.user(...) in Python or withUser in TypeScript, so the id lands on every span of the run, root included. There is no environment variable for it, by design.

3. For workspaces, create one per customer. Use Create workspace… in the workspace switcher (organization admins only), name it after the customer, then create its API key under Settings → API keys. The number of workspaces is a plan limit, and creating one past it is refused.

4. Send each customer’s traces with that customer’s key. With one deployment per customer, set the key in the environment:

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

   A shared runtime that serves many customers registers the keys once and wraps each request in its customer’s scope:

   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

   Enter the scope at the request boundary, before the root span starts, so one trace stays in one workspace.

5. Read the split. For end users, open Users and sort by Cost. For workspaces, switch to the customer’s workspace and open Usage and cost.

6. Or ask over MCP. Connect the Rius MCP server and ask which end users cost the most this week. The client calls list_users sorted by cost. For workspaces, list_workspaces and workspace_metrics_overview return each workspace’s total and cost by model.

What you get

• Cost per end user. The Users page shows each end user’s total cost and average cost per trace, so you can sort to find your most expensive customers.
• Cost per customer workspace. The usage and cost view shows the period’s total cost, per-trace and per-1k-token averages, cost by model, and the change against the previous period.
• Drill-down. From a customer’s total you can open the traces behind it, and from a trace the individual LLM calls with their model, tokens and cost.
• Alerts per customer. Alerting is configured per workspace, so a cost alert on one customer’s workspace fires and is acknowledged on its own. A cost rule is measured per trace, for example p95 of cost above a dollar value over a rolling window.
• A scriptable summary. Over MCP you can list your workspaces and fetch each one’s metrics, which is enough to build a weekly all-customers cost report.

When something else fits

• If you need every customer’s cost side by side in the console, note that the console shows one workspace at a time. Plan and usage shows span usage against your plan, not cost per workspace, so script that comparison over MCP.
• If you want a total-spend or budget threshold for a whole workspace, that is not an alert metric today. Watch it on the usage and cost view, and use per-trace cost alerts for runs that get expensive.
• If you bill customers from this number, treat it as a list-price estimate. Negotiated, batch, flex, priority and long-context pricing are not applied, so your invoice from the provider can differ.

Related