Feature request built-in cost dashboard for voice agents

Getting Started
1

Hey LiveKit team :waving_hand:

Been building production voice agents (Deepgram STT + Cartesia TTS, custom LLM) and consistently run into the same gap: there’s no single place to see actual $ cost per call/session.

Would love to see:

  • A cost dashboard in LiveKit Cloud (Agent Insights) that shows estimated $ cost per session, broken down by component (STT/LLM/TTS/telephony), using whatever rate card applies (LiveKit Inference pricing if using Inference, or a configurable rate table for BYO provider keys)
  • Optionally, a per-call cost field in the session report (ctx.make_session_report()) so it’s queryable without re-deriving it
  • Even a simple exportable CSV/API of session cost estimates would unlock building client billing/quoting on top of it (this is our actual use case — we quote clients per-minute pricing and need accurate cost data to price it right)

Happy to be a guinea pig / give feedback if this is already on the roadmap. Is this something the team has discussed, or is there a recommended pattern for this today that I’m missing?

Thanks for all the work on Agents it’s been solid to build on.

@LiveKit-Community @livekit @LiveKit-Staff

2

+1, though most of what you need is already there. session.usage returns one entry per model/provider combination, so you get Deepgram’s audio_duration, Cartesia’s characters_count, and your LLM’s token counts already broken down by component. Multiply by your own rates and you have per-call cost today.

Heads up if you go looking: UsageCollector is deprecated in favour of ModelUsageCollector, and AgentSession already builds one internally, so there’s nothing to attach.

Both Langfuse and LangSmith have official LiveKit integrations that hang off the built-in OTel support, but they give you token metrics and latency, not dollar cost, so you’d still bring your own rate table.

The real ask is LiveKit owning the rate card, and that’s the hard part with BYO keys since your Deepgram and Cartesia contract rates aren’t visible to them. The configurable rate table you suggested is probably the only workable shape. Agreed it belongs in make_session_report().

3

+1 on the rate card being the real ask. Abid’s summary is right, with one correction that matters for your second bullet.

Model usage is already in make_session_report(). The docs list the SessionReport as a per-session final snapshot with identifiers, history, events, and model usage. So the plumbing you asked for exists. The only missing piece is dollars, which means this is purely a rate-card problem, not an API-surface problem. Worth reframing the request that way, it is a much smaller ask.

Small nuance on the deprecation: UsageCollector and UsageSummary are deprecated in favour of reading session.usage directly. ModelUsageCollector is what AgentSession builds internally, so you never instantiate it yourself.

Also worth knowing: session_usage_updated fires during the session, not just at the end, so you can build live per-call cost tracking rather than waiting for shutdown.

Four things that will produce wrong invoices

Since you are quoting clients off this, these are the ones I would check before trusting your numbers:

  1. Python durations are seconds, Node.js durations are milliseconds. audio_duration vs audioDurationMs, session_duration vs sessionDurationMs. A 1000x error in a billing pipeline is the kind of bug you find from a customer.

  2. Cached tokens are broken out and you will overcharge if you ignore them. LLMModelUsage gives you input_cached_tokens, plus input_cached_audio_tokens, input_cached_text_tokens and input_cached_image_tokens. Cached input is billed well below full input rate by most providers. Bill on input_tokens alone and every quote is inflated.

  3. Telephony is not in session.usage at all. It covers models only, so your STT/LLM/TTS breakdown is complete but the telephony line item is not there. SIP minutes come from the billing and analytics side instead. That is a genuine gap in “it is already there.”

  4. session_end_timeout defaults to 5 minutes and bounds your on_session_end callback. If you are POSTing cost records to an external billing service from there, raise it. The separate shutdown_process_timeout (10s default) bounds process shutdown after callbacks finish.

One more that helps the self-hosted crowd: make_session_report() and to_dict() run entirely in the agent process from data the SDK already has, with no calls to LiveKit Cloud. So the same billing code works self-hosted.

On the rate card

Agreed a configurable rate table is the only workable shape for BYO keys, since your negotiated Deepgram and Cartesia rates are not visible to LiveKit. But it is worth splitting the ask in two, because one half is easy:

  • Inference users: LiveKit knows the rates, so per-session dollars could be computed today with no configuration.
  • BYO keys: user-supplied rate table, applied to the model_usage entries that already exist.

Shipping the first half alone would cover a lot of people, and the second half is then a config surface rather than a data problem.

4

Thanks for the feature request, and thank you for everyone piling on because it helps to understand the prioritization of any features.

We do have this on our backlog currently, specifically enhancements to the dashboard as described to expose session cost and break it down by component. I don’t have any dates I can share I’m afraid but looking at the internal tickets I also see folks on the enterprise plan also asking for this, so this feature is unlikely to fall off the backlog and be forgotten about.