[Bug]: OpenRouter /model picker truncated to ~30 curated models instead of full tool-calling catalog

[Pinhais]

Bug Description

Summary

The OpenRouter model picker (/model) surfaces only ~30 models, while the full OpenRouter catalog advertises ~260 models today with tool-calling support. The picker iterates a curated snapshot instead of the live /v1/models catalog,
so the vast majority of usable models are never shown.

The bug

hermes_cli/models.py → fetch_openrouter_models() builds its output by iterating OPENROUTER_MODELS (the curated snapshot, ~33 entries) and looking each id up in the live API response:

python
preferred_ids = [mid for mid, _ in fallback]
...
for preferred_id in preferred_ids:
    live_item = live_by_id.get(preferred_id)
    if live_item is None:
        continue
    if not _openrouter_model_supports_tools(live_item):
        continue
    ...


Any model that exists on OpenRouter but is not in the curated list is silently dropped. The function already fetches the full live catalog (payload["data"]) — it just doesn't iterate it.

Impact

- Users can only pick from ~30 of the ~260 tool-capable OpenRouter models.
- Real, currently-available models (including ones the user is actively using, e.g. tencent/hy3:free) may be invisible in the picker depending on what the curated list happened to include.
- Because the curated list is static, every new OpenRouter model requires a code/manifest change to become selectable — the catalog drifts between releases.

Repro

1. Run /model (Telegram / Discord / CLI / TUI).
2. Count the OpenRouter models offered.
3. Compare against GET https://openrouter.ai/api/v1/models filtered by supported_parameters containing tools.

Observed: ~30 offered vs ~260 available.

Workaround required today (why this should be fixed upstream)

The fix is to iterate the live catalog directly rather than the curated list. This works, but it lives only as a local patch. hermes update resets the working tree (it git reset --hard origin/main when the local branch has
diverged commits, or stashes/restores local edits), so the correction is wiped on every update. The user is then forced to re-request the fix from the agent after each update. Making the picker iterate the live catalog in the
canonical source removes this recurring breakage.

Related / similar PRs

- #57362 — "add all OpenRouter free models to curated catalog": addresses the same symptom by inflating the curated list rather than iterating the live catalog; would raise the count to ~50 but still truncates and still requires
manual updates as the catalog grows. Different approach to the same root cause.
- #57642 — "detect and warn when curated OpenRouter models are removed from live API": complementary (warns about drift) but does not change picker truncation.
- #60656 — "make picker discovery config-aware": reworks provider-row discovery via config.yaml; does not change fetch_openrouter_models() to iterate the live catalog.

Suggested direction (for maintainers)

Iterate payload["data"] in fetch_openrouter_models() and keep every entry that advertises tool-calling support, using OPENROUTER_MODELS only as a fallback ordering hint / offline source. Keep the existing
_openrouter_model_supports_tools() gate (so non-tool models stay hidden) and the max_models plumbing in gateway/slash_commands.py / tui_gateway/server.py (currently capped at 50, which would truncate even a correct catalog).

Steps to Reproduce

run hermes update, choosing yes or no to the questions about fetching.

Expected Behavior

maintain all Openrouter LLMs with toolcalling after run an hermes update

Actual Behavior

every update for hermes, inspite of option choosen, openRouter LLMs list comes to ~30 LLMs from 260+ with toolcalling, so if I update Hermes, I have to ask him to fix the openRouter LLMs list so I can choose thr one I want to use.

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

Telegram

Debug Report

[hermes debug share: log content redacted at upload time. run with --no-redact to disable]
--- hermes dump ---
version:          0.18.2 [e8ac41c5] (2026-07-08)
os:               Linux 7.1.3-1-cachyos x86_64
python:           3.11.15
openai_sdk:       2.24.0
profile:          default
hermes_home:      ~/.hermes
model:            tencent/hy3:free
provider:         openrouter
terminal:         local

api_keys:
  openrouter           set
  openai               not set
  anthropic            not set
  anthropic_token      not set
  nous                 not set
  google/gemini        not set
  gemini               not set
  glm/zai              not set
  zai                  not set
  kimi                 not set
  minimax              not set
  deepseek             not set
  dashscope            not set
  huggingface          not set
  nvidia               not set
  opencode_zen         not set
  opencode_go          not set
  kilocode             not set
  firecrawl            not set
  tavily               not set
  browserbase          not set
  fal                  not set
  elevenlabs           not set
  github               not set

features:
  toolsets:           hermes-cli
  mcp_servers:        0
  memory_provider:    built-in
  gateway:            running (systemd (user), pid 70497)
  platforms:          none
  cron_jobs:          1 active / 1 total
  skills:             91

config_overrides:
  agent.max_turns: 150
  display.streaming: True
  display.show_reasoning: False
  tts.provider: openai
--- end dump ---


--- full desktop.log ---
[hermes] [boot] Resolving Hermes backend
[hermes] [boot] Resolving Hermes runtime
[hermes] [boot] Using existing Hermes CLI at /home/ze/.local/bin/hermes
[hermes] [backend] `serve` supported for existing Hermes CLI at /home/ze/.local/bin/hermes
[hermes] [boot] Starting Hermes backend via existing Hermes CLI at /home/ze/.local/bin/hermes
[hermes] Starting Hermes backend via existing Hermes CLI at /home/ze/.local/bin/hermes
[hermes] [boot] Waiting for Hermes backend to launch
[hermes] HERMES_DASHBOARD_READY port=45519
[hermes]   Hermes Web UI → http://127.0.0.1:45519
[hermes] [boot] Waiting for Hermes backend to become ready
[hermes] [boot] Hermes backend is ready. Finalizing desktop startup

Operating System

cachy os latest

Python Version

3.14.6

Hermes Version

latest version with hermes update at 08/07/2026 (dd/mm/yy)

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[Jugder]

Independent confirmation on 3fa318a50, plus fresh numbers — the gap is wider than the issue title suggests, and the same root cause extends to Nous.

Current measurements

Provider	Live catalog	Tool-capable	Shown in picker	Visibility
OpenRouter	338	272	39	14.3%
Nous	292	—	30	10.3%

233 tool-capable OpenRouter models are dropped. Reproduced with:

from hermes_cli.models import fetch_openrouter_models, get_curated_nous_model_ids
len(fetch_openrouter_models())    # 39
len(get_curated_nous_model_ids()) # 30

The remote manifest does not help

Worth noting since it might look like a stale-cache issue — it isn't. Both manifest URLs are reachable and serve exactly the same truncated lists:

https://hermes-agent.nousresearch.com/docs/api/model-catalog.json   -> openrouter=39, nous=30
https://raw.githubusercontent.com/.../website/static/api/model-catalog.json -> openrouter=39, nous=30

So the manifest indirection adds a moving part without changing the outcome — publishing a wider manifest would still require a manual edit per model, which is the treadmill this issue is about.

Nous has the same defect, via a shorter path

get_curated_nous_model_ids() (hermes_cli/models.py:1578) returns a static list with no live reconciliation at all — not even the intersection OpenRouter gets. Whatever fix lands here should cover it; otherwise Nous users keep 10% visibility. Related: #71313.

Practical impact — the curated list has no cheap tier

This bites hardest on auxiliary.* tasks, where a small cheap model is the correct choice. I benchmarked candidates for my aux workloads, then checked whether the picker could have offered them:

google/gemini-3.1-flash-lite             live=True  picker=False
amazon/nova-lite-v1                      live=True  picker=False
google/gemma-4-26b-a4b-it                live=True  picker=False
inclusionai/ling-3.0-flash:free          live=True  picker=False
stepfun/step-3.7-flash:free              live=True  picker=False
anthropic/claude-sonnet-4.6              live=True  picker=False
qwen/qwen3-vl-30b-a3b-instruct           live=True  picker=False
nvidia/nemotron-3-nano-30b-a3b           live=True  picker=False
deepseek/deepseek-v4-flash               live=True  picker=True   <- only one

8 of the 9 models I ended up configuring are unreachable through the UI. All were set via hermes config set, bypassing the picker entirely — which makes the picker the slowest path to a correct config.

Free tier is cut too — 12 free tool-capable OpenRouter models are hidden, several of them good aux candidates:

inclusionai/ling-3.0-flash:free
nvidia/nemotron-3-nano-30b-a3b:free
nvidia/nemotron-nano-12b-v2-vl:free
google/gemma-4-26b-a4b-it:free
poolside/laguna-xs-2.1:free
openai/gpt-oss-20b:free

On measured quality these are not compromises: inclusionai/ling-3.0-flash:free scored 10/10 on an identifier-retention compression test at 2.8s and $0, matching paid models I compared it against.

One caveat on the proposed fix

Iterating the live catalog is right, but supports_tools alone is not a sufficient gate for every task. auxiliary.vision additionally needs architecture.input_modalities to contain image — without that filter a wider list makes it easier to pick a blind model and hit a runtime 404. Filed separately as #78884; noting it here so the two fixes stay compatible.