fix(web,desktop): Fast runs on Luke's Anthropic key alone; an account's own key is refused before any request, and Anthropic refusing fast mode reads as that
Cause
Dean's Fast agent after #2239 was 030e05aa (2026-10-13 02:52Z). It ran on a production deploy that contained #2239: that fix had been live since 22:35Z on 10-12 per GitHub Production deployments. The request was correct this time: claude-opus-5-5 with speed: "fast" and the fast-mode beta.
Anthropic refused it with a 429:
This request would exceed your organization's rate limit of 0 fast mode input tokens per minute (model: claude-opus-5-5)
- Whose key: the step ran on Dean's own saved Anthropic key. It was saved 16:09Z on 10-12, before every Fast agent, and it is the only account key in production.
- What the refusal means: fast mode is a research preview that Anthropic grants per organization. Any other organization's key gets a fast limit of 0. Nothing Anthropic offers can say whether a key is admitted without sending a request.
- Luke's own key: no Fast turn in production has ever run on it, so production data can't show whether Luke's organization is admitted.
- The other two Fast agents (aaa372de, 15389820) failed on the old slug bug and never reached this check.
- Retries: the SDK retried the 429 three times, all refused the same way.
Fix (the "Luke's key only" variant Dean chose)
/api/modelsper account. An account that runs a provider on its own key doesn't get that provider's fast versions. Each affected base model carriesfastWithheld: "own-key", and the Fast row (Start menu and Settings › Coding agents) rests with "Fast isn't available on your own API key". Accounts on Luke's key still see Fast.- Fast choice on an account's own key. Start, a model change, and the default's write check the choice against the catalog as that account is offered it, so a withheld Fast choice is refused there. One that still reaches a step (a stored default, or a worker delegated to Fast) is refused in plain words before any request is sent (
fast_own_key). Settings › Coding agents reads the models again when a key is saved or removed on the page, so the Fast row follows the change. - Fast-mode refusal on Luke's key. Anthropic's "rate limit of 0 fast mode" 429 now fails the step as "Fast mode isn't enabled for this Anthropic organization" (
fast_not_enabled), not a generic model error, and it is not retried. If Luke's organization turns out not to be admitted, the agent's end line will say so plainly.
Tests (each fails without the change)
coder-host-model.test.ts: against a scripted Anthropic that answers fast requests with production's 429:- A Fast step on the account's own key is refused before any request.
- A Fast step on Luke's key fails with the fast-mode words.
- Both refusals read as their new failure words.
models-app.test.ts(now on a real dialect): an account with its own Anthropic key reads Opus with no fast version and withfastWithheld. Another account reads the fast version.model-catalog.test.ts: a Fast choice is refused for an account with its own Anthropic key and accepted for one on Luke's key.coding-agents-page.test.ts: saving an Anthropic key on the page reads the models again, and the Fast switch rests saying why.
Goldens: five JSON-Schema goldens under packages/hosted/fixtures/json-schema/ were re-recorded with LUKE_UPDATE_FIXTURES=1. The diff only adds the optional fastWithheld key and the two new failure words. These are desktop IPC answer schemas, not anything a model is shown.
Mac
CI could not verify the Mac UI, and ./scripts/verify.sh was not run: this work was done on a Linux cloud VM. LUKE-159 is the manual Mac pass. The desktop change is the Fast row's resting text plus two failure end lines. ./scripts/check.sh exits 0.
🤖 Generated with Claude Code