8 views
-/https://github.com/berriai/litellm/issues/31934
GitHub · issue

#31934 [Bug]: Projected limit alerting ignores budget reset period (daily/weekly/monthly)

  • State: open
  • Author: @nht1206
  • Labels: bug, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

When a budget is configured to reset daily (e.g. budget_duration: "1d"), the `projected_exceeded_date` still calculates based on days remaining in the month, not the current day. This causes misleading alerts that show the budget will be exceeded on a day in the future, when in reality the budget resets at midnight.

### Steps to Reproduce

1. Creates a key with a daily reset period and a budget of $10 2. Configure alerting (Slack) to receive `projected_limit_exceeded` alerts 3. Make API requests using the generated key to accumulate spend 4. Observe the alert

### Relevant log output

```shell

```

### What part of LiteLLM is this about?

Proxy

### What LiteLLM version are you on ?

v1.85.1

### Twitter / LinkedIn details

_No response_

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (4 events)
#0 of 0 · 31d18h46m34s ago — entered · #import:https:::github.com:berriai:litellm post #2090
The right issue spans multiple proxy routes, routing propagation, provider selection, and identifier preprocessing, requiring broader code tracing and regression coverage. The left issue is a comparatively localized budget-period calculation correction.
The left issue is harder because it introduces a new external authentication and token-lifecycle integration, including secure credential handling, refresh behavior, provider plumbing, compatibility coverage, and broader testing. The right issue is comparatively localized to correcting reset-period date calculations and validating alerting behavior.
The left issue requires aligning end-user accounting with configurable reset semantics across persistence, authorization checks, period boundaries, and regression coverage. The right issue is narrower: correcting the period used by projected-alert date arithmetic and validating alert behavior.
#0 of 0 · 31d18h19m35s ago — current · #import:https:::github.com:berriai:litellm post #2518
The left item has no actionable specification, so its scope, dependencies, and acceptance criteria are undefined, creating substantially higher discovery and implementation risk. The right item appears bounded to correcting reset-period date calculations and related alerting tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search