GitHub Copilot Provider Shape

Last updated: dev@e57f60b | 2026-07-20

Scope

Canonical provider ID copilot; OpenAI-compatible chat with Copilot headers and OAuth; runtime adapter src/copilot.py and routes in routes/copilot_routes.py. There is no dedicated Copilot canonical reader on current dev.

Catalog Shape

The observed Copilot /models response uses data[] entries with:

id;
model_picker_enabled;
capabilities.supports.tool_calls and .vision;
optional limit/family metadata.

Runtime model discovery uses picker state for availability. The canonical reader package does not map the nested support fields; an explicitly supplied copilot vendor currently uses generic identity-only normalization, and model_picker_enabled does not become canonical capability.

Request And Response Shape

Chat is OpenAI-compatible but requires Copilot/GitHub API version, editor/plugin identity, intent, integration, and initiator headers; image requests add the vision request flag. Header derivation must tolerate malformed message entries. OAuth token exchange and access policies are provider authentication, not model capability.

Fallback And Safety

Use exact GitHub Copilot host or explicit kind, including the constrained enterprise copilot-api.*.ghe.com form. Do not treat arbitrary ghe.com hosts as Copilot. Official model availability tables are useful registry context but do not replace the account-scoped catalog response.

Current Gaps

The catalog shape is implementation-observed and needs ongoing fixture comparison with current Copilot clients.
Copilot catalog capability fields are not normalized by current dev.
Account/plan/policy availability must remain endpoint-user scoped.

1.7 KiB Raw Blame History