How do I track LLM cost per conversation?

Rius prices every model call and shows cost per trace, and the session.id you set on your spans ties the traces of one conversation together. A conversation’s cost is the sum of its traces. Over MCP, agent_traces_summary with a session_id filter returns that total in one call, and in the console the Session link in a trace’s header lists every span of that conversation. You set the session id from your own conversation id, and Rius computes the cost from the model and token counts on each span. You never send a cost value.

How it works

Two things on the spans make the split possible.

• The session id. A session is one conversation or job as your users see it. Each turn of a chat is its own trace, and the session.id attribute groups those traces. Your application mints the id, so it can be the conversation id you already have. Set it on every span, root included. A trace with no session id counts as its own single-trace session, so if an agent’s session count equals its trace count, nothing is setting it.
• The model and token counts. Rius prices each model call from gen_ai.request.model and the gen_ai.usage.* token counts, with prompt-cache reads and writes at their own rates. A span that carries only gen_ai.response.model is not priced. A model missing from the price catalog, or a span with no token usage, gets an empty cost, not $0.

The cost of a conversation is the cost of the traces that share its session id. Rius shows cost on each model call, on each trace, per agent, per end user and per workspace. Prices come from LiteLLM’s public model-price catalog in US dollars, so every figure is a list-price estimate and your invoice can differ. Spans with an unpriced model leave a gap in that sum.

Set it up

1. Send traces with the SDK and make sure each model call records its model and token usage. Auto-instrumentation does this for the supported libraries. The Track LLM and agent cost guide covers pricing and what an unpriced call looks like.
2. Give every conversation an id from your own system, such as a chat or ticket id.
3. Stamp that id on the spans of each turn. In Python, use rius.session. In TypeScript, use withSession. Both set session.id on every span inside the scope, so wrap the whole turn, root span included.
4. If one process handles exactly one conversation or job, set the id for the whole process instead:

export RIUS_SESSION_ID=chat-881

5. Keep the id opaque and stable across turns. A conversation that outlives a deploy or moves between replicas stays one session, because the grouping rides on the traces, not on the process.
6. If you also want per-person totals, set user.id the same way. Prefer an opaque id to an email, because the value is stored on every span.

What you get

• Cost on every turn. Open the trace list and read the cost of each trace, and open a trace to see the cost of each model call in the span detail. The Spans tab sorts individual calls by cost, and the map view has a cost lens that shows where the money went in one run.
• Turns that belong together. Traces carrying the same session.id are the turns of one conversation, so you can add up a conversation’s cost from its traces. The concepts page explains how sessions relate to traces and agents.
• Wider rollups beside it. An agent’s total and average cost per trace, cost by end user on the Users page, and the workspace total with cost by model on Usage and cost.
• Cost over MCP. Connect the Rius MCP server and ask in plain language. The client uses list_agent_traces and list_spans for individual runs and calls, agent_traces_summary for an agent’s totals or, with a session_id filter, one conversation’s total, and workspace_metrics_overview for the workspace.
• Alerts scoped to a session. Custom alert rules on cost can be filtered by session, but cost is measured per trace, so a rule fires when one turn of the sessions you name crosses the threshold, not when a conversation’s total does. A conversation-total alert is not available.

When something else fits

• If you need cost per customer rather than per conversation, tag end users with user.id and use the Users page, or run one workspace per customer so the workspace total is that customer’s cost.
• If you need a budget threshold across the whole workspace, watch it on Usage and cost, because total spend is not an alert metric.

Related