litellm - 💡(How to fix) Fix [Bug]: Analytics API returns 0 tokens despite token usage data correctly stored in database [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#24910Fetched 2026-04-08 02:23:48
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×3commented ×1mentioned ×1subscribed ×1

The Analytics API endpoint /api/v1/analytics/tokens returns 0 for all token counts across all models, despite token usage data being correctly stored in the chat_message table. The per-message token counter in the chat UI works correctly and displays accurate counts.

Root Cause

The Analytics API endpoint /api/v1/analytics/tokens returns 0 for all token counts across all models, despite token usage data being correctly stored in the chat_message table. The per-message token counter in the chat UI works correctly and displays accurate counts.

Code Example

DEFAULT_MODEL_METADATA: '{"capabilities": {"usage": true}}'
DEFAULT_MODEL_PARAMS: '{"stream_options": {"include_usage": true}}'

---

SELECT 
    model_id,
    SUM(json_extract(usage, '$.prompt_tokens')) as prompt,
    SUM(json_extract(usage, '$.completion_tokens')) as completion,
    SUM(json_extract(usage, '$.total_tokens')) as total,
    COUNT(*) as messages
FROM chat_message
WHERE usage IS NOT NULL
AND usage != 'null'
AND json_extract(usage, '$.total_tokens') > 0
GROUP BY model_id;

---

('company-assist-fast', 110, 645, 755, 5)

---

{
  "model_id": "company-assist-fast",
  "input_tokens": 0,
  "output_tokens": 0,
  "total_tokens": 0,
  "message_count": 23
}

---

{
  "completion_tokens": 195,
  "prompt_tokens": 57,
  "total_tokens": 252,
  "completion_tokens_details": {
    "accepted_prediction_tokens": 0,
    "audio_tokens": 0,
    "reasoning_tokens": 0,
    "rejected_prediction_tokens": 0
  },
  "prompt_tokens_details": {
    "audio_tokens": 0,
    "cached_tokens": 0
  }
}

---

DEFAULT_MODEL_METADATA: '{"capabilities": {"usage": true}}'
DEFAULT_MODEL_PARAMS: '{"stream_options": {"include_usage": true}}'

---
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

Environment

  • Open WebUI version: v0.8.12
  • Installation: Docker
  • Backend: LiteLLM proxy → Azure AI Foundry (OpenAI-compatible)
  • Database: SQLite (default)

Description

The Analytics API endpoint /api/v1/analytics/tokens returns 0 for all token counts across all models, despite token usage data being correctly stored in the chat_message table. The per-message token counter in the chat UI works correctly and displays accurate counts.

Steps to Reproduce

  1. Configure Open WebUI with an OpenAI-compatible backend (LiteLLM or Azure OpenAI)
  2. Enable usage tracking via environment variables:
DEFAULT_MODEL_METADATA: '{"capabilities": {"usage": true}}'
DEFAULT_MODEL_PARAMS: '{"stream_options": {"include_usage": true}}'
  1. Send several chat messages — token counts appear correctly below each response in the UI
  2. Navigate to Admin Panel → Analytics — Total Tokens shows 0
  3. Call /api/v1/analytics/tokens directly — all models show input_tokens: 0, output_tokens: 0, total_tokens: 0

Verification — Data Exists in DB

Direct SQLite query confirms data is present and correctly structured:

SELECT 
    model_id,
    SUM(json_extract(usage, '$.prompt_tokens')) as prompt,
    SUM(json_extract(usage, '$.completion_tokens')) as completion,
    SUM(json_extract(usage, '$.total_tokens')) as total,
    COUNT(*) as messages
FROM chat_message
WHERE usage IS NOT NULL
AND usage != 'null'
AND json_extract(usage, '$.total_tokens') > 0
GROUP BY model_id;

Result:

('company-assist-fast', 110, 645, 755, 5)

Analytics API Response (same model)

{
  "model_id": "company-assist-fast",
  "input_tokens": 0,
  "output_tokens": 0,
  "total_tokens": 0,
  "message_count": 23
}

Note: message_count is correct (23) but all token values are 0. This confirms the analytics router can find the messages but fails to aggregate token data from the usage JSON column.

Sample usage JSON Stored in DB

{
  "completion_tokens": 195,
  "prompt_tokens": 57,
  "total_tokens": 252,
  "completion_tokens_details": {
    "accepted_prediction_tokens": 0,
    "audio_tokens": 0,
    "reasoning_tokens": 0,
    "rejected_prediction_tokens": 0
  },
  "prompt_tokens_details": {
    "audio_tokens": 0,
    "cached_tokens": 0
  }
}

Expected Behaviour

/api/v1/analytics/tokens should return aggregated token counts matching what is stored in the chat_message.usage JSON column.

Actual Behaviour

All token values return 0 despite data being present and correctly structured in the database. Message counts are correctly returned, indicating the query reaches the right rows but fails to extract the JSON token values.

Possible Cause

The analytics router query may not be correctly using json_extract() on the usage column, or there may be a mismatch in how JSON aggregation is handled for the usage field compared to how message counts are aggregated.

Steps to Reproduce

  1. Configure Open WebUI with an OpenAI-compatible backend (LiteLLM or Azure OpenAI)
  2. Enable usage tracking via environment variables:
DEFAULT_MODEL_METADATA: '{"capabilities": {"usage": true}}'
DEFAULT_MODEL_PARAMS: '{"stream_options": {"include_usage": true}}'
  1. Send several chat messages — token counts appear correctly below each response in the UI
  2. Navigate to Admin Panel → Analytics — Total Tokens shows 0
  3. Call /api/v1/analytics/tokens directly — all models show input_tokens: 0, output_tokens: 0, total_tokens: 0

Relevant log output

What part of LiteLLM is this about?

UI Dashboard

What LiteLLM version are you on ?

v1.82.6

Twitter / LinkedIn details

No response

extent analysis

TL;DR

The Analytics API endpoint /api/v1/analytics/tokens may not be correctly aggregating token counts from the usage JSON column in the database, suggesting a potential issue with the query or JSON handling.

Guidance

  • Verify that the json_extract() function is correctly used in the analytics router query to extract token values from the usage column.
  • Check for any differences in how JSON aggregation is handled for the usage field compared to message counts.
  • Review the database query used by the /api/v1/analytics/tokens endpoint to ensure it accurately reflects the structure of the usage JSON column.
  • Consider testing the query directly on the database to isolate the issue.

Example

No specific code example can be provided without more details on the analytics router query, but the correct use of json_extract() in the SQLite query provided in the issue description is a good reference point:

SELECT 
    model_id,
    SUM(json_extract(usage, '$.prompt_tokens')) as prompt,
    SUM(json_extract(usage, '$.completion_tokens')) as completion,
    SUM(json_extract(usage, '$.total_tokens')) as total,
    COUNT(*) as messages
FROM chat_message
WHERE usage IS NOT NULL
AND usage != 'null'
AND json_extract(usage, '$.total_tokens') > 0
GROUP BY model_id;

Notes

The issue seems to be related to how the analytics endpoint handles JSON data in the database. Without access to the specific query or code used by the /api/v1/analytics/tokens endpoint, it's challenging to provide a precise fix. However, focusing on the correct extraction and aggregation of JSON data should lead to a resolution.

Recommendation

Apply a workaround by directly querying the database with a verified query that correctly extracts and aggregates token counts, and then use this data to populate the analytics display until the issue with the /api/v1/analytics/tokens endpoint is resolved. This approach ensures that accurate token usage data is available for administrative purposes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING