# Feature request built-in cost dashboard for voice agents **URL:** \ **Category:** Getting Started\ **Tags:** livekit-cloud\ **Created:** [September 5, 2026, 5:35pm UTC](https://community.livekit.io/t/feature-request-built-in-cost-dashboard-for-voice-agents/2006 "2026-09-05T17:35:51Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![mayank\_yadav](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/mayank_yadav/32/670_2.png) [@mayank\_yadav](https://community.livekit.io/u/mayank_yadav)\ **Post date:** [September 5, 2026, 5:35pm UTC](https://community.livekit.io/t/feature-request-built-in-cost-dashboard-for-voice-agents/2006/1 "2026-09-05T17:35:52Z")
Hey LiveKit team 👋 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](https://community.livekit.io/groups/livekit-staff) ---
**Author:** ![abidullahcs.uk](https://avatars.discourse-cdn.com/v4/letter/a/ba8739/32.png) [@abidullahcs.uk](https://community.livekit.io/u/abidullahcs.uk)\ **Post date:** [September 5, 2026, 5:58pm UTC](https://community.livekit.io/t/feature-request-built-in-cost-dashboard-for-voice-agents/2006/2 "2026-09-05T17:58:02Z")
+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(). ---
**Author:** ![areeb\_mohsin1](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/areeb_mohsin1/32/2438_2.png) [@areeb\_mohsin1](https://community.livekit.io/u/areeb_mohsin1)\ **Post date:** [September 6, 2026, 12:16am UTC](https://community.livekit.io/t/feature-request-built-in-cost-dashboard-for-voice-agents/2006/3 "2026-09-06T00:16:02Z")
+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. - Session usage, session reports, and the full field tables: [Data hooks | LiveKit Documentation](https://docs.livekit.io/deploy/observability/data/) - Analytics API, for the telephony side that `session.usage` does not cover: [Analytics API | LiveKit Documentation](https://docs.livekit.io/deploy/admin/analytics-api/) ---
**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\ **Post date:** [September 7, 2026, 10:35am UTC](https://community.livekit.io/t/feature-request-built-in-cost-dashboard-for-voice-agents/2006/4 "2026-09-07T10:35:55Z")
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. ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/system/32/26_2.png) [@system](https://community.livekit.io/u/system)\ **Post date:** [September 22, 2026, 10:36am UTC](https://community.livekit.io/t/feature-request-built-in-cost-dashboard-for-voice-agents/2006/5 "2026-09-22T10:36:15Z")
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.