odysseus/specs/model-providers/github-copilot.md

46 lines
1.7 KiB
Markdown

# 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.