Routing Around Provider 402s and Deprecations at the Model Gateway

When a model provider hits a billing wall or silently archives an endpoint, your pipeline should not drop half a page on the floor.

Cerebras hit a billing wall, returning HTTP 402 on every call, while zai-glm-4.7 was archived by its provider with an HTTP 404. Five pipeline stages went dark simultaneously. Because the Gemini viewer kept running, pages arrived with key points rendered and empty space after them.

The immediate instinct during provider failures is often credential rotation. That instinct was useless here. A bad key returns HTTP 401. Both keys authenticated cleanly and returned HTTP 402. The limit was enforced at the account level, so generating new API keys inside the deployment changed nothing.

Treating model endpoints as hard dependencies turns account limits and upstream deprecations into immediate pipeline outages.

Request -> Model Gateway Router
             |
             +--> Primary Provider (402/404) [Failed]
             |
             +--> Fallback Provider (Gemini-class) [200 OK]

The fix was handling this at the router level. When a provider fails with an error like 402 or 404, the gateway catches the failure and routes the alias to a working model class instead of failing the pipeline stage.

A provider outage changes character entirely under this pattern. A Gemini-class fallback might be slower and carry a higher token cost, but the pipeline stage completes. Slower and pricier answers preserve downstream features; hard failures leave users with half-rendered pages.

Check how your gateway handles provider-level failures: if an upstream returns an unexpected 402 or 404, does it crash the stage, or does it automatically route the alias to an active fallback?