Check for existing issues

• I have searched the existing issues

What happened?

When a user makes API calls using a team key (team_id is set), the spend is correctly attributed to the team (LiteLLM_TeamTable.spend). However, the same cost is also written to the user's personal spend record (LiteLLM_UserTable.spend). This means the user's personal spend DB field accumulates all team key spend in addition to personal key spend.

When the user later makes a call with their personal key (team_id = None), the personal budget check in auth_checks.py reads user_object.spend (the polluted DB field) as the fallback_spend, sees total spend ≥ personal budget, and raises BudgetExceededError — even though the user's actual personal key spend is within budget.

Steps to Reproduce

1. Create a user with a personal budget (e.g. max_budget = $200)
2. Add the user to a team; the user makes calls with the team key (accumulates, say, $400 of team spend)
3. The user makes a call with their personal key
4. BudgetExceededError is raised: "Current cost: 411.92, Max budget: 200.0" — even though personal key spend is only ~$11

Root cause

_batch_database_updates() in db_spend_update_writer.py (line 333) calls _update_user_db() unconditionally — it does not pass team_id, and _update_user_db() has no guard to skip the update when the request came from a team key.

Compare _update_team_db() (line 560–565), which correctly short-circuits when team_id is None:

# _update_team_db (correctly guarded)
async def _update_team_db(self, ..., team_id, ...):
    if team_id is None or prisma_client is None:
        return  # skip — not a team key call

# _update_user_db (no guard — the bug)
async def _update_user_db(self, ...,  # no team_id parameter at all
):
    # unconditionally enqueues spend increment for the user
    await self.spend_update_queue.add_update(
        update=SpendUpdateQueueItem(
            entity_type=Litellm_EntityType.USER,
            entity_id=_id,
            response_cost=response_cost,
        )
    )

The budget check in auth_checks.py (line 623–633) is correctly guarded:

# Correctly skips personal budget check for team key calls
if (
    (team_object is None or team_object.team_id is None)  # ← correct guard
    and user_object is not None
    and user_object.max_budget is not None
):
    user_spend = await get_current_spend(
        counter_key=f"spend:user:{user_object.user_id}",
        fallback_spend=user_object.spend or 0.0,  # ← reads polluted DB field
    )
    if user_spend >= user_budget:
        raise litellm.BudgetExceededError(...)

The mismatch between the spend write path (no guard) and the spend check path (correctly guarded) is what causes the bug. The fallback_spend=user_object.spend line reads from the DB field that has been inflated by team key costs, so any time the Redis counter is absent (e.g. after a proxy restart), the inflated DB value is used and triggers a false positive.

Proposed fix

Add team_id as a parameter to _update_user_db() and short-circuit when it is set:

async def _update_user_db(
    self,
    response_cost: Optional[float],
    user_id: Optional[str],
    prisma_client: Optional[PrismaClient],
    user_api_key_cache: DualCache,
    litellm_proxy_budget_name: Optional[str],
    end_user_id: Optional[str] = None,
    team_id: Optional[str] = None,    # new parameter
):
    if team_id is not None:
        return  # team key call — spend is tracked against the team, not the user

And update the caller in _batch_database_updates() (line 333) to pass team_id:

await self._update_user_db(
    response_cost=response_cost,
    user_id=user_id,
    prisma_client=prisma_client,
    user_api_key_cache=user_api_key_cache,
    litellm_proxy_budget_name=litellm_proxy_budget_name,
    end_user_id=end_user_id,
    team_id=team_id,    # pass through
)

Relevant log output

BudgetExceededError: ExceededBudget: LiteLLM Proxy: User=<user_id> over budget.
  Current cost: 411.92, Max budget: 200.0, Reset At: 2026-05-01 00:00:00+00:00

What part of LiteLLM is this about?

Proxy — spend tracking (db_spend_update_writer.py) and budget enforcement (auth_checks.py)

What LiteLLM version are you on?

main @ 09cd7e383e (April 2026)