#13950·OmniRoute

feat(resilience): optional wait-until-reset instead of erroring when all combo candidates hit quota_exhausted

Author: agents-nilsCreated Sep 17, 2026Updated Sep 17, 2026
Labelsenhancementresilience

Problem

Today, when every candidate in a combo has hit quota_exhausted (daily/weekly account limits, not a short transient 429), OmniRoute fails the request immediately. The docs are explicit about this being deliberate: comboCooldownWait "never waits on quota_exhausted (locked until midnight)", and the general waitForCooldown mechanism is capped at a few retries × 30s — nowhere near long enough for an hours/days-long reset window.

This means a long-running agent session (e.g. a coding agent burning through Claude/Codex/Gemini quota) dies mid-task once all accounts in its combo are exhausted, and requires a human to notice and manually restart the session once quota resets — even though OmniRoute already tracks the exact reset time for every connection (GET /api/resilience/model-cooldowns, omniroute resilience cooldowns, omniroute_check_quota).

Feature request

An opt-in setting (default off, to preserve today's fail-fast behavior) that, when all candidates in a combo/request are quota_exhausted with no fallback left, holds the request server-side and retries automatically once the earliest known reset time among the exhausted candidates elapses — instead of returning an error that requires a manual session restart.

Suggested shape, mirroring the existing comboCooldownWait settings block:

"waitForQuotaReset": {
  "enabled": false,
  "maxWaitMs": 21600000,   // e.g. 6h ceiling, configurable
  "onlyWhenAllExhausted": true
}

Nice-to-have: stream a keepalive/progress event while waiting (similar to the existing "surface cooldown-retry progress in the committed keepalive stream" idea in #11694), so long-lived SSE/agent clients don't time out client-side while OmniRoute is holding the request.

Why this instead of just "add more fallback accounts"

More combo candidates helps but doesn't solve it structurally — any finite combo eventually gets to "all exhausted" during a long session, and today that's always a hard failure rather than a bounded wait for a known reset time OmniRoute is already tracking.