CLI sends wrong model ID to custom OpenAI-compatible endpoint, killing the session

[arisng]

Bug Report: CLI sends wrong model ID to custom OpenAI-compatible endpoint

Describe the bug

When using a custom OpenAI-compatible endpoint with a non-OpenAI model name (e.g. mimo-v2.5), the CLI sends gpt-5.4-nano as the model in the API request body instead of the configured model name. The custom endpoint rejects the unknown model with HTTP 401, retries exhaust, and the session terminates.

Affected version

1.0.82 (output of copilot --version)

Steps to reproduce the behavior

1. Configure a custom OpenAI-compatible endpoint with a non-OpenAI model name (e.g. mimo-v2.5) as the session model
2. Start or resume a Copilot CLI session targeting that endpoint
3. Send any prompt (e.g. hello)
4. The session fails within seconds

Expected behavior

The CLI should send the configured model name (e.g. mimo-v2.5) in the model field of the API request body, without internal substitution.

Observed behavior

The session event log shows the model field is overridden to gpt-5.4-nano before the API call:

model_call_started → "model":"gpt-5.4-nano"   (expected: "mimo-v2.5")
model_call_failure → HTTP 401, body: "Model gpt-5.4-nano is not supported"
turn_retry         → reason: "transient_auth_error"
session.error      → "Failed to get response from the AI model;
                      retried 5 times (total retry wait time: 31.26 seconds)
                      Last error: 500 Internal server error"

Note: The retry log shows 3 logged retries but the session error reports 5 total — some retries may have occurred before logging began.

Additional context

• The endpoint's GET /v1/models lists mimo-v2.5 as available
• Direct API call with "model":"mimo-v2.5" → HTTP 200 (works)
• Direct API call with "model":"gpt-5.4-nano" → HTTP 401 (model does not exist on this endpoint)
• gpt-5.4-nano is an OpenAI model — it appears the CLI maps unrecognized model names to gpt-5.4-nano before sending, which breaks custom endpoints that don't host that model
• The HTTP 401 comes from the custom endpoint; the final HTTP 500 comes from the CLI's retry layer after all attempts are exhausted
• OS: Windows, PowerShell

[seven7763]

The retry log discrepancy aside, the model-name mapping is the real issue here: a client-side fallback that rewrites an explicitly configured model id breaks the endpoint contract — the custom endpoint is the source of truth for what ids exist (its GET /v1/models already lists mimo-v2.5), so any local "unrecognized name → default model" rewrite guarantees this failure mode for every non-OpenAI endpoint.

Workaround that keeps sessions alive while this is open: pin the model id exactly as the endpoint reports it, and verify with a direct call before entering a session:

# confirm what the endpoint will accept
curl.exe -s https://<endpoint>/v1/models -H "Authorization: Bearer $env:KEY"
# confirm the exact id answers
curl.exe -s https://<endpoint>/v1/chat/completions -H "Authorization: Bearer $env:KEY" -H "Content-Type: application/json" -d '{\"model\":\"mimo-v2.5\",\"messages\":[{\"role\":\"user\",\"content\":\"ping\"}]}'

If the session still rewrites the id after that, it's the CLI's mapping layer, not the endpoint — worth adding the request/response pair from the failing session to this issue so maintainers can see the rewrite happen.

FWIW I run an OpenAI-compatible gateway, so I've seen this exact class of failure from the endpoint side — the fix belongs in the client (honor the configured id verbatim or fail loudly), not in endpoint compat shims.

[metrofun]

There is also a gateway-side workaround for this class of bug while the CLI fix is pending.

If Copilot insists on sending:

"model": "gpt-5.4-nano"

an intermediary can treat that as a logical route rather than the upstream model identity and rewrite it to the actual configured model:

Copilot → gpt-5.4-nano → Swobu → mimo-v2.5 → upstream

swobuforge/swobu can do this model/route indirection, so the upstream never has to pretend it serves gpt-5.4-nano.

This obviously shouldn't replace the CLI fix — an explicitly configured BYOK model ID should be opaque and passed through verbatim. It also only fixes the transport side; if Copilot derives model-specific capabilities from the substituted ID internally, those could still be wrong.

But it gives affected users a way to keep the session running, and putting a gateway in between also makes it trivial to verify exactly which model ID is arriving on the wire.