Skip to content

v0.9.39 — Sustained-overload failover (529/503)

Choose a tag to compare

View all tags
@bagidea bagidea released this 03 Jul 07:12
v0.9.39
1769cf2

Fail over to Claude when a brain is SUSTAINEDLY overloaded (529/503)

Fixed

  • A sustained provider overload (529 / 503) no longer ends in a raw "API Error: 529". When a non-Claude brain's server is overloaded (common with GLM/Z.AI under load), a one-off hiccup is still left to the built-in retries — but once it's retried several times and the provider is still down, the office now fails that task over to Claude the same way it does for a dead/bad-auth brain, so the work runs instead of stalling. The owner is told it fell over. (429 rate-limit stays a pause/resume case, not a failover.)

The behaviour, by error shape:

  • 401/403 (bad/expired key) → fail over immediately.
  • Dead endpoint (no response) → fail over after 2 tries.
  • 529/503 (overloaded) → fail over after it persists through ~4 retries (a brief blip is retried, not failed over, so we don't burn the Claude fallback on a transient hiccup).
  • 429 (the office's own rate limit) → pause + auto-resume, not fail over.

Daemon change — no shell rebuild. Update via the in-app 🔄 banner or bagidea update.

Assets 7
Loading