Prerequisites
Bug Description
Fallback chains in model-requirements.ts include github-copilot as a provider, but the model IDs used don't match what GitHub Copilot actually serves. This causes the resolution to silently skip copilot and fall through to lower-quality free models.
Example — sisyphus fallback chain:
{ providers: ["anthropic", "github-copilot", "opencode"], model: "claude-opus-4-6", variant: "max" },
{ providers: ["kimi-for-coding"], model: "k2p5" },
{ providers: ["opencode"], model: "kimi-k2.5-free" },
{ providers: ["zai-coding-plan"], model: "glm-4.7" },
{ providers: ["opencode"], model: "glm-4.7-free" }, // ← lands here
The chain references claude-opus-4-6 but copilot serves it as claude-opus-4.6 (dot, not hyphen). The model resolution can't match, skips github-copilot, and falls all the way to glm-4.7-free.
Copilot model catalog (from opencode models):
github-copilot/claude-haiku-4.5
github-copilot/claude-opus-4.5
github-copilot/claude-opus-4.6
github-copilot/claude-opus-41
github-copilot/claude-sonnet-4
github-copilot/claude-sonnet-4.5
Fallback chain model IDs:
claude-opus-4-6 → copilot has claude-opus-4.6 (dot)
claude-sonnet-4-5 → copilot has claude-sonnet-4.5 (dot)
claude-haiku-4-5 → copilot has claude-haiku-4.5 (dot)
Steps to Reproduce
- Connect only
github-copilot (no anthropic provider)
- Start a session — sisyphus should use
github-copilot/claude-opus-4-6 per fallback chain
- Observe it falls through to
glm-4.7-free instead
Expected Behavior
When anthropic is unavailable, the fallback chain should resolve to github-copilot/claude-opus-4.6 (or whatever the correct copilot model ID is).
Actual Behavior
Model resolution silently skips github-copilot due to ID mismatch and falls through to much lower-quality free models.
Impact
This affects every fallback chain that lists github-copilot alongside anthropic Claude models — which is most agents and categories. Users who rely on copilot (e.g. Copilot Pro+ subscribers without an Anthropic API key) silently get degraded model quality with no indication of why.
Suggested Fix
Either:
- Normalize model IDs during resolution (treat hyphens and dots as equivalent for version numbers)
- Update fallback chain model IDs to match what copilot actually serves
- Add provider-specific model ID aliases
Additional Context
Discovered while trying to use github-copilot as the sole Claude provider (anthropic disconnected). All copilot Claude entries in the fallback chains are affected.
Prerequisites
Bug Description
Fallback chains in
model-requirements.tsincludegithub-copilotas a provider, but the model IDs used don't match what GitHub Copilot actually serves. This causes the resolution to silently skip copilot and fall through to lower-quality free models.Example — sisyphus fallback chain:
The chain references
claude-opus-4-6but copilot serves it asclaude-opus-4.6(dot, not hyphen). The model resolution can't match, skipsgithub-copilot, and falls all the way toglm-4.7-free.Copilot model catalog (from
opencode models):Fallback chain model IDs:
Steps to Reproduce
github-copilot(noanthropicprovider)github-copilot/claude-opus-4-6per fallback chainglm-4.7-freeinsteadExpected Behavior
When
anthropicis unavailable, the fallback chain should resolve togithub-copilot/claude-opus-4.6(or whatever the correct copilot model ID is).Actual Behavior
Model resolution silently skips
github-copilotdue to ID mismatch and falls through to much lower-quality free models.Impact
This affects every fallback chain that lists
github-copilotalongside anthropic Claude models — which is most agents and categories. Users who rely on copilot (e.g. Copilot Pro+ subscribers without an Anthropic API key) silently get degraded model quality with no indication of why.Suggested Fix
Either:
Additional Context
Discovered while trying to use
github-copilotas the sole Claude provider (anthropic disconnected). All copilot Claude entries in the fallback chains are affected.