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

#31835 [Feature]: SpendLogs historical recalculation and failed request billing policy

  • State: open
  • Author: @limitjupyter-ops
  • Labels: enhancement, proxy

### Check for existing issues

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

### The Feature

I would like LiteLLM to support historical SpendLogs recalculation and configurable failed request billing policy.

Suggested behavior:

1. Admins can recalculate historical spend for a date range. 2. Recalculation can use the current model cost map or a selected pricing rule version. 3. Failed request billing behavior can be configured. 4. Recalculation can correct stale or missing spend fields. 5. The process should be auditable and safe to run repeatedly.

Example failed request billing policies:

- never bill failed requests - bill failed requests only if token usage is present - preserve provider-reported cost - custom callback decides

Suggested admin operation:

```text POST /spend/recalculate

### Motivation, pitch

Spend tracking is operationally important, but historical spend records may need recalculation when:

- model pricing configuration changes - provider returns corrected usage - a bug caused incorrect cost calculation - failed requests were incorrectly billed - enterprise negotiated pricing is updated

Today, teams often need ex…

GitHub resolver

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

Refresh page
vote history (15 events)
#0 of 0 · 31d19h8m4s ago — entered · #import:https:::github.com:berriai:litellm post #1826
The left requires coordinated backend, data-model, pricing, policy, auditability, and idempotent migration work with significant correctness risk. The right is a comparatively contained dashboard interaction and visualization change using existing data.
Issue 31835 is substantially harder because it spans new administrative workflows, historical data processing, pricing-version selection, configurable billing semantics, repeatability, auditing, and safety across persistence and proxy behavior. Issue 27840 is a localized response-shape handling gap with focused code and test changes.
Issue 31835 is substantially harder because it spans persistent data correction, versioned pricing, policy configuration, idempotent execution, auditability, and administrative API design. Issue 31568 is comparatively contained provider integration work, mainly involving routing, model metadata, and pricing translation.
The left issue is harder because it spans streaming correctness, protocol translation, tool/reasoning semantics, and compatibility across multiple independently evolving components. The right issue is primarily a bounded proxy feature involving durable data updates, policy configuration, and auditability.
31835 is harder because it spans new administrative APIs, pricing-version semantics, configurable policy behavior, repeatable data mutation, auditing, and compatibility across historical records. 30460 is a demanding distributed-consistency and failure-mode investigation, but its scope is more concentrated around correcting one spend-counter path.
Historical financial-data mutation requires versioned pricing, idempotency, auditability, safe background execution, and nuanced failure semantics; the other mainly adds authorization-scoped read APIs and UI aggregation.
30421 is harder because it spans a new user-facing CLI workflow, authentication, model discovery, and compatibility with several independently evolving external agent tools. 31835 requires substantial billing-data correctness, versioning, idempotency, and audit safeguards, but remains more contained within LiteLLM's existing proxy and spend systems.
Historical financial-data mutation carries greater correctness, auditability, idempotency, and backward-compatibility risk, especially across pricing versions and provider-specific outcomes. The other feature is broader across storage, enforcement, APIs, and UI, but follows a more straightforward request-gating pattern.
The left is harder because it requires cross-cutting changes to persistence, pricing/version selection, billing semantics, repeatable execution, auditability, and operational safety. The right is mainly a configuration-resolution and routing-graph feature, with recursion, validation, and compatibility risks but a narrower runtime scope.
29320 is harder due to cross-cutting SDK/proxy integration, model execution on the request path, configuration inheritance, observability, fail-open behavior, and performance/isolation risks. 31835 requires substantial billing, persistence, API, and idempotency work but is more contained in administrative and spend-accounting workflows.
28168 spans many proxy subsystems and requires a coherent, portable, secret-safe, idempotent serialization and restore design. 31835 is also data-sensitive and needs auditability and pricing-policy correctness, but its implementation is more concentrated in spend calculation and administration flows.
Historical spend correction has greater scope and risk: it requires safe, repeatable data mutation, pricing-version handling, policy semantics, auditability, and operational safeguards. Custom routing is architecturally significant but can largely be isolated behind a routing extension interface and proxy integration.
Historical accounting changes require durable data processing, versioned pricing semantics, policy evaluation, auditability, and repeat-safe operations across existing records. The authentication work is broader in integration surface but can be more cleanly isolated behind provider and credential abstractions, making its implementation risk lower.
The left item is harder because it spans multiple public interfaces, introduces a complex external runtime dependency, and requires careful handling of configuration, request flows, streaming, errors, deployment, and compatibility testing. The right item is narrower in scope: primarily persistence-layer recalculation, policy evaluation, an administrative endpoint, and auditability concerns.
#0 of 0 · 31d17h31m14s ago — current · #import:https:::github.com:berriai:litellm post #3449
#25447 is harder because it requires diagnosing and preventing a high-severity distributed concurrency and data-isolation failure across replicas and Redis Cluster, with difficult reproduction and correctness risks. #31835 is broader than a simple endpoint but can be implemented as a more bounded administrative workflow with explicit policy handling, idempotency, and auditability.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search