fix(copilot): route grok-4.5 to Responses API on GitHub Copilot

[munim]

Summary

Fixes #85213 — grok-4.5 on the GitHub Copilot provider currently fails with:

HTTP 400: model "grok-4.5" is not accessible via the /chat/completions endpoint

Root cause

GitHub Copilot serves grok-4.5 exclusively on the Responses API — the live catalog advertises grok-4.5 -> ['/responses']. But Hermes' Copilot API-mode routing only routed GPT-5+ models to the Responses API. _should_use_copilot_responses_api returned True only for gpt-5+ (excluding gpt-5-mini), with every other non-GPT family hardcoded to Chat Completions. So grok-4.5 fell through to /chat/completions and was rejected.

Verified against the live catalog (GET https://api.githubcopilot.com/models):

model	supported_endpoints
grok-4.5	['/responses'] (only)
gpt-5.4	['/responses','/chat/completions','ws:/responses']
gpt-5-mini	['/chat/completions','/responses','ws:/responses']
claude-sonnet-5	['/v1/messages','/chat/completions']
gemini-3.5-flash	['/chat/completions']

Only grok-4.5 (and any future /responses-only non-GPT family) hits this bug.

Changes

1. _should_use_copilot_responses_api (hermes_cli/models.py): also return True for grok* / x-ai/grok* model IDs.
2. copilot_model_api_mode (hermes_cli/models.py): after the GPT-5 pattern check, consult the live catalog's supported_endpoints — if /responses is present and /chat/completions is absent, return codex_responses. This is authoritative and future-proof for any non-GPT /responses-only model, not just grok.

Verification

• Functional: grok-4.5 -> codex_responses; gpt-5.4 / gpt-5-mini / claude / gemini routing unchanged.
• E2E: hermes -m grok-4.5 --provider copilot -z "reply with exactly: OK" -> OK.

Note on tag

The fix commit is tagged grok-fix-85213 on the fork for traceability.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #74377 — it already implements catalog-aware Copilot routing for Responses-only models, including Grok, with the broader runtime handling.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(copilot): route grok-4.5 to Responses API on GitHub Copilot

Correct direction — grok is Responses-only on Copilot today, and the catalog fallback is the right authoritative check. Observations:

1. The grok prefix heuristic bypasses the authoritative catalog. _should_use_copilot_responses_api returns True for any grok-prefixed id, so copilot_model_api_mode never consults supported_endpoints for those models. If a future grok variant is served only on /chat/completions (the catalog would say so), the heuristic still forces Responses — the exact opposite of this fix's intent. Consider consulting the catalog first for grok-named models and using the prefix check only when the catalog doesn't list the id.
2. Endpoint string matching is exact. The fallback matches the literal "/responses" and requires "/chat/completions" absent from the same set. If the catalog ever reports /v1/responses or a trailing-slash variant, the check silently misses and the model falls through to chat completions — the precise failure this PR fixes. Normalizing endpoint strings (strip leading /v1, trailing /) would harden it.
3. Minor: model_id.lower().startswith("grok") also matches e.g. grokfoo-1; harmless today, but a stricter prefix (grok-, x-ai/grok, or a word-boundary) avoids accidental future matches. The isinstance(catalog, list) guard is fine given the list[dict[str, Any]] parameter type.

[arminanton]

Nice fix — the catalog-driven fallback here ("/responses" in endpoints and "/chat/completions" not in endpoints -> codex_responses) is the right general shape, and worth noting it already covers more than grok on this account.

Live-probed api.githubcopilot.com/models today (2026-08-21):

grok-4.5                -> ['/responses']
grok-4.6                -> ['/responses']
mai-code-1.1-flash      -> ['/responses']
mai-code-1-flash-picker -> ['/responses']

So the catalog branch routes grok-4.6 and the mai-code-* family correctly too, no per-family prefix needed. The explicit startswith("grok") guard is still a good offline safety net for when the catalog probe is cold, but the generic endpoint check is what makes this future-proof. LGTM.

[Jeremygarden]

please get this merged to enable grok working.