6 views
-/https://github.com/berriai/litellm/issues/26701
GitHub · issue

#26701 [Bug] custom_llm_provider not propagated to budget_limiter.async_log_success_event for /v1/messages + /v1/embeddings

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

## Bug

When `provider_budget_config` is enabled (e.g., `anthropic: 5.0/24h`), every call to `/v1/messages` (Anthropic format) and `/v1/embeddings` triggers a `ValueError` in the budget-limiter callback. Calls succeed (200 OK), but stderr floods with traceback from `budget_limiter.async_log_success_event`.

## Reproducer

LiteLLM v1.83.7, config:

```yaml litellm_settings: callbacks: ["prometheus"]

provider_budget_config: anthropic: budget_limit: 5.0 time_period: "24h"

model_list: - model_name: claude-haiku-4-5-direct-anthropic litellm_params: model: anthropic/claude-haiku-4-5-20251001 api_key: os.environ/ANTHROPIC_API_KEY ```

Then call:

```bash curl -X POST http://litellm:4000/v1/messages \ -H "x-api-key: $LITELLM_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "Content-Type: application/json" \ -d '{"model":"claude-haiku-4-5-direct-anthropic","max_tokens":10,"messages":[{"role":"user","content":"hi"}]}' ```

Returns 200 + valid response, BUT stderr emits ValueError from `router_strategy/budget_limiter.py` complaining about missing `custom_llm_provider` in the kwargs/data dict.

Same behavior for `/v1/embeddings` calls.

## Frequency

In ou…

GitHub resolver

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

Refresh page
vote history (2 events)
#0 of 0 · 31d18h30m52s ago — entered · #import:https:::github.com:berriai:litellm post #2358
Issue 30956 is harder because it spans the cross-cutting OTel V2 instrumentation pipeline, content capture, event generation, exporter behavior, and compatibility across providers and modes. Issue 26701 is comparatively localized to preserving an existing parameter through a few request and callback paths, with narrower regression coverage.
#0 of 0 · 31d17h52m45s ago — current · #import:https:::github.com:berriai:litellm post #2988
The right issue is harder because it requires tracing and correcting provider metadata propagation across multiple request paths and the budget-limiter callback, with regression coverage for integrations that currently succeed but emit failures. The left issue is a narrowly scoped API addition with limited implementation and testing risk.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search