openclaw - 💡(How to fix) Fix Feature: preserve provider-level continuation for github-copilot to reduce premium request burn [1 participants]

Summary

OpenClaw already has the building blocks around session continuity, tool loops, and even previous_response_id handling on the OpenAI websocket path, but the built-in github-copilot provider still appears to send each turn as a fresh provider-level request.

This makes OpenClaw materially more expensive on GitHub Copilot premium models than OpenCode / Copilot CLI style workflows, where long tool-driven sessions can often stay within a single premium-request continuation chain.

The request is not “make sessions longer.” The request is:

please support true provider-level continuation for the github-copilot provider (or document clearly why it is impossible), so OpenClaw can minimize unnecessary premium request burn on Copilot premium models.

Why this matters

Users running OpenClaw on GitHub Copilot premium models (for example github-copilot/gpt-5.4, github-copilot/claude-opus-4.6) can see much higher premium-request consumption than they see in OpenCode / Copilot CLI for similarly long interactive coding or tool-heavy sessions.

From investigation, the likely reason is:

• Copilot premium billing is effectively sensitive to user prompt vs continuation boundaries.
• Tool calls inside one provider-level continuation do not create new premium requests.
• But OpenClaw’s github-copilot path appears to rebuild and resend each turn as a fresh /v1/responses request without preserving provider-side continuation state.

If true, OpenClaw is paying the “fresh request” cost repeatedly even when the user experience looks like one continuous session.

Related existing issues

This request seems related to, but not fully covered by:

• #37765 — previous_response_id behavior in OpenResponses API is undocumented / silently ignored
• #44948 — websocket tool-result continuation can resume a stale branch
• #18882 — Copilot premium overcount risk from X-Initiator classification on internal/synthetic requests
• various github-copilot provider issues around model support / headers / subagent behavior

Those issues cover adjacent pieces, but I do not see a single issue that frames the end-to-end problem as:

“How can OpenClaw’s built-in github-copilot provider preserve provider-level continuation strongly enough to reduce Copilot premium request consumption, closer to OpenCode / Copilot CLI behavior?”

Current observed gap

From local investigation:

1. OpenClaw has session continuity at the gateway/session layer.
2. OpenClaw has continuation logic on the OpenAI websocket path.
3. But the github-copilot provider path does not appear to reuse provider continuation in the same way.
4. Therefore a long OpenClaw chat session can still be many fresh provider requests.

This means:

• OpenClaw session continuity != Copilot premium-request continuity
• “the assistant keeps asking follow-up questions” may feel like ask_user, but billing-wise it is not equivalent unless the provider sees it as continuation

Requested outcome

Please investigate and clarify one of the following:

Option A — support it

Add proper continuation support for github-copilot, for example:

• preserve and reuse provider-side continuation state where supported
• verify whether Copilot’s responses endpoint supports previous_response_id or an equivalent mechanism
• ensure tool-result turns and internal continuations are not sent in a way that unnecessarily creates fresh premium-billed requests
• make X-Initiator / provenance / internal-vs-user classification robust enough that internal loops are not overcounted

Option B — document the limitation clearly

If the Copilot endpoint fundamentally does not support continuation in a way OpenClaw can use, please document that clearly:

• why OpenCode / Copilot CLI can appear cheaper
• why OpenClaw cannot currently match that behavior
• what users should expect in terms of premium request consumption

Suggested investigation areas

• github-copilot provider request construction
• whether provider-level continuation is possible on api.individual.githubcopilot.com/v1/responses
• interaction between tool-result loops and premium request counting
• whether subagents and synthetic/internal turns are creating new top-level billed requests
• whether current session/provenance metadata can be used to drive safer continuation decisions

Why this is worth prioritizing

This is not just a minor optimization. For users trying to use OpenClaw as their main Copilot-powered assistant, this directly affects whether the built-in github-copilot provider is economically viable.

If OpenCode can achieve meaningfully lower premium-request burn on the same GitHub Copilot account, OpenClaw users will naturally expect the same or at least want a documented explanation of the gap.