[BUG] Claude Desktop (Code tab): fast mode fails silently and the status bar reports "Fast" while every request runs standard

[antonioaraujo664]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code available on this surface (see Version note below)

---

What's Wrong?

In the Claude Desktop app's Code tab, enabling fast mode produces no error, no log line, and no visible indication that it did not take effect — while the status bar affirmatively displays Opus 5 · Fast. Every request in the session is sent at speed: "standard".

The CLI surfaces a reason string in this situation (pde() logs Fast mode unavailable: <reason>). The Desktop UI surfaces nothing, and instead asserts the opposite.

This report is not about fast mode being gated. Gating is expected and documented — this account does not have usage credits enabled. The bug is that the gate is invisible and the UI misreports the resulting state, so a user has no way to know they are not getting what the status bar says they are getting.

Measured on this machine:

Scope	Requests	speed: "fast"
All transcripts	135,218	0
Claude Code 2.1.219 only (Desktop Code tab)	15,934	0

Meanwhile preferences.epitaxyPrefs.fastMode is true and the status bar reads Fast.

What Should Happen?

Either:

1. Requests are sent with speed: "fast"; or
2. The UI surfaces the reason fast mode is unavailable — as the CLI does — and the status bar does not display Fast.

Reporting the requested state instead of the effective state is the core defect.

Steps to Reproduce

1. Open the Claude Desktop app and go to the Code tab.
2. Open the model selector and turn on Enable fast mode.
   • Tooltip: "Faster responses, higher cost. Opus only."
   • Status bar changes to Opus 5 · Fast.
   • ~/Library/Application Support/Claude/claude_desktop_config.json updates preferences.epitaxyPrefs.fastMode from false to true.
3. Start a new conversation (to rule out mid-session toggling) and send any message.
4. Inspect the transcripts:

cat ~/.claude/projects/*/*.jsonl | jq -r 'select(.message.usage.speed) | .message.usage.speed' | sort | uniq -c

Observed: 135218 standard, zero fast. No error anywhere in the UI. Status bar still reads Fast.

Precondition for this account: usage credits are not enabled, so fast mode is correctly expected to be refused. The bug is the absence of any signal that it was.

Error Messages/Logs

# Searching the Claude app log directory for the reason string the CLI would emit:
$ grep -ri 'Fast mode unavailable' ~/Library/Logs/Claude/ ~/Library/Application\ Support/Claude/logs/ 2>/dev/null
# (no output)

$ grep -ri 'fast' ~/Library/Logs/Claude/ 2>/dev/null
# (no output)

There is no error output. That is the bug: nothing is written to the UI or to any log.

Why the reason is never surfaced

In Claude.app/Contents/Resources/.../claude the availability check returns a reason string:

function JW(e){
  if(!El()) return xn()!=="firstParty" ? "not_first_party" : "disabled_by_env";
  if(Ke("tengu_penguins_off",null)!==null) return "unknown";
  if(!Hl(jkt())){ /* ... */ return "model_not_allowed" }
  let t = Hr("flagSettings")?.fastMode === true;
  if(_n() && HVt() && !t) return "sdk_opt_in_required";
  if(mB.status === "pending" && !rYn() && !t) return "pending";
  if(mB.status === "disabled" && !rYn()){ /* ... */ return mB.reason }
  return null
}

and the caller logs it:

function pde(e){ let t = JW(e); if(t === null) return null;
  let r = Rig(t); w(`Fast mode unavailable: ${r}`); return r }

Each reason has a user-facing message, including:

reason	message
extra_usage_disabled	"Fast mode requires usage credits · /usage-credits to turn them on"
free	"Fast mode requires a paid subscription"
preference	"Fast mode has been disabled by your organization"
network_error	"Fast mode unavailable due to network connectivity issues"

None reach the Desktop UI. The message exists; this surface never renders it.

I could not determine which reason fires, precisely because it is never emitted. Two candidates fit:

• extra_usage_disabled — usage credits are off on this account, a documented hard requirement.
• sdk_opt_in_required — the Desktop Code tab is an SDK host, and this gate is bypassed only when flagSettings.fastMode === true, i.e. set in settings.json rather than via the UI toggle. The Desktop session record (claude-code-sessions/**/local_*.json) stores model, effort and permissionMode, but not fastMode.

If it is the second, the UI toggle cannot enable fast mode on this surface at all, regardless of credits — which would make the status bar's Fast label unconditionally wrong here.

Documentation gap (secondary)

The fast mode docs enumerate surfaces and state a negative for one:

"Use /fast to toggle on fast mode in the Claude Code CLI. Fast mode is not supported in the VS Code extension."

The Claude Desktop app is not mentioned at all — neither supported nor unsupported. In a section that explicitly names an unsupported surface, the omission is ambiguous.

The docs also describe the only visual signal for degraded fast mode as the ↯ icon turning gray:

"When you hit the fast mode rate limit or run out of usage credits: 1. Fast mode automatically falls back to standard speed 2. The ↯ icon turns gray to indicate cooldown"

The Desktop Code tab has no ↯ icon. It renders the text Opus 5 · Fast, which has no gray/degraded state. The documented signal has nowhere to appear on this surface.

Finally, the docs list four refusal messages users may see (organization disabled, model not in allowlist, network connectivity, currently unavailable) — but no message is documented for the usage-credits-off case, though it is listed as a requirement and the string exists in the binary.

Suggested fix

In rough priority order:

1. Do not render Fast in the Desktop status bar when the availability check returned a non-null reason.
2. Surface the reason in the Desktop UI, as the CLI does — an inline notice or model-selector subtext would both work.
3. At minimum, write Fast mode unavailable: <reason> to the app log, so the failure is diagnosable without reverse-engineering the binary.
4. Document whether the Claude Desktop app supports fast mode, and document the usage-credits-off message alongside the other four.

Claude Model

Opus (Opus 5, effort High)

Is this a regression?

I don't know — I have no record of fast mode ever engaging on this surface.

Claude Code Version

2.1.219, bundled inside Claude Desktop 1.24012.9.

Note on the "latest version" checkbox: the standalone CLI on this machine is 2.1.220, but the Desktop Code tab does not use it — it runs the Claude Code build embedded in the Desktop app, which is 2.1.219 and cannot be updated independently. 2.1.219 is therefore the latest version available on the affected surface. I could not test 2.1.220 here for that reason; its changelog entry is "Bug fixes and reliability improvements", so I cannot rule the fix in or out.

Platform

Anthropic API (Max 20x subscription, personal account, no organization)

Operating System

macOS (15, Darwin 25.5.0, Apple Silicon)

Terminal/Shell

Other — Claude Desktop app, Code tab (rendererSurface: "epitaxy"), local session. Not a terminal.

Additional Information

Prior reports touching fast mode / Desktop, all closed without a behavior fix:

• /fast slash command has no effect on Desktop app (Windows, Team plan) #44421
• [BUG] Fast mode silently disabled when Claude starts responding (v2.1.68) #30888
• [BUG] /fast has no effect in desktop app — ON and OFF both ~11s; terminal ON ~2x faster (~6s) #64083
• Fast mode billing bug #68728

Changelog search across all 353 released versions returns 17 fast mode entries and 27 Desktop entries, with zero entries covering both. The closest adjacent fixes are surface-specific — and for other surfaces:

• 2.1.157 — "[VSCode] Fixed the fast mode indicator not appearing on Opus 4.8"
• 2.1.219 — "Fixed Remote Control clients keeping a stale fast-mode status after a model switch, reconnect, or failed org check"

Both are the same class of defect — a client displaying a fast-mode state that does not match reality — fixed on VS Code and on Remote Control, but not on Desktop.

Note on filing method: submitted via gh because this report spans the bug-report form's fields plus binary/docs evidence that does not fit them cleanly. All required fields are answered above under their form headings.