litellm - ✅(Solved) Fix [Bug]: Inconsistent behavior of "1mo" budget duration for Users vs Team Members [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25432Fetched 2026-04-10 03:41:06
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Participants
Timeline (top)
labeled ×2referenced ×2cross-referenced ×1

LiteLLM uses two different functions to calculate budget_reset_at depending on entity type. This means 1mo (and 30d) has different meanings for Users/Teams/Keys vs Team Members.

Root Cause

LiteLLM uses two different functions to calculate budget_reset_at depending on entity type. This means 1mo (and 30d) has different meanings for Users/Teams/Keys vs Team Members.

Fix Action

Fixed

PR fix notes

PR #25440: fix(budget): align reset times for legacy entities (Team Members, End Users) with standardized calendar

Description (problem / solution / changelog)

Align budget table reset times with standardized calendar schedule.

Relevant issues

Fixes issue #25432

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • I have Added testing in the tests/test_litellm/ directory, - [X] Passes impacted/relevant tests
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I will have requested a Greptile review by commenting @greptileai and will receive a Confidence Score of at least 4/5 before requesting a maintainer review

Type

🐛 Bug Fix

Changed files

  • litellm/proxy/common_utils/reset_budget_job.py (modified, +5/-16)
  • litellm/proxy/management_endpoints/budget_management_endpoints.py (modified, +3/-5)
  • tests/test_litellm/proxy/common_utils/test_reset_budget_job.py (modified, +134/-0)

Code Example

SELECT user_id, budget_duration, budget_reset_at, spend, max_budget
  FROM "LiteLLM_UserTable" WHERE budget_duration IS NOT NULL;

---

SELECT tm.user_id, tm.team_id, tm.spend,
         b.budget_id, b.budget_duration, b.budget_reset_at, b.max_budget
  FROM "LiteLLM_TeamMembership" tm
  JOIN "LiteLLM_BudgetTable" b ON tm.budget_id = b.budget_id
  WHERE b.budget_duration IS NOT NULL;

---
RAW_BUFFERClick to expand / collapse

Check for existing issues

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

What happened?

LiteLLM Budget Reset: Two Different Code Paths for 1mo

Summary

LiteLLM uses two different functions to calculate budget_reset_at depending on entity type. This means 1mo (and 30d) has different meanings for Users/Teams/Keys vs Team Members.

The Two Paths

EntityFunctionIntroduced1mo Behavior
Keysget_next_standardized_reset_time()April 2025, PR #103311st of next month at midnight (calendar-aligned)
Usersget_next_standardized_reset_time()April 2025, PR #103311st of next month at midnight (calendar-aligned)
Teamsget_next_standardized_reset_time()April 2025, PR #103311st of next month at midnight (calendar-aligned)
Team Membersduration_in_seconds()Sep 2023 (original)Same day/time next month, sliding window from NOW
End-Usersduration_in_seconds()Sep 2023 (original)Same day/time next month, sliding window from NOW

Code Locations (reset_budget_job.py)

  • Standardized path: _reset_budget_common() (line 553) calls get_budget_reset_time() at lines 605-608
  • Legacy path: _reset_budget_reset_at_date() (line 650) calls duration_in_seconds() at lines 656-659
  • Team Members/End-Users enter via reset_budget_for_litellm_budget_table() (line 136)

Context

The standardized function seems to having been introduced in April 2025 (PR #10331) to align resets to calendar boundaries. However, the Budget Table path (Team Members, End-Users) still uses the legacy duration_in_seconds, either by design or oversight.

Impact

Impossible to implement the "calendar month" budget semantics for Team Members, at least without external crutches / manual updates to budget_reset_at via API etc.

Steps to Reproduce

  1. Create an Internal User with a fixed budget and "1mo" Budget Duration
  2. Add user to a Team and set Team Member Budget also with 1mo" Budget Duration
  3. Check "budget_reset_at" in Postgre
  • For Users, it will be aligned to Calendar Month
  SELECT user_id, budget_duration, budget_reset_at, spend, max_budget
  FROM "LiteLLM_UserTable" WHERE budget_duration IS NOT NULL;
  • For Team Members, it will not be aligned to Calendar Month
  SELECT tm.user_id, tm.team_id, tm.spend,
         b.budget_id, b.budget_duration, b.budget_reset_at, b.max_budget
  FROM "LiteLLM_TeamMembership" tm
  JOIN "LiteLLM_BudgetTable" b ON tm.budget_id = b.budget_id
  WHERE b.budget_duration IS NOT NULL;
  1. Optionally, wait for the 1st of the month. User budget is reset, Team Member budget will not be reset.

Relevant log output

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

main

Twitter / LinkedIn details

No response

extent analysis

TL;DR

  • Update the reset_budget_for_litellm_budget_table() function to use the standardized get_next_standardized_reset_time() function for Team Members and End-Users to align budget resets with calendar months.

Guidance

  • Identify the entity type (User, Team, Team Member, End-User) and its corresponding function for calculating budget_reset_at to understand the current behavior.
  • Review the code locations in reset_budget_job.py to understand the different paths for calculating budget_reset_at.
  • Consider updating the duration_in_seconds() function to align with the standardized get_next_standardized_reset_time() function for consistency.
  • Test the changes by creating Internal Users and Team Members with "1mo" Budget Duration and verifying the budget_reset_at values in the database.

Example

  • Update the _reset_budget_reset_at_date() function to call get_budget_reset_time() instead of duration_in_seconds() to align Team Member and End-User budget resets with calendar months.

Notes

  • The fix assumes that the desired behavior is to align all budget resets with calendar months, which may not be the case if the legacy behavior is intended for certain entity types.
  • Additional testing and verification may be necessary to ensure that the changes do not introduce unintended consequences.

Recommendation

  • Apply workaround: Update the reset_budget_for_litellm_budget_table() function to use the standardized get_next_standardized_reset_time() function for Team Members and End-Users, as this will provide a consistent and predictable behavior for budget resets.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING