Repository navigation
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c9de4267ca
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b45f645b2c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Stopped: blocked, no further changesThis PR is blocked and stays open. I will not push, rerun or merge it. The branch stays.
Generated with |
The first model switch now runs inside the try, so the finally also runs when that switch fails. The finally restores Opus 5.5 only when the label is not Opus 5.5 already.
b45f645 to
61fc4f5
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 61fc4f5e21
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // The model's capability identity comes from the provider config, not from the route: an | ||
| // explicit mapping ("Treat as") or a Coder instance's upstream, then a custom provider's | ||
| // wire dialect (an anthropic-messages provider serving claude-opus-5-5 is an Opus model). | ||
| let capabilityModel = normalizeToCanonical(resolveModelForMetadata(modelString, providersConfig)); |
There was a problem hiding this comment.
Recognize Copilot-hosted Anthropic models
When a Fast-capable Claude model is selected through GitHub Copilot (for example, github-copilot:claude-opus-5-5), this preserves the Copilot prefix because that gateway intentionally has no canonicalizer. The subsequent direct-provider check therefore rejects the model and the new toast incorrectly says the model has no Fast mode, even though direct Anthropic supports it and only the Copilot route is incompatible. Resolve Copilot's recognizable upstream model family before classifying the reason.
Useful? React with 👍 / 👎.
|
Parked on
Generated with |
Summary
Two follow-ups from #5744. Ctrl+I in the workspace view no longer moves focus behind the open command palette. The fast mode shortcut now says "this model has no fast mode" for models that have none on any route, instead of blaming the provider route.
Fixes #5752
Refs #5753
Background
[cmdk-root]), becauseisDialogOpen()does not see it. The workspace view's handler inuseAIViewKeybindsstill checked onlyisDialogOpen().Implementation
isCommandPaletteTarget(target)inkeybinds.tsreplaces the inline[cmdk-root]checks. The creation Ctrl+I handler, the workspace Ctrl+I handler and the background-processes shortcut use it.getFastModeUnavailableReason(model, providersConfig)first finds the model's capability identity from the provider config, independent of the route: an explicit mapping or the Coder upstream, then a custom provider's wire dialect (ananthropic-messagesprovider servingclaude-opus-5-5counts as Opus). It then asksgetFastModeProviderabout that model on its own provider, called directly. If fast mode works there, the route is the reason. Otherwise the model is.Validation
New bug-bash repros in
tests/bugbash/repros/focusAndLabels.e2e.ts, web and phone. Both fail on main on their own assertion:ASSERTION_FAILED: expect.toBeFocusedASSERTION_FAILED: expect.toBeVisibleI restored
App.tsxanduseAIViewKeybinds.tsfrom main in a scratch build to get the failures above, then restored the fix: the whole file passes.The #5753 repro is tagged
mock-only. It switches the shared workspace from Opus 5.5 to Haiku 4.5 and back, and the model search matches model ids, not the labels the test can read. Mock mode always starts on Opus 5.5, while real mode starts onBUGBASH_APP_MODEL. Both model switches run inside thetry/finally. Thefinallyswitches back to Opus 5.5 only when the label is not Opus 5.5 already, so it also works when the first switch fails part way.make test-bugbash-reproson61fc4f5e21: the mock phase (--tag mock-only) passed 8 of 8 tests, this repro included on web and phone. The main phase (--exclude-tag mock-only) passed 28 of 28.make static-checkpassed. The older #5693 toast repro stays in the main phase: it checks the "Fast mode is not available" prefix, which both reasons share. A unit test infastModeServiceTier.test.tscovers the model/route branches: Gemini, Haiku andgrok-code-fast-1give "model". Gateway Opus, OpenRouter GPT and Grok 4.7 give "route". It also covers the provider-config cases: mappedteam-opusgives "route", mappedteam-haikugives "model", and ananthropic-messagescustom provider serving Opus gives "route". With the config lookup removed, it fails.Failure-path check of that
finally(scratch edits, not committed, on61fc4f5e21, web and phone). Each variant also checks, at the end of thefinally, that the model picker shows Opus 5.5:finallyswitched back and saw Opus 5.5. The test failed with the forced error.finallyskipped the switch and saw Opus 5.5. The test failed with the forced error.ASSERTION_FAILED: expect.toBeVisibleon the Opus 5.5 check, so the check can see a wrong model.A scratch probe test that ran next in the same app also saw Opus 5.5 in all three variants, the control included. e2e gives each test a fresh browser context, and the picker keeps an existing workspace's model only in browser storage. So in this harness a model switch does not leak into later tests, and the
finallyonly keeps the test's own state clean.Known limit, tracked in #5764: a model with an unknown identity (an
openai-compatiblecustom provider, an unknown Coder instance) gets the "model" reason.Risks
Low. Ctrl+I now does nothing while focus is in the command palette, in both views. Only the toast text changes for fast mode.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high