Repository navigation
🤖 Fast mode toast: unknown model identity should give the route reason #5764
Description
Activity
One more case for this issue, found by the normal review of #5756 (thread: #5756 (comment)).
Copilot-hosted Claude models get the "model" reason instead of "route". A user on
github-copilot:claude-opus-5-5who presses the fast mode shortcut sees "this model has no fast mode". Direct Anthropic supports fast mode for Opus 5.5, so the real cause is that the Copilot route cannot send it.Where:
getFastModeUnavailableReasoninsrc/browser/utils/fastModeServiceTier.ts:84(on #5756 head61fc4f5e21).normalizeToCanonicalkeeps thegithub-copilot:prefix, because that gateway has no canonicalizer. The direct-provider check then rejects the model.Scratch-script evidence (on that head,
providersConfig=null):github-copilot:claude-opus-5-5 model anthropic:claude-opus-5-5 route anthropic:claude-haiku-4-5 modelThe fix belongs with the other identity cases here: map Copilot's recognizable upstream model family before the direct-provider check. The user approved deferring it from #5756 to this issue.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high- added a commit that references this issue
on Oct 7, 2026
Problem: The fast mode shortcut toast (#5756) says "this model has no fast mode" when Xum cannot tell which model it is. This happens for an
openai-compatiblecustom provider (for example one servingclaude-opus-5-5) and for a Coder instance of unknown type. The claim can be false there. The route message ("on its current provider route ...") is never false in that case.Fix idea: in
getFastModeUnavailableReason(src/browser/utils/fastModeServiceTier.ts), return "route" when the capability identity is unknown. Flip theteam-compatcase infastModeServiceTier.test.ts.Priority P3. Size S. Follow-up of #5756 (found by its final check).
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high