[Bug]: max_end_user_budget_id ignores budget reset, leading to continuous spend accumulation

[venkivijay]

Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

The max_end_user_budget_id feature doesn't respect budget reset configurations. While RPM, TPM, and max_budget are honored, an end-user's "spend" continuously increases without periodic resets, making true cost budgeting impossible. This essentially makes this feature unusable as the total customer spend will always be increasing and we cannot set a budget on cost.

Root Cause:
The system fetches total cumulative spend from /customer/info?end_user_id=xxx, which is then compared against max_budget without considering any reset schedule.

Relevant code link: if end_user_budget is not None and end_user_object.spend > end_user_budget:

Expected Behavior:

When max_end_user_budget_id is configured, the system should:

1. Allow for the definition of a budget reset period (e.g., daily, weekly, monthly).
2. Reset the end-user's "spend" counter at the beginning of each budget period.
3. Enforce max_budget against the spend accumulated within the current budget period.

Steps to Reproduce

1. Create a new budget specifying Max Budget (USD) and Reset Budget values.
2. In LiteLLM Proxy config.yaml set litellm_settings.max_end_user_budget_id to the id of the above created budget.
3. (Optional) Set litellm_settings.timezone to the appropriate timezone ("Asia/Kolakata" in my case)
4. Start using LiteLLM and check how the budget doesn't reset after the specified period.

Relevant log output

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.81.12

Twitter / LinkedIn details

@venkivijay_ / https://linkedin.com/in/venkivijay

[AtharvaJaiswal005]

Hey, I'd like to work on this!

After digging into the code, the root cause is in _reset_budget_for_enduser() in litellm/proxy/common_utils/reset_budget_job.py (line 635-645). Unlike keys/teams/users which use _reset_budget_common() to:

1. Reset spend = 0.0
2. Reset Redis/in-memory spend counters
3. Update budget_reset_at based on budget_duration

The end-user reset only does spend = 0.0 and skips the cache reset entirely. This means stale spend values persist in the cache and the budget appears to never reset.

Plan:

• Update _reset_budget_for_enduser to reset the spend counter cache (matching the pattern in _reset_budget_common)
• Invalidate the cached end-user object (end_user_id:{id}) so auth checks pick up the reset spend
• Add tests following the existing test patterns in test_reset_budget_job.py

Will open a PR shortly.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.