-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Prefer native Responses API compaction when available #2558
Description
Describe the feature or problem you'd like to solve
I've been trying to understand how long sessions behave in Copilot CLI, especially once /compact or auto-compaction kicks in.
Right now, it seems like compaction goes through Copilot CLI's own summary/checkpoint flow even when the active model is OpenAI-backed and already using the Responses stack. I'd love to see the CLI prefer native Responses API compaction in those cases, and only fall back to the current Copilot compaction when native support is not available.
Proposed solution
If the selected provider/model supports native compaction through the Responses API, use that path by default. If not, keep the current Copilot compaction as the fallback.
That feels like the best of both worlds: the current implementation keeps working everywhere, but OpenAI-backed sessions can preserve more of the provider's native behavior during very long runs.
A small config switch would also be nice, something along the lines of auto | native | copilot, but even just making auto prefer native compaction would already be a big improvement.
Example prompts or workflows
- Long debugging sessions with lots of shell commands, edits, and tool calls
- Extended GPT-5 / Codex workflows where
/compactmay run more than once - Research-heavy sessions that build up a lot of intermediate state over time
- Comparing the same workflow between Copilot CLI and other Responses-based harnesses
Additional context
This is not a request to remove the current compaction/checkpoint system. That still makes sense as a universal fallback.
The request is mainly about letting OpenAI-backed sessions take advantage of provider-native compaction when it's already available.