fix(usage_manager): 🐛 prevent stale API responses from resetting quota count (#75)

[b3nw]

Summary

• Prevents stale API responses (returning remainingFraction: 1.0) from resetting local quota tracking to 0
• Uses max(current_count, used_requests) to ensure the API can only increase our count, never decrease it
• Applied fix to both primary model and grouped models to maintain state consistency

Problem

When background refresh syncs with the API and receives a cached/stale response showing 100% remaining, the calculated used_requests becomes 0. The previous code unconditionally overwrote local tracking with this value, wiping out accurate request counts.

Solution

The API can only increase our count (if we missed requests), never decrease it. This prevents stale cache responses from corrupting local state while still allowing the API to correct our count upward if needed.

Fixes #75

---

Important

Fixes stale API responses resetting quota count to 0 in update_quota_baseline() by using max() to ensure the count only increases.

• Behavior:
  • Fixes stale API responses resetting quota count to 0 in update_quota_baseline() in usage_manager.py.
  • Uses max(current_count, used_requests) to ensure API can only increase count, not decrease it.
  • Applies fix to both primary and grouped models for consistency.
• Misc:
  • Updates quota_display to use synced_count instead of used_requests.

^{This description was created by for f663c45. You can customize this summary. It will automatically update as commits are pushed.}

[mirrobot-agent]

I'm starting my review of the quota reset bug fix in usage_manager.py. I'll be checking if the use of max() correctly handles stale API responses while still allowing legitimate count updates.

[mirrobot-agent]

Overall Assessment

The fix for the quota reset bug (#75) is solid and correctly addresses the issue where stale API responses could reset the local request count to zero. By using max(current_count, used_requests), the UsageManager now ensures that local tracking only ever moves toward authority or increases, preventing accidental over-usage due to cached/stale API data.

Architectural Feedback

The implementation is consistent with the existing quota group logic. Using max() is a safe and effective defensive programming pattern here. Since authoritative resets of the request_count are still managed by local window timers and the _reset_model_data method, this change correctly protects against transient state corruption without interfering with legitimate quota resets.

Key Suggestions

None. The implementation is clean and directly solves the reported issue.

Questions for the Author

None.

This review was generated by an AI assistant.

[Mirrowel]

Actually, API can also increase too. I hit 0% quota remaining multiple times without hitting an API error. So API reporting can also increase. @b3nw

[Mirrowel]

Gonna look at possible solutions though. Maybe just by tightening counting locally. I think this needs a more complex system as we can't rely on the API anymore.