[gongpx20069]

Problem

Calling GitHub Copilot with gpt-5.* / o* models (e.g. github_copilot/gpt-5.4, github_copilot/gpt-5.4-mini) failed with a chain of misleading errors:

1. Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead.
2. model "gpt-5.4-mini" is not accessible via the /chat/completions endpoint (unsupported_api_for_model)
3. The requested model is not supported. (model_not_supported) even after routing to /responses

Each error masked the next, making it impossible to use any GPT-5/o-series model through the GitHub Copilot backend.

Root causes

• max_tokens parameter: The github_copilot ProviderSpec did not opt into supports_max_completion_tokens, so _build_kwargs always sent the legacy max_tokens parameter that GPT-5/o-series reject.
• Wrong endpoint: _should_use_responses_api was hard-gated to spec.name == "openai" plus a direct-OpenAI base URL, so the GitHub Copilot backend always went through /chat/completions even for models the Copilot gateway exposes only via /responses (e.g. gpt-5.4-mini, gpt-5.*-codex).
• Silent fallback hid real errors: When /responses failed on github_copilot, the existing "compatibility marker" heuristic silently fell back to /chat/completions — which can never succeed for these models — so the real upstream error was hidden.
• Model prefix not stripped on /responses: _build_responses_body did not honour spec.strip_model_prefix, so the request body sent model="github_copilot/gpt-5.4-mini" (with the routing prefix), which the Copilot gateway rejects with model_not_supported. (_build_kwargs already stripped it; this branch was missed.)

Fix

nanobot/providers/registry.py

• Set supports_max_completion_tokens=True on the github_copilot spec so requests use max_completion_tokens.

nanobot/providers/openai_compat_provider.py

• _should_use_responses_api now also allows the github_copilot spec, and skips the direct-OpenAI base check for it (the Copilot gateway is its own base URL).
• _build_responses_body now strips the model routing prefix when spec.strip_model_prefix is set, matching _build_kwargs.
• chat / chat_stream no longer fall back from /responses to /chat/completions on the github_copilot spec: the fallback cannot succeed for GPT-5/o-series and would mask the real gateway error.

Tests

• tests/cli/test_commands.py: switched the test_github_copilot_provider_refreshes_client_api_key_before_chat fixture model from gpt-5.1 to gpt-4 so it continues to exercise the /chat/completions code path it was designed for (gpt-5.1 now correctly routes to /responses on github_copilot).

• pytest tests/providers/ tests/cli/test_commands.py — 314 passed.

• Verified end-to-end against the live Copilot gateway with all GPT-5 family models:

  Model	Endpoints exposed by Copilot	Result
  gpt-5-mini	chat + responses	✅
  gpt-5.2	chat + responses	✅
  gpt-5.4	chat + responses	✅
  gpt-5.4-mini	responses only	✅
  gpt-5.2-codex	responses only	✅
  gpt-5.3-codex	responses only	✅

[gongpx20069]

Hi @Re-bin could you help review this PR? the nanobot won't work by gpt-5x models of gh copilot provider without the fix. Thanks