openclaw - 💡(How to fix) Fix [Bug]: github-copilot provider fails for OpenAI-family models (gpt-5.x): "no model endpoints available" + auth profile cooldown [1 comments, 2 participants]

Summary

On OpenClaw 2026.4.21, routing OpenAI-family models (gpt-5.x) through the github-copilot provider fails with a generic 400 from Copilot's scheduler:

400 building HTTP client: selecting model endpoint:
scheduler enqueue for model endpoint selection:
no model endpoints available given user constraints

The root cause appears to be the same class of bug tracked in the now-closed #17508: OpenClaw sends a Claude-shaped anthropic-messages payload (with content: [{type: "text", text: "..."}] arrays) to Copilot's GPT endpoint, which requires OpenAI Chat Completions shape (content: "..." string). Copilot rejects it but surfaces a vague "no model endpoints available" error rather than the underlying messages[1].content must be a string or null that #17508 captured at the proxy layer.

Per docs.openclaw.ai/providers/github-copilot:

Claude model IDs use the Anthropic Messages transport automatically. GPT, o-series, and Gemini models keep the OpenAI Responses transport. OpenClaw selects the correct transport based on the model ref.

In practice, on 4.21, the per-model-ref transport dispatch is not kicking in for github-copilot/gpt-5.4 (and by implication other gpt-5.x / o-series IDs) — the anthropic-messages transport is used regardless.

Like #70322, this failure also poisons the auth profile into cooldown, so one bad GPT request takes the whole provider down until cooldown clears.

Observed

• OpenClaw 2026.4.21 on Linux
• Provider github-copilot (native device-login flow, baseUrl https://api.githubcopilot.com)
• Model refs tried: github-copilot/gpt-5.4, github-copilot/gpt-5.4-mini
• Account: individual GitHub Copilot with Copilot Pro+ (gpt-5.2, gpt-5.2-codex, gpt-5.3-codex, gpt-5.4, gpt-5.4-mini, gpt-5-mini, claude-*, etc. all exposed on /models)
• Provider config left at defaults; no explicit models.providers.github-copilot.api override required to reproduce (and setting api: "anthropic-messages" does not change the failure mode for these model IDs — which itself is a clue the per-ref dispatch isn't happening).

Repro

1. openclaw models auth login-github-copilot (device flow, confirm profile works for Claude models first)
2. Set any agent's primary to github-copilot/gpt-5.4 (e.g. via agents.list[].model.primary in openclaw.json, hot-reload)
3. Send that agent any message.
4. Gateway logs show:

[diagnostic] lane task error: lane=main error="FailoverError:
  HTTP 400 building HTTP client: selecting model endpoint:
  scheduler enqueue for model endpoint selection:
  no model endpoints available given user constraints"
[model-fallback/decision] decision=candidate_failed
  requested=github-copilot/gpt-5.4 reason=format
  next=<fallback>

1. Subsequent requests on the same profile hit No available auth profile for github-copilot (all in cooldown or unavailable) for the cooldown window — same poisoning pattern as #70322.

Expected

Per the docs: github-copilot/gpt-5.4 (and other non-Claude IDs) should automatically use OpenAI Responses / Chat Completions transport with string-content messages. Either:

• The model-ref dispatch needs to actually pick the OpenAI transport for gpt-* / o* / gemini-* IDs, or
• If the OpenAI transport is already selected, the payload serializer for outgoing Copilot requests needs to produce OpenAI-shape content (string), not Anthropic-shape content (array of {type, text} blocks).

Until then, the only Copilot models that reliably work are the Claude family (sonnet-4.6, haiku-4.5, opus-4.7 — the latter only after resolving #70322 or forcing /thinking medium).

Workarounds currently in place

• Primary on github-copilot/claude-sonnet-4.6 (Anthropic transport, fine).
• Fallback on openai-codex/gpt-5.4 (direct OpenAI Codex provider — works perfectly, confirming the bug is specifically in the Copilot ↔ OpenAI-family transport path, not in the upstream API or the model itself).
• Avoid github-copilot/gpt-* in any primary or fallback chain to prevent auth-profile poisoning cascades.

Related

• #17508 — original "Copilot-proxy models usage" report (same class of bug, at a different entry point via the copilot-proxy VS Code extension; closed due to inactivity without a fix shipping for the native github-copilot provider)
• #70322 — adjacent Copilot-side bug where claude-opus-4.7 rejects output_config.effort="low" and poisons the same auth profile
• #60174 — Copilot-side Anthropic transport / prompt caching fix (scope: Claude IDs, not the OpenAI-family side)

Happy to capture on-wire payloads if useful — let me know what format you'd want them in.