Bug: LLM router progressively degrades throughout session — reasoning, agentic, quick all fail until app restart #5503

Summary

LLM access through the router degrades progressively throughout the day across all model tiers — reasoning, agentic, quick — until total model failure. The session starts functional but deteriorates to a state where no model is reachable and the app surfaces generic errors with no actionable information.

Problem

Degradation follows a consistent pattern within a single session:

Stage 1 — Individual model tiers go down:

another background task failed because the reasoning-v1 model is still temporarily unavailable.

looks like agentic-v1 is also down right now.

Stage 2 — Total model failure across all tiers:

• Switching to reasoning model: The selected model isn't available on your provider. Check your model settings.
• Switching to quick model: The selected model isn't available on your provider. Check your model settings.
• No model tier is reachable.

Stage 3 — App-level failure:

Something went wrong. Please try again. This error has been reported. You can also report it on Discord.

Secondary effects during the outage:

• Agent cannot write files to the workspace (background tool calls fail).
• Agent cannot complete tasks and surfaces repeated apologies instead of actionable status.
• No model-availability status surface in the UI — users must discover the failure by attempting a chat turn and hitting a generic error.

Root cause (suspected)

This is a router/provider-side availability issue, not a user misconfiguration:

• The degradation is progressive (not an instant all-or-nothing failure), suggesting provider rate limits, quota exhaustion, or a backend session/token that expires and is not refreshed.
• It affects multiple tiers simultaneously (reasoning-v1, agentic-v1, quick), pointing to a shared upstream dependency (the router itself, a provider credential, or a backend session) rather than a single model being down.
• The error The selected model isn't available on your provider is the same error returned when a model is not configured — but here the models were working earlier in the session, so it is a runtime availability failure being surfaced as a misleading configuration error.
• An app restart resets the session state and restores access, which is consistent with a credential/token expiry or leaked rate-limit state that is not automatically refreshed.

Reproduction

1. Start a session and use the agent normally across multiple tasks.
2. Observe: after extended use (hours), background tasks begin failing with reasoning-v1 temporarily unavailable.
3. Additional tiers (agentic-v1) follow.
4. Switching model tiers manually produces The selected model isn't available on your provider.
5. App eventually surfaces generic Something went wrong with no further detail.
6. Restarting the app restores access.

Impact

• Users lose access to all LLM functionality mid-session with no warning and no recovery path short of a full app restart.
• In-progress tasks and agent plans are abandoned.
• Generic error messages (check your model settings) mislead users into thinking they have a misconfiguration when the issue is a server-side availability failure.

Solution

• Identify what state expires or degrades over a long session (provider credential, router token, rate-limit bucket) and implement automatic refresh before failure occurs.
• Distinguish between "model not configured" and "model temporarily unavailable" in error messaging — these are different conditions and should surface differently to the user.
• Add a model-availability status indicator so users know when a tier is degraded without having to attempt a turn and hit a generic error.
• Implement automatic retry / tier fallback when a model is temporarily unavailable rather than surfacing the failure to the user on every turn.
• Log the specific upstream error that triggers temporarily unavailable so the root cause is diagnosable from logs rather than guessed from user reports.

Acceptance criteria

• A session running for multiple hours does not progressively lose model access.
• If a model tier becomes temporarily unavailable, the app automatically retries or falls back to an available tier rather than failing the turn.
• The selected model isn't available on your provider is not shown when the issue is a transient availability failure, not a misconfiguration.
• A model-availability degradation is surfaced in the UI (status indicator or notification) before the user hits a failed turn.
• Logs capture the specific upstream error for each unavailability event.