Check for existing issues
What happened?
Hard-budget checks use different boundary operators for the same product concept on current litellm_internal_staging at commit 65ca095d4d15a82372e53a547a2390a69f7e1797
Key, user, organization, and centralized team-member checks reject when current spend is equal to the configured maximum by using >=
The following active checks admit at equality:
| Scope |
Current condition |
Result when spend == max |
| Team |
spend > team_object.max_budget |
admitted |
| End user |
end_user_spend > end_user_budget |
admitted |
| Tag |
continue while tag_spend <= max_budget |
admitted |
| Virtual-key model |
_current_spend > max_budget |
admitted |
| End-user model |
_current_spend > max_budget |
admitted |
Relevant code:
At the exact hard limit, these scopes allow another request while key, user, organization, and the current centralized team-member path block it
Reservation can prevent some overspend when a reliable maximum request cost is available, but the read-time check remains authoritative when reservation is skipped or cannot estimate the request
The expected behavior is one documented boundary rule for hard budgets, preferably current_spend >= max_budget to match the key, user, organization, and centralized team-member checks
Steps to Reproduce
In focused unit calls, stub the Redis-first spend lookup to return 10.0, configure the relevant maximum as 10.0, and invoke each helper
Equivalent test setup:
current_spend = 10.0
max_budget = 10.0
# Team: _team_max_budget_check with team_object.spend/max_budget == 10
# End user: _check_end_user_budget with spend/max_budget == 10
# Tag: _tag_max_budget_check with tag spend/max_budget == 10
# Model: is_key_within_model_budget with model spend/max_budget == 10
Observed in the current code:
team_equal: allowed
end_user_equal: allowed
tag_equal: allowed
virtual_key_model_equal: allowed
end_user_model_equal: allowed
No BudgetExceededError is raised until spend is strictly greater than the cap
Expected:
team_equal: BudgetExceededError
end_user_equal: BudgetExceededError
tag_equal: BudgetExceededError
virtual_key_model_equal: BudgetExceededError
end_user_model_equal: BudgetExceededError
A regression test should parameterize every hard-budget entity at max - epsilon, max, and max + epsilon
Relevant log output
spend=10.0 max_budget=10.0
actual: request admitted for team, end-user, tag, and per-model checks
expected: hard-budget rejection at equality
What part of LiteLLM is this about?
Proxy
What LiteLLM version are you on ?
Current litellm_internal_staging at 65ca095d4d15a82372e53a547a2390a69f7e1797
Twitter / LinkedIn details
No response
Check for existing issues
What happened?
Hard-budget checks use different boundary operators for the same product concept on current
litellm_internal_stagingat commit65ca095d4d15a82372e53a547a2390a69f7e1797Key, user, organization, and centralized team-member checks reject when current spend is equal to the configured maximum by using
>=The following active checks admit at equality:
spend > team_object.max_budgetend_user_spend > end_user_budgettag_spend <= max_budget_current_spend > max_budget_current_spend > max_budgetRelevant code:
At the exact hard limit, these scopes allow another request while key, user, organization, and the current centralized team-member path block it
Reservation can prevent some overspend when a reliable maximum request cost is available, but the read-time check remains authoritative when reservation is skipped or cannot estimate the request
The expected behavior is one documented boundary rule for hard budgets, preferably
current_spend >= max_budgetto match the key, user, organization, and centralized team-member checksSteps to Reproduce
In focused unit calls, stub the Redis-first spend lookup to return
10.0, configure the relevant maximum as10.0, and invoke each helperEquivalent test setup:
Observed in the current code:
No
BudgetExceededErroris raised until spend is strictly greater than the capExpected:
A regression test should parameterize every hard-budget entity at
max - epsilon,max, andmax + epsilonRelevant log output
spend=10.0 max_budget=10.0 actual: request admitted for team, end-user, tag, and per-model checks expected: hard-budget rejection at equalityWhat part of LiteLLM is this about?
Proxy
What LiteLLM version are you on ?
Current
litellm_internal_stagingat65ca095d4d15a82372e53a547a2390a69f7e1797Twitter / LinkedIn details
No response