Repository navigation
Conversation
|
Hey! Your PR title Please update it to start with one of:
Where See CONTRIBUTING.md for details. |
There was a problem hiding this comment.
Thanks for picking up #40792! I can't verify this as it stands, and it won't change either picker on dev. The branch is built on the old v1 tree (packages/opencode 1.15.4). Neither file it edits exists on dev anymore: packages/opencode/src/cli/cmd/tui/component/dialog-model.tsx and packages/app/src/components/dialog-select-model.tsx were replaced in v2. Merging would at best re-add dead v1 files, and more likely hit modify/delete conflicts.
Could you rebase onto current dev and port the change to the v2 pickers?
- TUI:
packages/tui/src/component/dialog-model.tsx(anddialog-model-free.tsx), with tests inpackages/tui/test/cli/cmd/tui/model-options.test.ts. The footer there already shows usage limits (trailing(model, favorite), "No limit" and dollar amounts), so the context and cost badges need to fit with that rather than replace it. - Web/desktop:
packages/app/src/providers/models/select-dialog.tsx(state inselect-dialog-machine.ts). It already renders aModelUsageTagper item.
When porting, a few things from this version are worth fixing:
- The web badge row reads
i.limit.contextandi.cost.input/i.cost.outputwithout guards, so custom or config-defined models without cost or limit data would break the description's "degrade gracefully" promise. - User-facing labels in the app should go through
language.tlike the surrounding strings. - Sorting free models by
footer?.startsWith("Free")ties ordering to display text. Sort on the model data (for example, cost) instead. - #40792 also asks for the output limit, which isn't shown yet.
Before/after screenshots of both v2 pickers would help once ported.
Public API: unchanged (UI only).
Add modelFacts so a picker row states its input, context and output limits, reasoning and tool support, and guard the reads a hand-built model can omit.
Badge a row with its input modalities, tool support, context and output limits and price, and name the output limit in the model details flyout.
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
There was a problem hiding this comment.
Thanks for porting this to v2. All my earlier points are addressed: it now edits the v2 pickers, missing cost/limit data is guarded, the app badges use language.t, the sort no longer depends on the footer text, and the output limit is shown.
I checked it with model-options.test.ts (16 pass) and tsc -b in packages/tui and packages/app (both pass). The app src/providers tests have 2 failures, and the base has the same 2. I couldn't get a populated /models view in the TUI or run the web app here. Could you add the before/after screenshots of both pickers you mentioned, including a long model name in the large web dialog?
Public API: unchanged (UI only).
Two things worth sorting out:
-
Large web dialog row: see the inline comment.
-
TUI scope: the TUI only changes
modelFacts, which is shown in the highlighted model's detail row and only whenexperimental.new-designsis on. Without that flag the TUI/modelspicker looks the same as before. That may be fine, but the description should say so, since #40792 is about the TUI command. -
packages/app/src/providers/models/select-dialog.tsx:975: In the large dialog these badges go on the same line as the model name, inside oneshrink-0span. A multimodal paid model gets up to 7 badges (4 modalities, Tools, limits, price), plus Free/Latest/provider. Only the name can shrink, so long names get cut down to a few characters, and it gets worse on narrow and mobile layouts. This dialog already shows the same information in the hover flyout (ModelDetails, which now includes the output limit too). Could the row keep a smaller set, e.g. limits and price only, or put the badges on a second line as the settings list does at line 223?
ModelDetail only renders under experimental.new-designs, so the default picker showed nothing new. Append the context and output limits to the footer (next to Free) so anomalyco#40792 is fulfilled for the default experience too.
The desktop /models row is 28px single-line, so 7 badges plus Free/Latest/provider crushed long names. Render only limits and price there; the full set stays on the mobile drawer's second line and in the hover flyout (ModelDetails).
There was a problem hiding this comment.
Both points from my last review are addressed. The large dialog row now passes compact and shows only limits and price; the full badge set stays on the settings list's second line and in the hover flyout. The default (non-new-designs) TUI picker now shows the limits in the footer.
I checked it by driving /models in the TUI on the base and on this branch with the simulated provider. The row now shows 128K/16K (screenshots below). The TUI tests in test/cli/cmd/tui and dialog-select.test.tsx pass (65), and tsc -b passes in packages/tui and packages/app. I didn't run the web app, so your before/after screenshots of the web dialog, with a long model name, would still help.
Public API: unchanged (UI only).
No further concerns from the new commits.


Issue for this PR
Closes #40792
Type of change
What does this PR do?
Shows capability badges in the /models picker in both the TUI and the web/desktop app, so you can see what a model accepts at a glance:
The TUI's existing detail row (modalities, context, reasoning) now also shows the output limit and tool support. The app's model details flyout shows the output limit too.
On the TUI side the detail row only renders under the experimental.new-designs flag, so the limits are also appended to the default picker's footer, so #40792's ask is fulfilled for the default experience too.
On the desktop, the single-line row can't fit 7 badges without crushing long model names, so it keeps a compact set (limits and price) while the mobile drawer keeps the full set on a second line and the hover flyout keeps the complete details.
Data comes from the existing models.dev pipeline — no new fetch. Hand-built or config-defined models that omit cost or limit data are guarded so the picker degrades gracefully instead of breaking.
How did you verify your code works?
cd packages/tui && bun run typecheck:tscpassescd packages/app && bun run typecheck:tscpassescd packages/tui && bun test test/cli/cmd/tui/model-options.test.ts— 16 passcd packages/tui && bun test test/cli/cmd/tui test/cli/tui/dialog-select.test.tsx— 65 pass, 0 failcd packages/app && bun test --preload ./happydom.ts src/providers src/usage— 143 pass; the 2 failures (models.test.ts and connect/remote.test.ts) reproduce on a clean checkout (solid-sonner client-only API under happydom)Screenshots / recordings
To follow — before/after of both v2 pickers, including a long model name in the large web dialog.
Checklist
Added by the opencode bot (AI-generated).
Related: #59818, #60856