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

#28750 [Feature]: Project-scoped end-user/customer budget limits

  • State: open
  • Author: @javimp2003uma
  • 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’m using LiteLLM Projects and would like to enforce both:

A monthly budget at the Project level, for example 100 EUR/month. A separate monthly budget per end-user consuming through that Project, for example 15 EUR/month per user.

Ideally, I would like to use a single virtual key attached to the Project and send the end-user ID in each request, for example via x-litellm-end-user-id or user.

However, from what I understand, customer/end-user budgets seem to be global for a given customer/user ID, rather than scoped to the Project.

The only workaround I can think of right now is creating one virtual key per end-user under the Project, each with its own budget limit. This would work, but it makes key management much more complex.

Could you confirm whether LiteLLM currently supports Project-scoped end-user/customer budget limits? If not, is there a recommended way to achieve this, or would you consider supporting this natively?

Thanks.

### Motivation, pitch

.

### What part of LiteLLM is this about?

Proxy

### LiteLLM is hiring a founding bac…

GitHub resolver

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

Refresh page
vote history (2 events)
#0 of 0 · 31d18h30m29s ago — entered · #import:https:::github.com:berriai:litellm post #2544
The left issue requires cross-cutting authorization, accounting, data-model, and enforcement changes with compatibility and concurrency considerations. The right issue is a localized datetime normalization fix with focused regression tests and limited behavioral risk.
#0 of 0 · 31d17h51m40s ago — current · #import:https:::github.com:berriai:litellm post #3220
The right-side feature requires coordinated changes across authorization, budget accounting, persistence, request identity, configuration, and comprehensive compatibility testing. The left-side fix is comparatively localized to error classification and alert suppression around an existing lifecycle. Therefore the right-side work is substantially harder.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search