19 views
-/https://github.com/berriai/litellm/issues/28235
GitHub · issue

#28235 Support multiple concurrent budget windows for users

  • State: open
  • Author: @silencedoctor

### Feature request

LiteLLM currently supports budget_limits for virtual keys and teams, but users can only configure a single max_budget / budget_duration pair. This makes it hard to express multiple concurrent aggregate user budget windows, for example 1000 USD per 30d plus 150 USD per 1d.

### Motivation

Key-level budget_limits do not aggregate across multiple keys that share the same LiteLLM user. Team-level budget_limits constrain the whole team, not an individual user. User-level windows would let admins cap an individual user's aggregate spend while keeping the existing key and team controls.

### Proposed behavior

Add budget_limits to LiteLLM users with the same schema and behavior as key/team budget_limits:

- Persist budget_limits on LiteLLM_UserTable. - Initialize reset_at for each user budget window on user create/update. - Enforce each user window during auth with counters shaped as spend:user:{user_id}:window:{budget_duration}. - Increment and reserve user window counters using the existing spend counter and budget reservation paths. - Reset expired user windows in the existing budget reset job.

Example user configuration:

```json { "user_id": "user-123", "ma…

GitHub resolver

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

Refresh page
vote history (14 events)
#0 of 0 · 31d17h51m39s ago — entered · #import:https:::github.com:berriai:litellm post #3017
Issue 28235 is substantially harder: it requires coordinated persistence, authorization, accounting, concurrency, and reset-job changes with backward-compatibility risk. Issue 29539 appears comparatively localized to a provider-specific bug path.
The right issue is harder because it spans user data modeling, configuration compatibility, authorization-time enforcement, atomic budget accounting, expiration handling, and background reset behavior across shared infrastructure. The left issue is narrower, mainly involving request translation and provider-specific multipart/image handling.
The right issue is harder because it requires coordinated changes across data models, configuration handling, authentication-time enforcement, distributed spend counters, reservation logic, and scheduled resets, with substantial compatibility and migration risk. The left issue is primarily validation and automation of an already-defined multi-provider stack, with comparatively bounded implementation risk.
28168 spans many resource types, persistence layers, schemas, serialization rules, dependency ordering, and deployment/security concerns, creating substantially broader integration and compatibility risk. 28235 is a focused extension of existing budget-window mechanisms across user storage and enforcement paths.
Model-group composition is harder because it changes core deployment resolution and routing semantics, requiring recursive expansion, compatibility handling, and careful interaction with load balancing and rate limits. The budget-window change is substantial but can largely extend existing persistence, reservation, and reset mechanisms to another scope.
27883 has broader cross-tool integration scope, requiring new proxy configuration surfaces, policy translation, persistence/distribution semantics, and compatibility with two independently evolving client ecosystems. 28235 is a more contained extension of existing budget, counter, reset, and authentication paths, with clearer reuse patterns and validation boundaries.
The right issue is harder because it requires coordinated changes across persistence, authentication, distributed spend accounting, reset scheduling, concurrency handling, and backward compatibility. The left issue is comparatively contained within request-transformation adapters and their associated regression tests.
The right issue is harder because it requires reliable distributed-state initialization, failure handling, readiness behavior, and automatic recovery across worker lifecycles. The left issue is broader than a single budget field but can largely extend established persistence, accounting, enforcement, and reset mechanisms.
Issue 28235 is harder because it spans persistence, configuration migration, concurrent quota accounting, authorization enforcement, and scheduled reset behavior across multiple layers. Issue 31467 is primarily a security-hardening change to credential resolution and request validation, though it requires careful regression testing across providers.
28235 is harder because it requires coordinated persistence, concurrency-safe accounting, authentication enforcement, lifecycle resets, backward compatibility, and broad regression coverage across core budget paths. 33371 is mainly an interface and classification-contract extension around existing routing state, with narrower implementation boundaries.
The left task is harder because it spans authenticated API design, authorization and data isolation, aggregation, and dashboard UI work, while the right is primarily a backend extension of existing budget, persistence, counter, and reset mechanisms.
The left issue is harder because it requires coordinated changes across durable data models, authorization-time accounting, concurrent reservation logic, expiration handling, and compatibility-focused testing. The right issue is broader but currently less implementation-specific and appears more suitable for an integration or product-design effort than a deep change to core billing invariants.
#28235 requires coordinated changes across data modeling, configuration flows, authorization, counter reservation, expiration/reset processing, and comprehensive compatibility testing. #30460 is a high-risk distributed-systems bug involving Redis failure handling and counter idempotency, but its implementation scope is more concentrated.
#0 of 0 · 31d17h23m59s ago — current · #import:https:::github.com:berriai:litellm post #3485
The left task spans a new quota metric, calendar-based and timezone-aware lifecycle handling, overflow and warning semantics, enforcement, persistence, and coordinated API/UI exposure. The right task primarily extends existing budget-window, reservation, counter, and reset infrastructure to another entity scope, with concurrency and migration considerations but less new surface area.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search