fix(openrouter): surface first-party router models (Fusion) in the model picker

[yusekiotacode]

Problem

OpenRouter's first-party deliberation router openrouter/fusion never appears in the Hermes model picker, even with a valid OPENROUTER_API_KEY. Users have to hand-edit config to select it.

Two stacked causes in hermes_cli/models.py:

1. Not a candidate. The OpenRouter picker is a curated list (remote manifest via get_curated_openrouter_models(), with the in-repo OPENROUTER_MODELS snapshot as fallback). Neither included openrouter/fusion, so it never entered preferred_ids in fetch_openrouter_models().
2. Filtered out. Even when present, the function hides any live model whose supported_parameters omits tools (the tool-calling-first gate from fix(gateway): hide models without tool support from list Kilo-Org/kilocode#9068). Fusion reports supported_parameters: [] because it is a meta router, so it gets dropped.

Why Fusion is a legitimate exception

Fusion is a multi-model deliberation router: a panel of models answers in parallel (with openrouter:web_search/web_fetch run server-side), a judge synthesizes consensus/contradictions/blind-spots, and it returns a final answer. It does not require client-side tool calling, and it drives the Hermes agent loop fine — verified end-to-end with a one-shot hermes -z ... -m openrouter/fusion run that completed normally.

The same applies to OpenRouter's other first-party routers (openrouter/auto, openrouter/pareto-code, etc.), which are curated entries we already vouch for.

Fix (both layers)

• Add openrouter/fusion to the OPENROUTER_MODELS fallback snapshot.
• Always inject openrouter/* first-party routers into preferred_ids so they surface even when the remote curated manifest omits them.
• Exempt openrouter/* router ids from the _openrouter_model_supports_tools() filter (they are curated entries that report empty supported_parameters).

Verify

from hermes_cli.models import fetch_openrouter_models
ids = [m for m,_ in fetch_openrouter_models(force_refresh=True)]
assert "openrouter/fusion" in ids   # was absent before, present after

# live catalog confirms why the gate hid it:
curl -s https://openrouter.ai/api/v1/models | \
  python3 -c "import sys,json;[print(m['id'],m.get('supported_parameters')) for m in json.load(sys.stdin)['data'] if 'fusion' in m['id']]"
# openrouter/fusion []   ← empty supported_parameters

Notes

• Cost transparency preserved: the picker entry is labeled "multi-model deliberation (panel + judge); priced as sum of all completions" so users know Fusion bills as the sum of every panel completion plus the judge.
• Behavior-contract friendly: the fix asserts a relationship (first-party openrouter/* routers are always offered and bypass the tool gate), not a frozen model-list snapshot.

[alt-glitch]

Related: #46064 (the bug report — OpenRouter router models silently dropped by the tool-support filter), #46067 and #47485 (competing open fix PRs for the same issue).

This is one of three open PRs surfacing openrouter/fusion in the model picker. All three target hermes_cli/models.py with the same goal (add Fusion to the curated snapshot + exempt openrouter/* routers from the tool-support gate), but via different mechanisms:

• fix(openrouter): surface router models in the picker and add Fusion #46067 introduces an explicit _OPENROUTER_TOOL_CAPABLE_ROUTERS frozenset whitelist.
• fix(models): add openrouter/fusion to model picker with router-model allowlist #47485 uses a router-model allowlist plus a catalog edit.
• This PR injects openrouter/* routers into preferred_ids and exempts them by openrouter/ prefix at the filter call site.

Marked related (not duplicate) — different mechanisms competing for the same fix. Maintainers should pick one approach.

[teknium1]

Closing in favor of #46094, which adds configurable Fusion presets as the canonical OpenRouter Fusion implementation. Thanks for the contribution — the Fusion direction is being consolidated there.