Expose LiveKit Inference cost/pricing through AgentSessionUsage or a pricing API

オープン
  • 何か問題がありますか？
#7,420 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
backend-api-design

調査の方向性

Start by reading the AgentSessionUsage and session_usage_updated definitions, then compare how LiveKit Inference usage differs from provider-plugin usage. The issue leaves open whether cost belongs in session usage or a pricing API, so first clarify the preferred API direction and how rates should account for plans. Done means an agreed, machine-readable approach for estimating LiveKit Inference costs while allowing BYOK costs to remain unavailable or externally resolved.

索引モデルが issue の本文から書いたものです。

説明

enhancement
Feature Type

Would make my life easier

Feature Description

LiveKit Agents now exposes normalized model usage through
AgentSessionUsage / session_usage_updated.

This already gives applications most of the information needed for
cost observability: provider, model, token usage, audio duration,
character counts, session duration, etc.

However, there is an important distinction between the two ways models
can be used in LiveKit Agents:

1. LiveKit Inference

With LiveKit Inference, developers use LiveKit's model interface and
LiveKit Cloud credentials rather than bringing a separate provider API
key.

LiveKit meters and bills this usage directly.

For this path, LiveKit already knows:

  • the model being used
  • the billing unit
  • the measured usage
  • the LiveKit Inference rate applicable to that usage

So it would be useful if this cost information were exposed
programmatically.

For example:

usage = session.usage

for model in usage.model_usage:
    print(model.provider)
    print(model.model)
    print(model.estimated_cost)

or at the session level:

session.usage.estimated_cost

For LiveKit Inference, this could potentially represent the amount
LiveKit expects to bill for the recorded usage.

2. Provider plugins / BYOK

This is different when using provider plugins such as:

from livekit.plugins import openai, deepgram, cartesia

with the developer's own API keys.

In that case LiveKit cannot necessarily know the customer's actual
rate because pricing may depend on provider plans, volume discounts,
enterprise agreements, regions, etc.

I don't think LiveKit needs to guarantee cost for this path.

The cost field could simply be unavailable / None, or applications
could provide their own pricing resolver.

For example:

model_usage.estimated_cost  # populated for LiveKit Inference
model_usage.estimated_cost  # None for BYOK
Alternative: machine-readable LiveKit Inference pricing

If attaching cost directly to AgentSessionUsage isn't desirable,
another useful option would be a machine-readable LiveKit Inference
pricing endpoint/catalog.

Today the pricing is published on the LiveKit Inference pricing page,
but applications that want to calculate cost programmatically need a
stable way to map:

model ID + usage unit -> LiveKit Inference rate

Ideally this would also account for the project's applicable LiveKit
plan/rate where possible.

I maintain an open-source pricing catalog for voice AI models:

https://github.com/mahimailabs/voice-prices/

It includes LiveKit Inference alongside direct provider pricing.

I'd be happy to integrate an official pricing endpoint into
voice-prices, or contribute an implementation if there is an API
direction LiveKit prefers.

The main use case is per-call / per-session cost observability:

STT + LLM + TTS + realtime/inference models
↓
session usage
↓
actual/estimated
cost

Workarounds / Alternatives

For LiveKit Inference today, applications can take the usage returned
by AgentSessionUsage and maintain a separate copy of the pricing
table.

That works, but it means every application interested in cost
observability has to independently:

  • mirror LiveKit Inference pricing
  • keep rates synchronized when pricing changes
  • understand the billing unit for each model
  • distinguish regular / Scale / custom pricing
  • map model identifiers to pricing records

This is especially unfortunate for LiveKit Inference because LiveKit
is already the system metering and billing the usage.

For BYOK/provider plugins, maintaining application-side pricing is
reasonable because LiveKit does not control the customer's provider
contract.

Additional Context

LiveKit currently documents LiveKit Inference as a separate model
access path from provider plugins:

LiveKit Inference:

  • no separate provider API key
  • usage managed through LiveKit Cloud
  • billed by LiveKit based on usage

Provider plugins:

  • developer supplies their own provider credentials
  • provider billing/rate limits are managed separately

AgentSessionUsage already gives us a normalized usage abstraction.
Having an authoritative cost source for the LiveKit Inference half
would close the remaining observability gap.

主要言語
Python
スター
14.6k
フォーク
3.9k
平均マージ
2日 21時間
マージ済み PR（30日）
249

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

livekit/agents のほかの issue

livekit/agents の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。