Peixian Gong dd26b4407d fix(providers): make GitHub Copilot backend work with GPT-5/o-series models ...

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.

Root causes (each one masked the next):

  * 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.
  * `_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`).
  * When /responses did fail 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.
  * `_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:

  * registry.py: set `supports_max_completion_tokens=True` on the
    `github_copilot` spec so requests use `max_completion_tokens`.
  * 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 both
    `github_copilot/gpt-5.4` and `github_copilot/gpt-5.4-mini`.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

2026-04-22 14:28:19 +08:00

..

test_cli_input.py

test(cli): lock _render_interactive_ansi force_terminal to isatty

2026-04-22 13:12:29 +08:00

test_commands.py

fix(providers): make GitHub Copilot backend work with GPT-5/o-series models

2026-04-22 14:28:19 +08:00

test_restart_command.py

test: speed up cron and restart timing tests

2026-04-19 12:35:57 +00:00

test_safe_file_history.py

refactor: move SafeFileHistory to module level + add regression tests

2026-04-07 13:57:34 +08:00