litellm - 💡(How to fix) Fix [Bug]: Budget enforcement bypassed in v1.82.3 for key/user max_budget despite spend exceeding max_budget [3 comments, 3 participants]

Python 3.11.x

Steps to reproduce
Deploy LiteLLM Proxy v1.82.3 on a new machine
Use the same config as the environment running v1.81.0
Create a key with a low max_budget, for example:
{
  "max_budget": 0.05
}

Send requests through this key until spend exceeds the budget
Observe that:
spend continues increasing
requests still succeed
no budget block is triggered
Also tested with user max_budget, with the same result:
spend increases
requests continue
no enforcement happens
Observed behavior
Example key info after budget is exceeded:

{
  "key": "sk-YDWeeYDVv1Sr_Ci_rCgjtQ",
  "info": {
    "key_name": "sk-...gjtQ",
    "key_alias": "test1",
    "soft_budget_cooldown": false,
    "spend": 0.540408,
    "expires": null,
    "models": [
      "all-team-models"
    ],
    "aliases": {},
    "config": {},
    "router_settings": {},
    "user_id": "08ed2a11-fc16-41f1-8c90-1aefb621f58c",
    "team_id": null,
    "agent_id": null,
    "project_id": null,
    "permissions": {},
    "max_parallel_requests": null,
    "metadata": {},
    "blocked": null,
    "tpm_limit": null,
    "rpm_limit": null,
    "max_budget": 0.05,
    "budget_duration": null,
    "budget_reset_at": null,
    "allowed_cache_controls": [],
    "allowed_routes": [
      "llm_api_routes"
    ],
    "policies": [],
    "access_group_ids": [],
    "model_spend": {},
    "model_max_budget": {},
    "budget_id": null,
    "organization_id": null,
    "object_permission_id": null,
    "created_at": "2026-04-28T05:40:04.615000+00:00",
    "created_by": "08ed2a11-fc16-41f1-8c90-1aefb621f58c",
    "updated_at": "2026-04-28T05:55:07.573000+00:00",
    "updated_by": "08ed2a11-fc16-41f1-8c90-1aefb621f58c",
    "last_active": "2026-04-28T05:55:07.577000+00:00",
    "rotation_count": 0,
    "auto_rotate": false,
    "rotation_interval": null,
    "last_rotation_at": null,
    "key_rotation_at": null,
    "litellm_budget_table": null,
    "litellm_organization_table": null,
    "litellm_project_table": null,
    "object_permission": null,
    "jwt_key_mappings": null
  }
}



Key points:
max_budget is set to 0.05
spend is 0.540408
spend > max_budget
blocked is still null
requests continue succeeding
This suggests that spend tracking is working, but budget enforcement is not.
Expected behavior
Once spend exceeds max_budget, LiteLLM should reject further requests for that key/user and return a budget exceeded error (for example HTTP 429 / BudgetExceededError).

This is the behavior we see in the environment running v1.81.0.
Additional verification
We verified the following:
Verification 1
After exceeding the budget:
requests still succeed
spend keeps increasing
Verification 2
This affects both:
key budget
user budget
Verification 3
The key object clearly shows:
max_budget is present
spend is already above max_budget
enforcement is still not triggered
Why this looks like a bug
This does not look like a configuration issue because:
the config is the same as the environment where v1.81.0 works
budget values are being stored correctly
spend is being tracked correctly
only the enforcement/blocking part appears to be missing
This looks like a regression or an auth/budget-check path issue in v1.82.3.
Can you help us debug this?
Could you help confirm:
whether any budget enforcement logic changed between v1.81.0 and v1.82.3
whether common_checks() / auth path changes may cause budget checks to be skipped
whether this is a known issue in v1.82.3
Logs / request samples
We can provide request/response samples and server logs if needed.

### Steps to Reproduce

Steps to reproduce
In the LiteLLM UI, create an internal user that does not belong to any team
set the user's max_budget to 0.1
do not set reset budget
Create a key for that internal user
set the key's max_budget to 0.05
do not set reset budget
Configure this key in OpenClaw and use it once every minute
After around 5 minutes, the total spend reaches about 0.5
Observe that requests are still allowed and no budget enforcement is triggered

### Relevant log output

```shell