fix(auth): return 429 instead of 503 when disabled accounts mix with cooldown accounts

[ZHOUKAILIAN]

Problem

When an auth pool contains both permanently-blocked accounts (disabled or expired tokens) and temporarily-cooldown accounts (rate-limited), the selector returns 503 auth_unavailable instead of 429 model_cooldown.

Root cause

The old condition in all 4 selection paths:

if cooldownCount == len(auths) && !earliest.IsZero() {
    return 429 // model_cooldown
}
return 503 // auth_unavailable

This only returns 429 when ALL auths are in cooldown. With disabled accounts in the pool, cooldownCount can never equal len(auths), so it always falls through to 503 — even though the cooldown accounts will recover after their cooldown expires.

Real-world scenario

• 18 accounts total: 12 disabled (expired tokens), 6 healthy but rate-limited (429)
• Round-robin hits the 6 healthy accounts until they're all rate-limited
• Cooldown represents "recoverable" state but the 503 is fatal
• Client sees 503 and gives up, instead of 429 with Retry-After

Fix

Track permanently-blocked count (disabled + non-cooldown blocked) separately from cooldown count. When all non-permanently-blocked accounts are in cooldown, return 429 model_cooldown because they will recover.

recoverableCount := len(auths) - permanentlyBlocked
if cooldownCount > 0 && cooldownCount == recoverableCount && !earliest.IsZero() {
    return 429 // model_cooldown with Retry-After header
}
return 503 // auth_unavailable (only when truly no auth can recover)

Files changed

File	Function	Change
selector.go	getAvailableAuths + collectAvailableByPriority	Track permanentlyBlocked, use recoverableCount
conductor.go	availableAuthsForRouteModel	Same pattern
scheduler.go	unavailableErrorLocked + mixedUnavailableErrorLocked	Same pattern
scheduler.go	availabilitySummaryLocked	Count disabled+blocked states

All existing tests pass.

Test plan

• go test ./sdk/cliproxy/auth/... — all pass
• go test ./internal/runtime/executor/... — all pass
• go test ./sdk/api/handlers/... — all pass

🤖 Generated with Claude Code

[github-actions]

This pull request targeted main.

The base branch has been automatically changed to dev.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 70aa8dd00b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid classifying transient blocks as permanent cooldown-exempt

This branch counts every non-blockReasonCooldown auth as permanentlyBlocked, but isAuthBlockedForModel returns blockReasonOther for temporary outages with a future retry (for example Unavailable=true with NextRetryAfter and Quota.Exceeded=false in selector.go). With a mixed pool (e.g., one 429 cooldown auth plus one transient 503 auth), recoverableCount becomes 1 and the code now returns model_cooldown (429) even though not all credentials are cooling down. That misclassifies the failure mode, emits an inaccurate "All credentials ... are cooling down" message, and can drive incorrect client retry/backoff behavior; only truly permanent states (like disabled) should be excluded from the cooldown quorum.

Useful? React with 👍 / 👎.

[ZHOUKAILIAN]

Good catch, thanks! Fixed in c69dc41.

The updated logic now only excludes blockReasonDisabled / scheduledStateDisabled from the cooldown quorum. blockReasonOther (transient 503s, 401s with future retry) still counts toward the total, so they must genuinely transition to cooldown before the quorum triggers 429.

[gemini-code-assist]

Code Review

This pull request improves the error reporting logic for authentication availability by introducing a 'permanentlyBlocked' counter to distinguish between auths in temporary cooldown and those that are disabled or blocked. This change ensures that a 429 (model_cooldown) error is correctly returned when all recoverable auths are in cooldown, preventing incorrect 503 (auth_unavailable) errors in mixed-state pools. I have no feedback to provide as there were no review comments to evaluate.

[ZHOUKAILIAN]

Good catch, thanks! Fixed in c69dc41.

The updated logic now only excludes blockReasonDisabled / scheduledStateDisabled from the cooldown quorum. blockReasonOther (transient 503s, 401s with future retry) still counts toward the total, so they must genuinely transition to cooldown before the quorum triggers 429.

Updated scenarios:

Pool	disabled	cooldown	transient-other	recoverable	Result
12 disabled + 6 429-cooldown	12	6	0	6	6==6 → 429
1 429-cooldown + 1 503-transient	0	1	1	18	1≠18 → 503