Repository navigation
fix(tui): stop defaulting to the Zen provider in the model fallback - #144
Merged
Merged
Conversation
With no config `model` pin and no saved recents (a fresh `codevhub install` — both writers dropped the pin in PR #142 / hub PR #221), the TUI's fallbackModel took sync.data.provider[0]. The hosted Zen provider self-registers (free models need no auth) ahead of config-only providers, so a gateway-only setup started on "Big Pickle · OpenCode Zen" and would send messages to upstream's hosted gateway. Extract useConnected's predicate into isConnectedProvider and make the fallback prefer the first provider that passes it — the same "a real provider is configured" test the startup gate and footer indicator use. When no provider qualifies the old first-provider behavior is kept. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The hub's models-map order never carried the first-launch choice; hub PR #229 seeds the state dir's recents (when empty) instead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
After a fresh
codevhub install, the TUI footer showed Big Pickle · OpenCode Zen even though a real gateway provider (netgate) was configured — and a first message would have gone to upstream's hosted Zen gateway instead of the configured one.Both config writers dropped the top-level
modelpin in the last round (#142 / codev-hub#221), so with empty recents the TUI'sfallbackModel(context/local.tsx) fell through to its last resort: a blindsync.data.provider[0]. The hosted Zen provider self-registers (its free models need no auth) duringProvider.list()'s custom-loader loop, ahead of config-only providers, so it always occupies slot 0. The original Zen-hiding work covered the pickers, tips, and the footer/startup gate — but never this fallback path. (The server-sideProvider.defaultModelalready restricts its fallback to configured providers; the TUI's local fallback didn't.)Fix
component/use-connected.tsx: extractuseConnected's existing predicate into an exportedisConnectedProvider(provider); the hook delegates to it — gate/footer behavior unchanged. The free-Zen auto-registration fails it; a deliberately-authenticatedopencodewith paid models still passes.context/local.tsx:fallbackModel's last resort becomessync.data.provider.find(isConnectedProvider) ?? sync.data.provider[0]. When only the Zen registration exists, behavior is unchanged (the configure gate is up in that state anyway).Verification
test/component/use-connected.test.tscovers the predicate and the Zen-first-in-list selection; full TUI suite passes (247 tests),bun typecheckclean.model.jsonrecents): footer now showszai-org/GLM-4.7-cc netGateinstead ofBig Pickle OpenCode Zen.DIVERGENCES.md row added for both upstream files; CHANGELOG entry under Unreleased.
Note for a follow-up in codev-hub: within the configured provider the default still resolves via the server's
provider_defaultsort, not the model chosen in the install wizard — if the wizard's choice should stick, the hub needs to seed codev'smodel.jsonrecents like the fork's own/configureflow does since #142.🤖 Generated with Claude Code