fix(android): list and apply chat models without a Desktop Gateway - #97
Open
software-greg wants to merge 1 commit into
Open
software-greg wants to merge 1 commit into
software-greg wants to merge 1 commit into
Conversation
The per-chat model picker is coupled to the Desktop Gateway WebSocket: `_showModelSelector` returns early unless a gateway client exists, and applying a choice pushes it over that socket via `setSessionModel` / `setSessionReasoning`. Any deployment without a reachable gateway therefore has a permanently dead picker, even though chat, sessions and history all work. Listing needs only `api/model/info` and `api/model/options` over dashboard REST, and the API server already resolves a per-request `model` field, so the socket is not actually required for either half of the feature. - list models through `DashboardClient` when no gateway is configured; - keep the selection local and persisted instead of pushing it over the socket; - carry the chosen model as the `model` field on the chat request, which `sendMessageStreaming` already accepts. Reasoning effort remains gateway-only and is simply not applied in this mode. Gateway turn recovery and its journal invariants are untouched: with a gateway configured every path behaves exactly as before.
Author
|
Related issues:
|
rusty4444
approved these changes
Sep 5, 2026
rusty4444
left a comment
Owner
There was a problem hiding this comment.
Hermes automation review — APPROVED (not auto-merging this pass)
- Well-scoped, conservative fix:
_modelListingClient()only builds aDashboardClientwhen no Desktop Gateway is configured; therestClient!null-safety is sound by construction. - Verified against the repo: constructor args match
DashboardClient, referencedSavedConnectiongetters exist, and gateway-connected sessions still route through the existing gateway message paths — no regression to the desktop-gateway flow. ⚠️ This branch has no CI checks reported — merge only once CI is visible and green.⚠️ Merge-order: #95/#96 also modifychat_screen.dart; expect a rebase after those land.
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.
The per-chat model picker is coupled to the Desktop Gateway WebSocket:
_showModelSelectorreturns early unless a gateway client exists, and applying a choice pushes it over that socket viasetSessionModel/setSessionReasoning. Any deployment without a reachable gateway therefore has a permanently dead picker, even though chat, sessions and history all work.Listing needs only
api/model/infoandapi/model/optionsover dashboard REST, and the API server already resolves a per-requestmodelfield, so the socket is not reqd for either half of the feature.DashboardClientwhen no gateway is configured;modelfield on the chat request, whichsendMessageStreamingalready accepts.Reasoning effort remains gateway-only and is simply not applied in this mode.
Gateway turn recovery and its journal invariants are untouched: with a gateway configured every path behaves as before.
Motivation: we run Hermes headless and reverse-proxy only a handful of read-only dashboard GETs to the android client -- api/model/{info,options} for this picker, plus api/{memory,skills,cron/jobs} for the read-only tabs -- while deliberately not routing api/config, which returns provider keys and passwords. Every one of those tabs already works over REST; the model picker was the only feature that reached for the gateway socket, and only to read two endpoints we already publish.