Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#7,420 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend-api-design

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
14.6k
Fork
3.9k
Merge medio
2g 23h
PR unite (30g)
177

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di livekit/agents

Tutte le issue di livekit/agents

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.