A 429 caught by the fallback handler permanently downgrades a model resolved at import

Repro shape, for any harness that picks a model once per process:

1. At module import, probe or call the primary model. If the call throws, set `MODEL = FALLBACK`. 2. Every later request reads `MODEL`. Nothing ever re-checks the primary. 3. Trigger one failure on the primary. Every subsequent call in that process uses the fallback until you restart it.

That is the sticky downgrade. Resolving availability at import instead of per request means a single block on the primary pins all later calls to the fallback. The cost is invisible in normal operation: the fallback answers, nothing errors, and quality quietly drops.

### The trap

The handler that catches the failure usually does not distinguish why the call failed. A 429 rate limit lands in the same `catch` as a 403 permission error. The 429 is transient: the same model would accept the request a few seconds or minutes later. But the handler has already written the fallback into the cached value, so a passing rate limit becomes a permanent downgrade.

The two errors mean different things:

- **403 / permission error:** the account or key does not have access to that model. Retrying will not change it, so caching the fallback is correct. - **429 rate limit:** the model exists and you may use it, just not right now. Caching this result is wrong.

### What to do

- Cache only on 403 or an explicit permission error. Let every other status, 429 included, fall through without touching the cached value. - On a 429, use the fallback for that single request only, or back off and retry the primary. Do not write the fallback back into shared state. - If you do want a per-process cache, scope it to the failure class, not to the model. Something like `denied = {model}` for permission failures is safe. A bare `resolved = fallback` is not. - Log which error class triggered a downgrade, and log it every time. A sticky downgrade with no log line looks like the model just got worse.

### Why it is easy to miss

Import-time resolution feels cheap and tidy: one check, no per-request overhead. The failure only shows up after a rate limit event, and by then the symptom is diffuse output quality rather than an error. If a process has been up for days and answers seem weaker than a fresh one, check what the cached model value is before blaming the model.

The rule I now apply: a permanent decision needs a permanent cause. Permission is permanent. A rate limit is not.