Add a Copilot `/responses` transport so Responses-only ids like `grok-4.6` are reachable through `github-copilot:`

[dsfaccini]

This issue was posted by Claude Code using claude-fable-5-1 on behalf of David.

github-copilot:<id> always builds GitHubCopilotModel, an OpenAIChatModel subclass, so it reaches only the ids whose Copilot catalog entry lists /chat/completions under supported_endpoints. Every other id — all of xAI's Grok, the GPT-5.5/5.6/6 line, gpt-5.3-codex, Microsoft's mai-code-* — is served on /responses alone and answers 400 unsupported_api_for_model.

Evidence

• tests/models/test_github_copilot.py::test_github_copilot_responses_only_model — strict xfail(raises=ModelHTTPError) added in Add a GitHubCopilotProvider for GitHub Copilot's OpenAI-compatible API #8059, reason: "Blocked on a Copilot /responses transport … An XPASS means the Responses transport landed." Its cassette records the live body:

  {"error":{"message":"model \"gpt-5.6-luna\" is not accessible via the /chat/completions endpoint","code":"unsupported_api_for_model"}}

• docs/models/github-copilot.md already tells users the gap exists: "unsupported_api_for_model — the model exists but isn't served on Chat Completions. Pydantic AI does not yet speak Copilot's Responses API, so these ids … are unreachable for now."

• Live GET https://api.githubcopilot.com/models on 2026-09-08, with the headers GitHubCopilotProvider sends (Copilot-Integration-Id: vscode-chat included, which the listing depends on): 51 ids, 23 list /chat/completions, 11 list /responses without it.

The 11 Responses-only ids, 2026-09-08

id	vendor	supported_endpoints
gpt-5.3-codex	OpenAI	/responses, ws:/responses
gpt-5.4-mini	OpenAI	/responses, ws:/responses
gpt-5.5	OpenAI	/responses, ws:/responses
gpt-5.6-luna	OpenAI	/responses, ws:/responses
gpt-5.6-sol	OpenAI	/responses, ws:/responses
gpt-5.6-terra	OpenAI	/responses, ws:/responses
gpt-6-astra	OpenAI	/responses, ws:/responses
grok-4.5	xAI	/responses
grok-4.6	xAI	/responses
mai-code-1-flash-picker	Microsoft	/responses
mai-code-1.1-flash	Microsoft	/responses

A further 17 entries (the legacy gpt-3.5/gpt-4/gpt-4o ids and the three text-embedding-* ids) carry no supported_endpoints key at all. Separate question, not this one.

Which ids appear is per-subscription and moves over time — this is one plan's listing on one day, not a fixed set.

End state

The xfail asserts it directly: a run through github-copilot: against a Responses-only id returns output instead of raising ModelHTTPError. xfail_strict is on, so the fix surfaces as a reported XPASS.

Design note — the routing question is the open part

The transport itself has an obvious shape: a Responses-side sibling of GitHubCopilotModel, i.e. an OpenAIResponsesModel subclass used with provider='github-copilot', the way OpenAICodexModel subclasses OpenAIResponsesModel for a Responses-dialect provider.

What needs a maintainer decision is how github-copilot:<id> picks a transport. models/__init__.py::infer_model maps the prefix to GitHubCopilotModel unconditionally, so github-copilot:grok-4.6 has no way to land on the Responses side. The catalog does expose supported_endpoints per id, but reading it means a network call before the first request, and it is per-subscription. A second prefix, a catalog lookup, and "construct the Responses class explicitly" are all defensible; picking one is the decision.

Not in scope: a KnownModelName catalog. #8059 deliberately ships none, because availability is per subscription and the listing changes.

Unverified and worth checking first: whether Copilot's /responses envelope needs a repair like the one GitHubCopilotModel._validate_completion performs for Chat Completions (Copilot omits object, and per-choice index on Anthropic ids).

Where

• pydantic_ai_slim/pydantic_ai/models/github_copilot.py — GitHubCopilotModel
• pydantic_ai_slim/pydantic_ai/models/__init__.py — infer_model
• pydantic_ai_slim/pydantic_ai/providers/github_copilot.py — GitHubCopilotProvider
• docs/models/github-copilot.md

Background: #8057, implemented in #8059.