CLI /model picker only exposes first 50 models despite larger provider catalog

[hirenpatelatl]

Summary

The interactive /model picker shows providers with total_models > 50, but only loads the first 50 model IDs into the selectable list. As a result, users cannot scroll/page to models after the first 50 even though the picker displays the larger total count.

Repro

1. Configure a provider with more than 50 available models. In my current install this is Nous Portal.
2. Run Hermes CLI.
3. Enter /model.
4. Select the provider.
5. Try to navigate past the first 50 models.

Expected

All available models should be reachable from the interactive picker, either by scrolling through the full loaded list or by explicit pagination/search.

Actual

Only the first 50 models are selectable. The provider row may show the real total, but the model selection stage only has the first 50.

In my current install, Hermes reports:

nous: shown=50 total=247 current=False source=hermes

So the inventory knows there are 247 models, but the picker only receives 50.

Code pointers

The CLI picker hard-caps the payload here:

# cli.py
providers = build_models_payload(ctx, max_models=50)["providers"]

build_models_payload() forwards that to list_authenticated_providers():

# hermes_cli/inventory.py
rows = list_authenticated_providers(..., max_models=max_models)

Then list_authenticated_providers() slices the provider model list:

# hermes_cli/model_switch.py
total = len(model_ids)
top = model_ids[:max_models]

The picker viewport/scrolling code appears to work, but it can only scroll through the already-truncated model_list.

Related call sites with the same cap:

• cli.py — CLI /model picker (max_models=50)
• gateway/run.py — gateway model picker payload (max_models=50)
• tui_gateway/server.py — TUI model options/provider rows (max_models=50)
• hermes_cli/web_server.py — dashboard/API model options (max_models=50)

Environment checked

Current local install is clean and matches upstream origin/main:

HEAD: 6a72af044c44c9a05137bc448bc65ecf0ace5a89
branch: main
remote: git@github.com:NousResearch/hermes-agent.git
status: ## main...origin/main

No local diff in the relevant files.

Possible fixes

For interactive pickers, either:

1. Load all models by passing a non-truncating value, e.g. support max_models=None and skip slicing when it is None; or
2. Implement actual provider-model pagination/search so users can access models beyond the first 50.

A quick local mitigation would be to raise the CLI picker cap, but the cleaner fix is to separate display-preview limits from selectable model inventory.

[alt-glitch]

Duplicate of #27914 — PR already open to fix the same truncation (build_models_payload caps at max_models=50, picker can only scroll the truncated list). Also related: #35269 (bumps limit 50→200 as part of broader PR).

[Goblin05]

Confirmed same root cause on NVIDIA NIM provider (https://integrate.api.nvidia.com/v1, 121 models) hitting Dashboard on :9119. Adding our full repro + workaround to help the maintainers close this.

Symptom on Dashboard :9119 (hermes-dashboard.service)

• "Set Main Model" dropdown, provider list shows Nvidia — 121 models
• default model qwen/qwen3.5-122b-a10b (sort position 121) is missing from the dropdown
• GET http://192.168.0.185:9119/api/model/options payload only contains the first 50 NVIDIA model IDs
• curl against the same response also returns exactly 50 model IDs, confirming the cap is server-side in web_server.py, not a browser/UI pagination issue

Cross-check — third-party Web UI :8648 is unaffected

The third-party Web UI (EKKOLearnAI/hermes-web-ui) at http://192.168.0.185:8648/api/hermes/available-models lists all 121 NVIDIA models correctly because it queries NVIDIA's /v1/models directly, never going through build_models_payload. So the issue is purely in hermes-agent's own picker/Dashboard payload builder, not in any provider API.

Workaround we applied (matches the 4 call-sites you listed)

Raised the cap to 200 at the 4 sites in this repo:

--- a/hermes_cli/web_server.py
+++ b/hermes_cli/web_server.py
@@
-    return build_models_payload(load_picker_context(), max_models=50, pricing=True, capabilities=True)
+    return build_models_payload(load_picker_context(), max_models=200, pricing=True, capabilities=True)
@@
-    return build_models_payload(load_picker_context(), max_models=50, pricing=True, capabilities=True)
+    return build_models_payload(load_picker_context(), max_models=200, pricing=True, capabilities=True)

--- a/tui_gateway/server.py
+++ b/tui_gateway/server.py
@@
-    return build_models_payload(load_picker_context(), max_models=50, pricing=True, capabilities=True)
+    return build_models_payload(load_picker_context(), max_models=200, pricing=True, capabilities=True)
@@
-    return build_models_payload(load_picker_context(), max_models=50, pricing=True, capabilities=True)
+    return build_models_payload(load_picker_context(), max_models=200, pricing=True, capabilities=True)

(we didn't touch cli.py and gateway/run.py because in our install CLI and Gateway are not the user-facing entry; the symptom showed up in the Dashboard and TUI web gateways only)

Important for upgraders — the venv site-packages trap

After patching, the fix does not take effect by itself. The PyPI install runs web_server.py from:

~/.hermes/hermes-agent/venv/lib/python3.11/site-packages/hermes_cli/web_server.py

not from the development working tree. Steps needed to actually apply the change:

# 1. patch the source files in the working tree (or just patch the site-packages copy)
cp ~/.hermes/hermes-agent/hermes_cli/web_server.py \
   ~/.hermes/hermes-agent/venv/lib/python3.11/site-packages/hermes_cli/web_server.py

cp ~/.hermes/hermes-agent/tui_gateway/server.py \
   ~/.hermes/hermes-agent/venv/lib/python3.11/site-packages/hermes_cli/tui_gateway/server.py

# 2. restart the service (NOT hermes-gateway; the 9119 port is hermes-dashboard)
systemctl --user restart hermes-dashboard

If only the working-tree copy is patched and the service is restarted, behaviour is unchanged — web_server.py is loaded from site-packages.

Upgrade regression warning

Any of the following will silently overwrite this local fix and bring the cap back to 50:

• pip install --upgrade hermes-agent
• pip install -U hermes-agent (re-install)
• hermes update / the in-app update flow (if it touches the venv)

Until upstream lands max_models=None (skip slicing) or real pagination/search, the only durable local fix is a patch script that re-applies the change after every upgrade. We've kept backups of the 3 affected files in backup_official_webui_20260613/ for that purpose.

Long-term fix preference

We'd vote for option (1) — max_models=None to skip slicing, but with a sensible default in config.yaml (e.g. picker.max_models: 200) so power users can still cap if they want a lighter picker. The 50 cap was probably set when the largest provider had < 50 models; 121 (NVIDIA) and 247 (Nous Portal) make that hard cap the wrong default for a picker that's supposed to be exhaustive.

Environment

• Ubuntu 24.04.4 LTS, hermes-agent v2026.5.29-868-gd880b5be0
• PyPI install (no .git in hermes-agent/), user-level venv
• Config: ~/.hermes/config.yaml, NVIDIA provider, default: qwen/qwen3.5-122b-a10b
• API key: ~/.hermes/.env → NVIDIA_API_KEY
• Affected service: hermes-dashboard.service (port 9119); hermes-gateway (port 8642) was not the symptom site in our case

[Goblin05]

Pinging @teknium1 — same root cause as the dashboard fix you just landed in #45150 (skill installs silently auto-cancel). This one is the picker/payload builder hard-coding max_models=50 at 4 call-sites, which truncates any provider with more than 50 models (NVIDIA NIM = 121, Nous Portal = 247, etc.).

Repro for Dashboard :9119 (full details in my previous comment, also archived at the project README):

• Provider row shows correct total (Nvidia — 121 models)
• Default model qwen/qwen3.5-122b-a10b (sort position 121) is missing from the "Set Main Model" dropdown
• GET /api/model/options returns exactly 50 model IDs per provider

The cleanest fix per @hirenpatelatl's own analysis: support max_models=None to skip slicing, with a picker.max_models default in config.yaml (e.g. 200) so power users can still cap.

Happy to send a PR if useful — say the word and I'll open one against main.