[Bug]: /customer/update silently drops budget_duration when creating new budget for end-user without existing budget

[impr3ssi0n]

Check for existing issues

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

What happened?

When calling POST /customer/update on an end-user that has no existing budget (budget_id=null, e.g. after the budget was deleted via /budget/delete which triggers FK ON DELETE SET NULL), and the request includes both max_budget and budget_duration, a new budget row is created in LiteLLM_BudgetTable, but budget_duration and budget_reset_at are silently set to null. Only max_budget is persisted on the new budget row.

The end-user appears to have a budget (budget_id is set, litellm_budget_table.max_budget is set), but the reset period is missing — so reset_budget_job never resets spend for this budget, and the customer effectively has a one-time non-resetting cap.

What did you expect to happen?

When /customer/update creates a new budget (because end_user_budget_table is None), it should persist budget_duration and compute budget_reset_at — exactly like /budget/new does (budget_management_endpoints.py:86-87):

if budget_obj.budget_reset_at is None and budget_obj.budget_duration is not None:
    budget_obj.budget_reset_at = get_budget_reset_time(budget_duration=budget_obj.budget_duration)

Currently customer_endpoints.py (lines ~596-608) calls BudgetRepository(prisma_client).table.create(data=budget_table_data) directly without computing budget_reset_at from budget_duration, so both fields end up as null in the DB.

Steps to Reproduce

Setup: end-user must exist but have budget_id=null. Either create a fresh end-user with no budget, or delete its budget first.

# 1. Create end-user (skip if already exists)
curl -X POST "https://your-proxy.example.com/customer/new" \
  -H "Authorization: Bearer sk-xxxx" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "test-bug-repro@example.com"}'

# 2. Update end-user with max_budget + budget_duration (user has no existing budget)
curl -X POST "https://your-proxy.example.com/customer/update" \
  -H "Authorization: Bearer sk-xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "test-bug-repro@example.com",
    "max_budget": 50.0,
    "budget_duration": "1mo"
  }'

# 3. Fetch customer info — inspect litellm_budget_table
curl "https://your-proxy.example.com/customer/info?end_user_id=test-bug-repro@example.com" \
  -H "Authorization: Bearer sk-xxxx"

Actual result (step 3):

{
  "user_id": "test-bug-repro@example.com",
  "litellm_budget_table": {
    "budget_id": "69ec4697-4577-400e-9192-edeba7685837",
    "max_budget": 50.0,
    "budget_duration": null,
    "budget_reset_at": null
  }
}

Expected result:

{
  "user_id": "test-bug-repro@example.com",
  "litellm_budget_table": {
    "budget_id": "...",
    "max_budget": 50.0,
    "budget_duration": "1mo",
    "budget_reset_at": "2026-08-01T00:00:00.000Z"
  }
}

Relevant log output

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.90

Twitter / LinkedIn details

No response

[ebarkhordar]

The symptom reproduces, but the drop happens one level earlier than customer_endpoints.py:596-608, and that changes what the fix has to be.

/customer/update binds to UpdateCustomerRequest (litellm/proxy/_types.py:1722), which does not declare budget_duration at all. Its base LiteLLMPydanticObjectBase (litellm/types/llms/base.py:7) sets model_config = ConfigDict(protected_namespaces=()) with no extra="allow", so pydantic v2's default extra="ignore" applies and the field is discarded at request parsing. update_end_user then builds data_json from data.json() at customer_endpoints.py:541, so budget_duration is already gone before non_default_values and budget_table_data are built.

Executed at HEAD 5d4c4d0 in a clean container (python:3.12-slim, dependencies from the released wheel with the HEAD tree ahead of it on sys.path, imported from /build/litellm/proxy/_types.py), using your exact request body:

declared fields: ['alias', 'allowed_model_region', 'blocked', 'budget_id', 'default_model', 'max_budget', 'object_permission', 'user_id']
model_config extra = <unset -> pydantic default 'ignore'>
data.json() -> {'user_id': 'test-bug-repro@example.com', 'alias': None, 'blocked': False, 'max_budget': 50.0, 'budget_id': None, 'allowed_model_region': None, 'default_model': None, 'object_permission': None}
non_default_values -> {'user_id': 'test-bug-repro@example.com', 'max_budget': 50.0}

budget_duration survived request parsing: False
budget_duration reaches budget_table_data: False

That matches what you saw in the DB: max_budget persisted, budget_duration and budget_reset_at null.

The consequence for the fix is the part worth flagging. Adding the budget_reset_at computation at customer_endpoints.py:596-608 on its own will not change the outcome, because budget_duration is never in budget_table_data to compute from. budget_table_data is built once at :575-582, before the create/update branch, so the same applies to the else branch: raising the duration on an already existing budget through /customer/update cannot work either. Accepting the field on UpdateCustomerRequest looks necessary before the reset_at change does anything.

Whether it should be accepted there is a call for the maintainers rather than me. /customer/new takes it (BudgetNewRequest, _types.py:1649) and documents it in its docstring, while the /customer/update docstring does not list it, so the asymmetry may be deliberate and the intended path may be /budget/new plus budget_id. I did not stand up a proxy and a database, so the DB-level result stays yours and not mine; what I measured is the request-parsing drop.

Written with AI assistance. The output above was run at 5d4c4d0.