8 views
-/https://github.com/berriai/litellm/issues/29575
GitHub · issue

#29575 [Bug]: Langfuse logs zero token usage for OpenAI Responses API calls

  • State: open
  • Author: @DanielMaly
  • Labels: llm translation

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

When using the OpenAI Responses API (`/v1/responses`) through LiteLLM, Langfuse traces show `input: 0`, `output: 0`, `total: 0` token usage despite the underlying model returning correct token counts.

This is because the Langfuse callback reads `prompt_tokens`/`completion_tokens` from the usage object, but Responses API responses use `input_tokens`/`output_tokens` instead. The callback never falls back to the Responses API field names, so it logs zeros.

Additionally, the response output content for Responses API calls was not being logged — the callback only extracted content from Chat Completion-style response objects, not from `ResponseCompletedEvent.response.output`.

### Relevant log output

```shell # Trace in Langfuse shows: input: 0, output: 0, total: 0

# But LiteLLM spend logs show correct counts: input_tokens: 16, output_tokens: 21 ```

### Are you a ML Ops Team?

No, individual self-hosted user.

### What LiteLLM version are you on?

v1.74 (latest at time of reporting)

### Relevant stack trace

```python # In langfuse.py _log_lang…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (4 events)
#0 of 0 · 31d19h3m40s ago — entered · #import:https:::github.com:berriai:litellm post #1795
The right issue is harder because it spans frontend state handling, API update semantics, persistence, credential-preservation safeguards, and regression testing. The left issue is comparatively localized to callback field normalization and response extraction.
The right issue is harder because it requires callback compatibility across distinct response schemas, token accounting, content extraction, and regression coverage; the left issue is comparatively localized URL routing and configuration propagation.
Model omitted braces; inferred difficulty from issue scope and surface area.
#0 of 0 · 31d17h53m45s ago — current · #import:https:::github.com:berriai:litellm post #2956
Issue 29575 is harder because it spans callback integration behavior, multiple response schemas, usage normalization, content extraction, and regression coverage across observability paths. Issue 26707 is comparatively localized to multipart request parsing and downstream validation, with a narrower implementation surface.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search