fix(fallback): trigger eager fallback on 503/529 provider overload

[pazyork]

(Continuation of #11492 — rebased on main, couldn't reopen the old PR after force-push.)

---

When a provider returns 503/529 (overloaded), Hermes should fall back to another provider. Currently it doesn't — two small things are missing:

1. error_classifier.py: 503/529 doesn't set should_fallback=True
2. run_agent.py: even if it did, the credential-pool check would block fallback (rotation can't fix provider overload)

Fix

1. error_classifier: 503/529 → should_fallback=True (1 line)
2. run_agent: new eager-fallback block for overloaded, after the rate-limit block. Bypasses pool check entirely.

Why a separate block: overloaded isn't a rate limit, and credential rotation can't fix a saturated provider. Separate = zero risk to existing rate-limit/billing logic.

What this does NOT touch

• is_rate_limited tuple — unchanged (still only rate_limit + billing)
• _pool_may_recover_from_rate_limit — unchanged
• Nous rate guard — unchanged
• Compression / context-overflow — unchanged
• All existing fallback and retry paths — preserved

Related

• Fixes [Bug]: Persistent HTTP 529 / “server cluster is currently under high load” errors in Hermes when using MiniMax M2.7 #10210
• Complements fix(error_classifier): classify 'overloaded' message as FailoverReason.overloaded #14055 (message-pattern path vs status-code path)
• Builds on [Feature]: 遇到http 529错误的时候，应该尝试切换成fallback的模型 #11314 (_pool_may_recover_from_rate_limit)

4 files, +27/-1 lines.

[alt-glitch]

Likely duplicate of #11034 — same root cause: 503/529 overloaded errors missing should_fallback=True in error_classifier.py and credential pool guard blocking fallback. #11492 (closed) had same fix. This PR is more comprehensive with the independent overloaded block.

[alt-glitch]

Likely duplicate of #11034

[pazyork]

@alt-glitch same author as #11492 — rebased on main after _pool_may_recover_from_rate_limit landed (#11314). GitHub won't reopen after force-push, so here we are.

Independent block is intentional: overloaded ≠ rate_limit, credential rotation can't fix provider overload. #14055 is complementary (message-pattern path vs status-code path).

[teknium1]

Thanks for this, @pazyork — and for the careful writeup. The underlying bug (overloaded providers not falling back, #10210) was real when you filed, but it's been resolved on current main through the agent-loop refactor, so I'm closing this out.

What changed since the PR:

1. The agent loop moved out of run_agent.py into agent/conversation_loop.py. The run_agent.py lines this PR patches no longer exist in that form.

2. Overload fallback already happens. In conversation_loop.py, FailoverReason.overloaded is treated as a transport failure and triggers _try_activate_fallback() — after a couple of retries, and still respecting _pool_may_recover_from_rate_limit.

On the two specific changes here:

• The classifier one-liner (503/529 → should_fallback=True) wouldn't actually move the needle on the current loop: the eager-fallback decision there derives from the FailoverReason enum directly, not from classified.should_fallback, so that flag isn't read on the overload path.

• The eager-fallback-bypassing-the-pool design conflicts with the direction the codebase deliberately took in "overloaded" server errors classified as rate_limit, exhausting credential pool #14038 / [Feature]: 遇到http 529错误的时候，应该尝试切换成fallback的模型 #11314 / Prefer fallback for Gemini CloudCode rate limits #13636: provider overload usually self-recovers, so we retry first rather than immediately abandoning the provider, and we let the credential pool rotate when it can instead of bypassing it. The "overloaded ≠ rate limit" disambiguation you wanted is implemented (see the 429-overload split in error_classifier.py around the _OVERLOADED_PATTERNS check).

Net: the behavior you were after — a 503/529 provider getting failed over instead of hard-failing — is live on main today, just via the loop's transport-failure path rather than a dedicated eager block. Appreciate the contribution and the clear root-cause analysis.