You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The hardcoded _PROVIDER_MODELS["xai"] list in hermes_cli/models.py is stale, and the pattern of hardcoded per-provider model lists is structurally fragile across the file.
Concretely:
# hermes_cli/models.py (current main: 4a9ac5c3)_PROVIDER_MODELS: dict[str, list[str]] = {
...
"xai": [
"grok-4.20-reasoning", # ← xAI no longer accepts this name"grok-4-1-fast-reasoning", # ← never existed in xAI's catalog
],
...
}
xAI's actual current model IDs (per models.dev cache, fetched today) use date-suffixed names like grok-4.20-0309-reasoning, grok-4.20-0309-non-reasoning, grok-4.20-multi-agent-0309. None of those match the hardcoded list.
Reproduction
Configure xAI provider via env: XAI_API_KEY=…
Run hermes and select xAI from /model picker
Picker shows only the 2 stale entries; selecting either yields:
HTTP 400: Unknown Model, please check the model code.
_PROVIDER_MODELS hardcodes per-provider lists that don't track upstream catalogs. Of the ~15 providers in this dict, only openai-codex is currently sourced dynamically (_codex_curated_models(), added in PR #7844 to fix the analogous bug #6595). Every other provider — xai, nous, openai, copilot, gemini, zai, nvidia, kimi-coding, stepfun, moonshot, minimax, minimax-cn, etc. — keeps drifting silently.
Short-term: apply the _codex_curated_models() pattern to xai (and the other most-active providers). For xai specifically, derive from the existing models_dev_cache.json that hermes already maintains:
```python
def _xai_curated_models() -> list[str]:
import json, os
cache = os.path.expanduser("~/.hermes/models_dev_cache.json")
try:
if os.path.isfile(cache):
with open(cache) as fh:
data = json.load(fh)
ids = list(data.get("xai", {}).get("models", {}).keys())
if ids:
return sorted(ids)
except Exception:
pass
return [...static fallback...]
Longer-term: the pattern of per-provider helpers will keep growing. Worth considering a single _provider_models(provider: str) resolver that:
Reads models_dev_cache.json for any provider available there (covers most),
Falls back to provider-specific helpers (e.g. _codex_curated_models) where the cache isn't authoritative,
Falls back to a small per-provider static list only as a last resort.
Related: the model-allowlist feature request #16608 would let users opt into a known-good subset rather than relying on the curation embedded in source.
Workaround
Patch locally by replacing the xai literal with a _xai_curated_models() helper modeled on _codex_curated_models(). We're maintaining a small Ansible playbook that re-applies this on each managed-host install; happy to share if helpful.
Environment
Hermes Agent main @ 4a9ac5c3 (2026-04-27)
Python 3.12, Ubuntu 24.04 LTS
Provider: xAI direct (XAI_API_KEY, https://api.x.ai/v1)
Summary
The hardcoded
_PROVIDER_MODELS["xai"]list inhermes_cli/models.pyis stale, and the pattern of hardcoded per-provider model lists is structurally fragile across the file.Concretely:
xAI's actual current model IDs (per
models.devcache, fetched today) use date-suffixed names likegrok-4.20-0309-reasoning,grok-4.20-0309-non-reasoning,grok-4.20-multi-agent-0309. None of those match the hardcoded list.Reproduction
XAI_API_KEY=…hermesand select xAI from/modelpickerSame shape as the open Z.AI bug #7922.
Root cause
_PROVIDER_MODELShardcodes per-provider lists that don't track upstream catalogs. Of the ~15 providers in this dict, onlyopenai-codexis currently sourced dynamically (_codex_curated_models(), added in PR #7844 to fix the analogous bug #6595). Every other provider —xai,nous,openai,copilot,gemini,zai,nvidia,kimi-coding,stepfun,moonshot,minimax,minimax-cn, etc. — keeps drifting silently.The drift surfaces in two places:
/modelpicker (this issue, also Bug: Duplicate provider entries in /model picker #14057, Missing GPT-5.5 model support across provider catalog, Codex image-gen default, tests, and docs #16161)detect_provider_for_model()validation, which uses_PROVIDER_MODELSmembership and emits "Could not reach … to validate" warnings for any model not in the curated list (same false-warning bug as [Bug] Telegram /model picker missing gpt-5.4 for openai-codex provider (stale _PROVIDER_MODELS hardcoded list) #6595).Suggested fix
Short-term: apply the
_codex_curated_models()pattern toxai(and the other most-active providers). Forxaispecifically, derive from the existingmodels_dev_cache.jsonthat hermes already maintains:```python
def _xai_curated_models() -> list[str]:
import json, os
cache = os.path.expanduser("~/.hermes/models_dev_cache.json")
try:
if os.path.isfile(cache):
with open(cache) as fh:
data = json.load(fh)
ids = list(data.get("xai", {}).get("models", {}).keys())
if ids:
return sorted(ids)
except Exception:
pass
return [...static fallback...]
_PROVIDER_MODELS["xai"] = _xai_curated_models()
```
Longer-term: the pattern of per-provider helpers will keep growing. Worth considering a single
_provider_models(provider: str)resolver that:models_dev_cache.jsonfor any provider available there (covers most),_codex_curated_models) where the cache isn't authoritative,Related: the model-allowlist feature request #16608 would let users opt into a known-good subset rather than relying on the curation embedded in source.
Workaround
Patch locally by replacing the
xailiteral with a_xai_curated_models()helper modeled on_codex_curated_models(). We're maintaining a small Ansible playbook that re-applies this on each managed-host install; happy to share if helpful.Environment
4a9ac5c3(2026-04-27)XAI_API_KEY,https://api.x.ai/v1)References