dsh: remove the local Ollama models from the chat dropdown

Reverts the MODEL_CHOICES/MODEL_LABELS additions from 2609ab5. The .27 models are
gone from the family console, so the two dropdown entries would have been dead
options that error when selected (and they were offered to every user).

The list is back to exactly the original 10 cloud entries. Existing sessions that
still reference a removed id fall back to the default rather than erroring, since
the server validates the id against MODEL_CHOICES.

docs/dsh-architecture.md: drop the 'Local Ollama models' section, and add a warning
that auto/* are OmniRoute *routers* — when OmniRoute's pool is exhausted they fail
with 'Maximum combo retry limit reached' and DSH shows it as 'Model returned no
response', which is not a DSH bug.

Verified on .13: all four instances report 10 models with no ollama entries, and a
real streamed reply comes back through DSH on an explicit model.
This commit is contained in:
2026-10-12 19:45:29 +11:00
parent 990e433117
commit 1ff6c41a51
2 changed files with 10 additions and 13 deletions

View File

@@ -88,6 +88,8 @@ is added to `MODEL_CHOICES` **and** `MODEL_LABELS`.
A chosen model is validated server-side (`if active_model not in MODEL_CHOICES:
active_model = LLM_MODEL`), so an unlisted id silently falls back to the default.
That also means removing an id is safe: sessions that still reference it fall back
rather than erroring.
### Adding a model
@@ -100,13 +102,15 @@ active_model = LLM_MODEL`), so an unlisted id silently falls back to the default
bakes `app.py` via `COPY . .`, so a rebuild is required — restarting is not enough).
4. Verify: `curl -s http://127.0.0.1:3081/api/models` should list the new id.
### Local Ollama models
### The default model is not necessarily a working model
The `.27` models are exposed by OmniRoute as `ollama/qwen2.5:14b` and
`ollama/qwen2.5-coder:14b` (`ollama-local/…` also exists but is duplicated).
Because Ollama now starts **off** at boot, these fail until it is started from the
family console; hence the `needs Ollama on` label. Inference is CPU-only on `.27`,
so expect it to be slower than the cloud routes.
`DSH_LLM_MODEL` (set to `auto/best-chat` in `docker-compose.yml`) is the default.
The `auto/*` entries are **OmniRoute routers**, not providers: if OmniRoute's
candidate pool is exhausted it returns `service_unavailable` / "Maximum combo
retry limit reached", and DSH surfaces that as *"Model returned no response"*.
That is an OmniRoute-side failure, not a DSH bug — check it by calling OmniRoute
directly, and prefer an explicit model id (e.g. `deepseek/deepseek-v4-flash`)
when testing whether DSH itself is healthy.
---