[shipsfromrio]

⚠️ base-red inherited: #15306

Addresses the queue stall reported in #16442, for every RetryInfo wait longer than the queue
budget: the 1104 s and 3009 s waits there, and the 86399s Gemini sends for an exhausted daily
quota. The failure-path gaps #16442 also describes stay open; see Notes.

Problem

A 429 body that names its own retry froze that key's limiter for the whole wait, while the router
heard about it for 3 s. updateFromResponseBody empties the key's reservoir until the stated wait
ends. The failure path does record a model lockout for the 429, whatever the generic lockout
setting, but, as #16442 traces, only at the API-key base cooldown of 3 s, because it does not read
error.details[].retryDelay. So 3 s later the router picks the frozen key again. Every dispatch
sits out requestQueue.maxWaitMs (30 s by default), fails as a local 503
Request exceeded queue budget, and only then falls back. Ten frozen keys ahead of the next working
target burned the 300 s combo timeout without one upstream call.

Measured on one production combo on 3.8.51, 2026-10-06 → 2026-10-12:

• 7,479 failed vs 915 successful combo requests, almost all Combo global timeout (300000ms).
• Between 02:08 and 16:46 UTC on 2026-10-12, 4,136 of 4,790 attempts to gemini-3.6-flash inside
  the combo were local queue 503s (p50 30,085 ms); only 86 came back as upstream 429s.
• Of 646 body-stated waits Gemini sent between 2026-10-09 and 2026-10-12, 488 were longer than 1 h,
  88 between 31 s and 1 h, and 70 at or under 30 s.

Fix

• updateFromResponseBody: a 429 that carries a typed Google RetryInfo detail whose
  retryDelay is longer than the connection's maxWaitMs now locks the model on that connection.
  This applies when the key's limiter is already scoped to the model (getLimiterKey: gemini and
  github per model, antigravity per quota family, codex per model scope).
  • The lock uses lockModel, which keys those same scopes (getModelLockKey), so it covers
    what the pause covered. The limiter is left unpaused.
  • Antigravity is the one exception. Its limiter is per quota family, but the lock goes on the
    exact model (lockExactModel), like its other quota locks (lockModelIfPerModelQuota, the
    core-owned quota state). An exhausted Claude model then does not take the whole Claude family
    down on that connection for up to a day.
  • Both lock functions keep the longer of two locks. So when the failure path then records its own
    short lockout (the 3 s in fix(resilience): Gemini 429 RetryInfo (details-only) is dropped before model lockout — 3s lock while the limiter pauses 1104s, requests stall 30s in queue #16442, through recordModelLockoutFailure), the RetryInfo lock
    stands.
  • The wait is read by retryInfoDetailsMs, the reader behind the google_rpc_retry_info
    provenance (now exported from retryAfterJson.ts). That includes its @type check and its
    24 h cap.
  • The name the client asked for is locked too, when an alias resolved it to that model, because
    account selection (and the combo pre-dispatch gate, for targets pinned to the connection) checks
    the requested name.
    • It is locked exactly, with lockExactModel, whose key isModelLocked already checks.
      Through lockModel's quota-family keys, an alias that crosses an antigravity family or a
      codex scope would lock its own family for the whole wait. For example, a gemini-2.5-pro
      alias for claude-sonnet-4-5 would take gemini-2.5-flash down on that connection.
    • chatCore now passes its pre-alias model as a new optional argument. Its end-of-request
      call runs on both legs (applyProviderFailureClassification in the streaming and
      non-streaming handlers).
    • The provider pipeline's call is unchanged, because its requestedModel is already the
      resolved one.
• Everything else keeps pacing the limiter exactly as before.
  • Waits that fit maxWaitMs.
  • Prose hints ("retry after Ns") and untyped or differently typed retryDelay fields: they are
    not authoritative, so they must not turn into a lock that escapes the lockout maxCooldownMs
    cap.
  • Connection-wide limiters: a lock on one model there would let the connection's other models
    through a paused key.
  • Non-429 statuses, and maxWaitMs = 0 (no queue deadline, fix(resilience): allow maxWaitMs=0 as disable sentinel for execution expiration #12902).
  • The feat(sse): learn hard request caps from 429 bodies and pace under them #13895 request-cap path is untouched.
• withRateLimit: when the limiter that the 429 path just rebuilt is paused, and the pause
  outlasts the caller's remaining queue time, the call is turned away at once. It gets the
  queue-timeout code (RATE_LIMIT_QUEUE_TIMEOUT, 503), with the same classification and combo
  fallback as before, instead of waiting that time out. This covers the prose, untyped and
  connection-wide cases above.
• updateFromHeaders: the 429 log no longer says pausing for 60s (the first line of the log
  in fix(resilience): Gemini 429 RetryInfo (details-only) is dropped before model lockout — 3s lock while the limiter pauses 1104s, requests stall 30s in queue #16442). That path evicts the limiter and takes no pause. The log now prints the real
  retry-after, the header as sent when it does not parse to a positive wait, or says there was
  none. That note is built by describeRetryAfter in rateLimitManager/headers.ts, next to
  parseResetTime. Built inline, it took updateFromHeaders to a complexity of 16 (cognitive 18)
  against the limit of 15 in the repository's ESLint rules, a new finding for
  check:complexity-ratchets on a changed file.

The new logic lives in open-sse/services/rateLimitManager/bodyRetryPause.ts. The three test-quiet
log helpers move to rateLimitManager/log.ts unchanged, so the new module logs the same way and
rateLimitManager.ts stays within its frozen size: 1312 → 1319 lines by the check:file-size
count, ceiling 1329. In chatCore.ts the new argument adds a line, and the sibling
updateFromHeaders call moves onto its if line, as the file already does for other one-line
guards: 3935 → 3934 on the branch. release/v3.8.52 now sits exactly at the 3938 ceiling after
#16456, and the merge with it measures 3937, so file-size-baseline.json is untouched.

Why a model lockout

• It is the signal both routers already read, independent of the opt-in generic lockout setting:

  • the combo pre-dispatch gate (open-sse/services/combo/executeTargetGates.ts, isModelLocked)
    for targets pinned to a connection;
  • account selection (src/sse/services/auth.ts, isModelLocked) for every request.

  The lock calls themselves (lockModel, lockExactModel) are unconditional.

• It has the scope the pause had, or a narrower one on antigravity. Other models on the same key
  keep serving where the quota is per model, and so do other keys.

• When every connection for the model is locked, account selection answers allRateLimited with
  a model-scoped cooldown ("getProviderCredentials reports allRateLimited when every account is
  model-locked" in tests/unit/sse-auth.test.ts pins this), and the cooldown-aware retry does not
  sit out a wait longer than maxRetryWaitMs. The request, or the combo target, fails at once
  instead of costing 30 s and a 503 per key.

• It is visible (GET /api/rate-limits lists model lockouts) and operators can clear it.
  POST /api/resilience/reset clears model lockouts, and a successful request on the same name
  clears its lock (clearModelLock in src/sse/handlers/chat.ts), like every other model lock.
  The frozen reservoir showed up nowhere and no reset touched it. Only a rebuilt limiter ended it
  early: a restart, a settings or override change, a protection toggle, or a later 429 with
  headers on the same limiter, which the frozen queue itself kept from happening. That is also why
  the lock does not come with a pause: a reset would clear the lock and leave an invisible pause
  behind.

Why the fail-fast cannot turn away a request the queue would serve

• The pause is recorded per limiter instance, and only on a limiter built for it. The recorded
  end is taken before the build, because Bottleneck starts the refresh clock in the datastore
  constructor (_lastReservoirRefresh) and the heartbeat patch keeps that anchor. So the recorded
  end never runs past the real refill, even when the build is slow. On an older limiter the refill
  can come sooner, so nothing is recorded there.
• Any later update to the reservoir or its refresh schedule forgets the record. That covers
  header learning, settings and override changes, and a relaxed limiter never fails calls fast.
• Guards cover all three. A short pause still holds the call and then serves it. A pause relaxed
  by later headers no longer fails calls fast. A limiter build that stalls for 2.5 s does not stop a
  call with 3 s of budget from being served by the refill 1.5 s later.

Tests

tests/unit/rate-limit-long-body-retry-lockout.test.ts (new, end to end through the manager, 13
cases; it clears RATE_LIMIT_MAX_WAIT_MS at load, because that variable moves the default 30 s
queue budget the cases assume):

#	Case	Base 7f3cbb046b	This PR
1	A 429 with a daily-quota RetryInfo (86399s) locks the model on that connection, leaves the key's other models free, and the next call on the key is served at once	✖ no lock (isModelLocked is false)	✔
2	The lock never outlasts the 24 h retry-hint ceiling (999999s)	✖ no lock	✔
3	A 20 s RetryInfo fits the 30 s queue budget, so the limiter pauses; a caller with 5 s left is turned away at once	✖ waited 5015 ms	✔
4	With no model to lock, a long pause still turns callers away at once	✖ waited 5010 ms	✔
5	A prose hint never becomes a lock; its pause turns callers away at once	✖ waited 5011 ms	✔
6	A retryDelay outside a typed RetryInfo detail never becomes a lock; its pause turns callers away at once	✖ waited 5017 ms	✔
7	On a connection-wide limiter (openai) a long RetryInfo locks nothing and keeps the pause, so another model on the connection is turned away at once	✖ waited 5004 ms	✔
8	The requested (alias) name is locked with the resolved model	✖ not locked	✔
9	The sequence in #16442: a 1104s RetryInfo, then the failure path's own 3 s lockout (recordModelLockoutFailure); the lock still lasts the RetryInfo wait	✖ only the 3 s lock ("the lockout shrank to 3000ms")	✔
10	Guard: a short pause inside the budget holds the call and then serves it	✔	✔
11	Guard: once the reservoir is relaxed, a recorded pause no longer fails calls fast	✔	✔
12	Guard: the per-target deadline (abort signal) ends a wait behind a pause	✔	✔
13	Guard: a limiter build that stalls 2.5 s does not turn away a call the refill serves 1.5 s later	✔	✔

The base column is this file run against a checkout of 7f3cbb046b (9 fail, 4 pass); with this PR
all 13 pass. The four guards pass on both sides on purpose: they pin the behaviour the fix must not
break.

tests/unit/rate-limit-body-retry-pause.test.ts (new, 7 timer-free cases with an injected clock):

• the fail-fast comparison;
• what forgets a recorded pause;
• the full lockout decision table: status, scope, budget, maxWaitMs = 0, prose, untyped and
  other-typed retryDelay, and the 24 h cap;
• the requested-name lock;
• the requested-name lock is exact: an antigravity alias across quota families and a codex alias
  across scopes leave their own family serving (through lockModel this case fails);
• on antigravity and agy the model itself is locked exactly, so the rest of its quota family keeps
  serving (through lockModel this case fails);
• retryInfoDelayMs.

It imports the new module, so it cannot run on the base.

tests/unit/ratelimitmanager-headers-split.test.ts (one new case) pins describeRetryAfter: a
parsed wait, a zero or unparsable header as sent, and no header. This case was not run on this
machine, CI runs it; its six inputs were checked by calling the function directly.

Both new test files import accountFallback.ts, a mutated module, so they are listed in
stryker.conf.json tap.testFiles, as check:mutation-test-coverage --strict requires. The
gate's other entries on 9ecddd15a1 (12 tests across 5 modules) predate this branch.

Also run locally (Windows 11, Node 24.19.0):

• npm run typecheck:core: clean on the branch, on its merge with 47688ba5ea, and on its merge
  with 9ecddd15a1, the current release/v3.8.52 tip.
• ESLint with config/quality/eslint-suppressions.json, and Prettier, on the changed sources and
  tests: clean. The pre-commit hooks passed on every commit (lint-staged, docs-sync,
  check:any-budget:t11, check:tracked-artifacts, check:ai-attribution).
• node scripts/check/check-cycles.mjs --ratchet: 14 cycles, at the ceiling of 14.
• npm run check:file-size, on the branch and on its merges with 47688ba5ea and 9ecddd15a1:
  the only violation is open-sse/services/combo/executeTargetAttempt.ts (1288 > 1284). refactor(combo): route strategy-specific branching through a typed strategy registry (rail 3.8.52 R0.4a) #16206
  grew it from 1284 without a baseline entry; this PR does not touch it. On the merge with
  9ecddd15a1, chatCore.ts measures 3937 (ceiling 3938) and rateLimitManager.ts 1319
  (ceiling 1329).
• npm run check:docs-all: pass.
• On the merge with 47688ba5ea, the 28 neighbouring unit files (list below) plus
  combo-model-lock-pre-dispatch-wait-16319, gemini-deprecated-model-lockout and
  combo-priority-all-circuit-open: 315 of 317 pass. One failure is rate-limit-learned-cap-13594,
  whose after() hook cannot delete its temp SQLite directory on Windows (EPERM), the same on the
  base. The other is a wall-clock setup step in rate-limit-manager, described below.
• The same 31 files on the merge of de911917aa (the head before the describeRetryAfter commit)
  with 9ecddd15a1, which includes fix(sse): honor Google RPC ErrorInfo quota-reset metadata as an upstream retry hint #16529: 326 of 327 pass, including the cases fix(sse): honor Google RPC ErrorInfo quota-reset metadata as an upstream retry hint #16529 added to
  account-fallback-retry-after-json and classify429. The one failure is again the after()
  hook of rate-limit-learned-cap-13594 (EPERM). rate-limit-manager passed all 19 tests, then
  again kept its process alive until a 300 s cap.
• rate-limit-manager-queue-bound, "timeout before dispatch (<80ms not 200ms)", is a wall-clock
  bound: a 30 ms budget must reject in under 80 ms. On this busy Windows machine it went over in
  three of this branch's long runs (120, 146 and 131 ms) and passed in the others, including the
  final one. To tell the diff from the load, a replica of that case (same imports and hooks,
  printing the measured time) ran 40 times on each side, alternating base and branch, each run in
  a fresh process: median 40 vs 39 ms, p90 47 vs 49 ms, and the base went over 80 ms once
  (144 ms), the branch never (max 71 ms). This change adds only a synchronous WeakMap lookup to
  that path.
• combo-model-lock-pre-dispatch-wait-16319 (from fix(resilience): wait out a short model lock instead of failing a combo instantly (#16319) #16360) bounds its quota-lock case at 1000 ms of
  wall clock. It went over once (3629 ms) inside a 14-minute run of ten files on the merge with
  e2d5747872. Alone, alternating the merge with 47688ba5ea and that tip in fresh processes,
  three runs a side, all six passed: 37–151 ms on the merge, 53–232 ms on the tip.
• rate-limit-manager, "idle-capacity watchdog preserves a real Bottleneck minTime wait", polls
  every 5 ms, for at most 1 s, for the job to sit in Bottleneck's 100 ms minTime wait. In the
  20-minute run above it never saw it (Bottleneck did not place the minTime-delayed job in RUNNING). It passed in this branch's four earlier long runs, and alone on both sides (1145 ms on
  the merge, 666 ms on the tip). This change adds no timer, and the only line it adds to
  withRateLimit returns at once when no body pause is recorded.
• On this Windows machine, rate-limit-manager.test.ts keeps its process alive for minutes after
  all 19 tests pass, with or without this branch. Run alone, it hit a 240 s cap on the tip
  47688ba5ea and on the merge with it, and a 200 s cap on the merge with e2d5747872.

The 28 unit files

antigravity-429-quota-cooldown, bug-7940-gemini-retrydelay, chat-rate-limit-body-lock,
classify429, combo-model-lockout-honors-reset-1308, provider-execution-pipeline,
rate-limit-enhanced, rate-limit-learned-cap-13594, rate-limit-long-body-retry-lockout,
rate-limit-body-retry-pause, rate-limit-manager-queue-bound, rate-limit-manager,
rate-limit-overrides-restart, rate-limit-queue-context, rate-limit-remaining-budget,
rateLimitManager-idle-eviction, rateLimitManager-update-sequencing,
ratelimit-reservoir-refresh, ratelimitmanager-headers-split, muse-code-oauth,
upstream-status-restatement, account-fallback-retry-after-json, chatcore-stream-error-result,
chatcore-quota-share-consumption, chatcore-streaming-quota-share,
combo-quota-exhaustion-only-fallback, repro-7387-sticky-quota-exhausted,
rate-limit-abandoned-queued-job (all under tests/unit/, --test-concurrency=1).

Notes

• Complementary to fix(resilience): wait out a short model lock instead of failing a combo instantly (#16319) #16360 (merged after this branch was cut), which waits out a short model
  lock in a combo.
  • That wait, and the retry_after it adds to the terminal response, apply only to locks whose
    reason is on its transient allow-list (isTransientComboCooldownReason: rate_limit,
    rate_limited, transient, overloaded, server_error, circuit_open).
  • The lock here carries rate_limit_exceeded, the reason parseRetryAfterFromBody reports. When
    the failure path's 3 s rate_limited lock follows it, the reason stays: both lock functions keep
    the longer lock, and getModelLockoutInfo reports the one with the most time left. So fix(resilience): wait out a short model lock instead of failing a combo instantly (#16319) #16360
    neither waits out nor advertises a RetryInfo lock, whatever its length.
  • A single pinned target locked this way still answers the hint-less 503 ALL_TARGETS_SKIPPED,
    as it does for a quota lock. Whether a RetryInfo lock inside fix(resilience): wait out a short model lock instead of failing a combo instantly (#16319) #16360's 90 s ceiling
    (comboCooldownWait.maxWaitMs) should be waited out instead is a follow-up.
  • fix(resilience): wait out a short model lock instead of failing a combo instantly (#16319) #16360 edits another section of docs/architecture/RESILIENCE_GUIDE.md, and fix(chat): expose route metadata on pre-dispatch errors #16456 another
    part of chatCore.ts. Neither overlaps the hunks here.
• fix(sse): honor Google RPC ErrorInfo quota-reset metadata as an upstream retry hint #16529 (also merged after this branch was cut):
  • Its compound durations (2h7m23s) reach both readers used here. The limiter pause
    (parseRetryAfterFromBody) and the lock (retryInfoDetailsMs) both parse through
    parseDelayString, so they see the same value. A typed RetryInfo with
    retryDelay: "2h7m23s", which the base read as 2 s, now locks the model for 2 h 7 min 23 s.
  • Its ErrorInfo quota-reset metadata does not reach this path, because
    parseRetryAfterFromBody reads details[] only for retryDelay fields. An ErrorInfo-only
    429 therefore takes neither the pause nor the lock from that detail; a prose hint in its message
    is handled as before. When a body carries both details, the lock lasts the RetryInfo wait.
  • A throwaway test on the merge with 9ecddd15a1 checked the compound and ErrorInfo cases
    (4 of 4 pass). It is not part of this PR, because the branch predates fix(sse): honor Google RPC ErrorInfo quota-reset metadata as an upstream retry hint #16529.
• fix(resilience): Gemini 429 RetryInfo (details-only) is dropped before model lockout — 3s lock while the limiter pauses 1104s, requests stall 30s in queue #16442. This PR covers its stall for RetryInfo waits past the queue budget. For a typed
  RetryInfo, it also covers its point (b): a limiter pause longer than the model lockout should
  count for target eligibility. Still open there:
  • parseUpstreamError() and checkFallbackError() do not read error.details[].retryDelay.
    The failure path's own lockout therefore stays at the base cooldown for a details-only
    RetryInfo, and its log line still prints that base (3 s) next to this PR's 🔒 line. Past
    the queue budget, the lock above covers the key; inside it, the limiter paces the key.
  • The Gemini 429 block in checkFallbackError() returns before the operator providerErrorRules
    lookup, so no rule can lengthen a Gemini 429 lockout.
  • A synthesized queue-budget 503 is not recorded as a lockout (its point (a)). With this PR, that
    503 comes at once when the recorded pause outlasts the caller's queue time, instead of after
    maxWaitMs.
• Not in this PR:
  • gemini-3.6-flash is still missing from open-sse/config/geminiRateLimits.json, so the RPD
    classifier cannot tell its daily quota from a per-minute limit.
  • A combo deadline reaches withRateLimit only as an abort signal, so the fail-fast compares
    against the queue budget, not against the time left in the combo.
  • A long RetryInfo on a non-429 status keeps the old pause.
  • The decision still runs only when parseRetryAfterFromBody finds a positive wait, as the
    pause always has. A body whose first retryDelay is invalid or zero therefore hides a later
    typed RetryInfo from both, on the base as here. Google's 429 bodies carry a single
    RetryInfo, so this stays as it was to keep the change to the reported defect.
  • The combo gate checks target.connectionId || "", so an unpinned target relies on account
    selection to skip the locked connection. This is existing behaviour for every model lock.
  • parseRetryAfterFromBody has no ceiling, while the typed reader caps at 24 h. A prose,
    untyped or connection-wide retryDelay longer than 24 h therefore still pauses the limiter for
    its full value, as on the base.
  • A background-task redirect reassigns model in chatCore before dispatch, so only the
    degraded model is locked, not the name the client sent. The next request on that name reaches
    the upstream and gets a 429 back, instead of waiting out the queue as on the base.
• Changelog fragment: changelog.d/fixes/0000-429-long-body-retry-lockout.md, with the 0000-
  prefix the other fragments opened before their PR number use.

[shipsfromrio]

CI on 8931826c82, tested as the merge with 9ecddd15a1 (CI 38489565761, Quality Gates 38489565904):

• The 21 cases this PR adds or extends pass, each in one CI unit shard and one fast-path shard. complexity-ratchets now passes (describeRetryAfter, 09a145da6a).
• mutation-test-coverage --strict still fails, on the same 12 unit tests it lists for 9ecddd15a1 alone (Quality Gates push run 38444167890). Eight were missing on 47688ba5ea; codex-reasoning-replay-retry, authz/local-only-bypass-spawn-denylist, request-logger-url-secret-masking and claude-thinking-continuity landed since. The two test files this PR adds are listed (8931826c82). 🔴 Release branch not green: release/v3.8.52 #15306 does not list this gate.
• check:dashboard-typecheck prints the same report here and on the base push run: 196 errors, 86 baselined ones gone, and one new TS2339 in src/app/(dashboard)/dashboard/providers/[id]/components/ConnectionRow.tsx, a file this PR does not touch. The base run also fails file-size ("3 gate(s) failed: file-size mutation-test-coverage check:dashboard-typecheck"); here only the other two fail.
• Every other failing job also fails on 9ecddd15a1's push runs (CI 38444167795, Quality Gates 38444167890): Lint, Docs Sync (Strict), Vitest, Integration Tests (1/2), Unit Tests (2/8) to (8/8), the four fast-path shards and Merge integrity. The unit and fast-path shards fail on the same ten test files on both sides (below). Unit Tests (5/8), (6/8) and (7/8) here run out of heap after the test summary, as (5/8) and (6/8) do on the base.
• Build lost its runner six minutes in, during next build ("The runner has received a shutdown signal"). On the base push run it has not left the queue.

The ten failing unit test files, on both sides

codex-provider-overlay-12782, combo-dispatch-prelude, combo-scoring-inspector, messages-count-tokens-route, model-hidden-dashboard-modality-read, model-test-route, oauth-providers-config, quality-rail-gate-membership, route-explainability, server-owned-tool-loop-flag (all under tests/unit/).

#16528 (@skygunner, Fixes #16442) closes the failure-path gap listed in Notes > #16442. parseUpstreamError reads error.details[].retryDelay, and createErrorResult relays it as Retry-After, so markAccountUnavailable locks the model for the RetryInfo window instead of 3 s. The two PRs complement each other:

• fix(resilience): relay a details-only RetryInfo 429 hint into the model lockout (#16442) #16528 does not touch the limiter. On its own, a long RetryInfo still pauses that connection's queue for the model, and a request that still reaches it (one already queued, or another alias of the same upstream model) can sit out its remaining queue budget and end in a local 503. This PR leaves that queue unpaused past the budget, and fails fast when a recorded pause outlasts the caller's queue time.
• fix(resilience): relay a details-only RetryInfo 429 hint into the model lockout (#16442) #16528 also makes the lock honor a RetryInfo wait inside the queue budget, which this PR leaves to the limiter.
• The two touch no file in common. fix(resilience): relay a details-only RetryInfo 429 hint into the model lockout (#16442) #16528 changes open-sse/utils/error.ts and adds its own test and fragment. This PR only adds an export to retryInfoDetailsMs in retryAfterJson.ts; fix(resilience): relay a details-only RetryInfo 429 hint into the model lockout (#16442) #16528 imports a different function from that module. Both heads merged onto 9ecddd15a1 with git merge-tree: clean. Either can land first.
• With both merged, a details-only RetryInfo 429 on Gemini gets this PR's lock first and the failure path's lock afterwards. When no alias is involved they share a key, and the failure path's window is rounded up to whole seconds, so lockModel normally keeps the later lock and its reason: rate_limited on the usual Gemini 429 path. That reason is on fix(resilience): wait out a short model lock instead of failing a combo instantly (#16319) #16360's transient allow-list. fix(resilience): wait out a short model lock instead of failing a combo instantly (#16319) #16360 would then add retry_after, and could wait out the end of the window once the time left fits its 90 s ceiling. The Notes say fix(resilience): wait out a short model lock instead of failing a combo instantly (#16319) #16360 "neither waits out nor advertises a RetryInfo lock"; that holds only while fix(resilience): relay a details-only RetryInfo 429 hint into the model lockout (#16442) #16528 is out.