fix(copilot): derive runtime api_mode from active target model

[dandomin]

Summary

When a user switches models mid-session via /model (e.g. config default is gpt-5.5 but the active model is claude-opus-4.7-1m-internal via Copilot), _copilot_runtime_api_mode() was deriving api_mode from model_cfg["default"] or a stale persisted model.api_mode rather than the currently active model.

This caused the resolver and the normalizer to disagree on api_mode on every turn, which in turn triggered constant OpenAI client rebuilds (a fresh agent_init log line on every conversation turn) and, for some model/endpoint pairs, outright HTTP failures because Copilot serves different model families through different API surfaces:

• GPT‑5.x non‑mini / -codex → codex_responses
• GPT‑5‑mini / 4.1 / 4o / Gemini → chat_completions
• Claude → chat_completions (or anthropic_messages depending on catalog)

Fix

Thread the resolved target_model through _resolve_explicit_runtime, _resolve_runtime_from_pool_entry, and the legacy creds path into _copilot_runtime_api_mode, and have that helper prefer copilot_model_api_mode(active_model) inference over a stale configured api_mode. The configured api_mode is still honored when no target_model is supplied, so non-switching callers keep their existing behavior.

Why

The same architectural smell — "runtime routing derives api_mode from stale config / default / main model instead of the actual target / active model" — shows up in several open PRs covering different surfaces (CLI switch, gateway switch, delegation, subagents, cron). This PR fixes the CLI/runtime path specifically and is intentionally scoped to one helper + its callers so it can land independently of the broader Copilot routing cleanups.

Verification

Locally, after restarting the gateway with this patch loaded:

• A fresh session logs exactly one agent_init at session startup and zero on subsequent turns.
• Pre-patch, the same flow was logging a new OpenAI client created (agent_init, shared=True) provider=copilot ... line on every conversation turn.

Tests

Two new unit tests added to tests/hermes_cli/test_runtime_provider_resolution.py:

• test_copilot_api_mode_recomputes_from_target_model_even_with_matching_config — proves that even when the configured api_mode matches the configured provider, an explicit target_model of a different family (Claude vs. GPT‑5.x) overrides it.
• test_resolve_runtime_provider_threads_target_model_to_copilot_explicit_path — proves the non-pool / explicit Copilot resolver path also threads target_model through.

Both pass:

tests/hermes_cli/test_runtime_provider_resolution.py ..    [100%]
2 passed, 129 deselected in 0.50s

Related

Open PRs working the same area / same bug class:

• fix(copilot): honor target_model when resolving api_mode override #27267 — closest match (same helper, same fix shape)
• fix(copilot): honor token precedence and derive api_mode per target model #17622 — broader Copilot api_mode + token precedence cleanup
• fix: recompute copilot api mode from target model for subagents #24251 — subagent variant
• fix(cron): derive copilot api_mode from job model, not config default #9033 — cron variant
• fix: derive delegation api_mode from delegation model, not main model #6647 — delegation variant

Happy to rebase on or close in favor of #27267 if the maintainers prefer that landing path.

[dandomin]

Pushed a follow-up commit (f45dfe9) that threads the resolved active model into resolve_runtime_provider from the two remaining call sites:

• gateway/run.py — _resolve_runtime_agent_kwargs now accepts and forwards target_model. All four gateway call sites (build_agent, /msg runtime snapshot, gateway-model probe, model diagnostic path) pass the gateway's active model.
• cli.py — HermesCLI passes self.model when resolving runtime credentials for the interactive session.

Without these, mid-session /model switches in the gateway or CLI still hit the no-target_model path inside _copilot_runtime_api_mode and silently fall back to model_cfg['default'] — exactly the resolver/normalizer disagreement this PR eliminates everywhere else.

[alt-glitch]

Related to #17622, #6647, #9033, #27267, #24251 — same architectural pattern (stale api_mode derived from config default instead of active target model) across different entry points. This PR fixes the CLI/runtime path specifically. #6647 covers delegation, #9033 covers cron, #24251 covers subagents, #27267 covers --model CLI override.

[allenliang2022]

Confirming this also breaks the hermes-web-ui (npm) bridge path — same root cause.

Hit this on hermes-web-ui (npm): switching to github_copilot/gpt-5.5 in a fresh WebUI chat 400s with unsupported_api_for_model … not accessible via the /chat/completions endpoint, even with no model.api_mode pinned in config.

The bridge already threads the active model through correctly:
hermes_bridge.py → _resolve_runtime(model) → resolve_runtime_provider(requested="copilot", target_model=model). The target_model arrives fine — it's just dropped in the copilot branch of _resolve_runtime_from_pool_entry, so api_mode is derived from model_cfg["default"] (a Claude default here) and gpt-5.5 gets chat_completions.

Minimal repro on current main (HEAD b99c6c4), no WebUI needed:

from hermes_cli.runtime_provider import resolve_runtime_provider
rt = resolve_runtime_provider(requested="copilot", target_model="gpt-5.5")
print(rt["api_mode"])   # -> 'chat_completions'  (bug; should be 'codex_responses')

With this PR applied it returns codex_responses and the live call to Copilot succeeds.

So the impact surface is broader than CLI /model switches — CLI override (#27267), cron (#9033), delegation (#6647), subagents (#24251), and the WebUI bridge all flow through this one function. Would be great to get one of this cluster merged — it's the last blocker for using Copilot GPT-5.x from the WebUI.

[teknium1]

Thanks for isolating the active-model routing issue. The premise still holds on current main: hermes_cli/runtime_provider.py:320-335 derives Copilot mode from persisted config/default, while hermes_cli/model_switch.py:1214-1217 already passes the switched model into the resolver.

Problems

• In the pool path, the PR passes effective_model as target_model (hermes_cli/runtime_provider.py, PR line 361). effective_model falls back to model_cfg["default"], so ordinary calls without a target model no longer take the PR helper's configured-api_mode preservation branch. Pass the original target_model instead; the helper can still use model.default for inference.
• The live CLI resolver has moved to hermes_cli/cli_agent_setup_mixin.py:41-45, and current gateway session setup invokes _resolve_runtime_agent_kwargs() without its resolved model at gateway/run.py:3801. The submitted locations therefore do not cover the current CLI/gateway paths.

Suggested changes

• Port the active-model wiring to those current call sites and add a pool-path regression where target_model is omitted but model.api_mode is set.

Automated hermes-sweeper review.

[teknium1]

Please pass the original target_model here, not effective_model. effective_model falls back to model_cfg["default"], so this is non-null even when the caller supplied no target; that bypasses the helper's new configured-api_mode preservation branch and changes normal pool resolution behavior.

[teknium1]

Closing — this fix landed via PR #60086 (merged, commit 51083d2), which threads target_model through all three Copilot resolver paths with resolver-level tests. Your PR fixed the same bug; the earliest submitter (#27267) and the first complete version (#47090) are credited alongside. Thanks for the contribution!