Skip to content

Automatic compaction repeatedly times out at 300s until sessions hit the hard context limit (1.0.91) #5292

Open

Description

@zcodegit

Describe the bug

Automatic compaction repeatedly fails with a 300-second summarizer timeout. The conversation keeps growing until Copilot CLI rejects requests because they exceed the model's context limit. The error recommends retrying compaction, but automatic compaction and the context-limit retry have both already timed out.

I have been encountering this across my Copilot sessions, not just once. The detailed counts below were verified in one affected long-running session; the cross-session recurrence is my user report, not a count of all sessions.

Exact blocking error:

Execution failed: Automatic compaction timed out and the request still exceeds the model's context limit (555009 tokens; limit 553200). Reduce context or retry compaction before continuing.

Affected version

GitHub Copilot CLI 1.0.91. This version is recorded in the affected session's startup event and confirmed by copilot --version.

Steps to reproduce the behavior

  1. Use a long-running interactive Copilot CLI session with a large context. The inspected session uses GPT-6.1 Sol (gpt-6.1-sol), long_context, and reasoning effort max; the footer reports a 1.1M context.
  2. Continue normal work until automatic compaction triggers.
  3. Observe repeated session.compaction_complete events with success: false and the error shown below.
  4. Continue working/retrying. Eventually a request fails with the hard context-limit error above, leaving the session unable to continue that request without intervention.

This is an observed failure sequence from a real session, not a minimal synthetic reproducer.

Expected behavior

Automatic compaction should reliably reduce the conversation before requests exceed their effective context budget. If summarization cannot finish within its time budget, the CLI should provide a viable non-destructive recovery path rather than repeatedly discarding summaries and eventually blocking the session. Compaction accounting and the effective request budget should be coordinated so the session does not require manual rescue.

Additional context

Environment: Linux x86_64, bash, tmux 3.4. The affected session had been running for approximately eight days.

The initial diagnostic snapshot, before recovery was attempted, contained 192 completed compaction attempts: 15 successful and 177 failed. Of the failures, 175 had exactly this error:

automatic compaction summarizer did not settle within 300s of starting; pending summary discarded

The other two failures were a connection timeout and an authentication error, so they are not included in the 175 summarizer-timeout count.

Selected sanitized events, all on 2026-10-29 UTC:

04:29:36.426 session.compaction_complete
  success=true, trigger=threshold
  preCompactionTokens=738110, postCompactionTokens=70850
  messagesRemoved=951, tokenLimit=922000

18:04:48.304 session.compaction_start
  trigger=threshold, currentTokens=882584, tokenLimit=922000
18:09:48.324 session.compaction_complete
  success=false, trigger=threshold, tokenLimit=922000
  error="automatic compaction summarizer did not settle within 300s of starting; pending summary discarded"
18:09:49.919 session.error
  errorType=query
  message="Execution failed: Automatic compaction timed out and the request still exceeds the model's context limit (555009 tokens; limit 553200). Reduce context or retry compaction before continuing."

18:15:18.083 session.compaction_start
  trigger=context_limit_retry, currentTokens=709698, tokenLimit=922000
18:20:18.139 session.compaction_complete
  success=false, trigger=context_limit_retry, tokenLimit=922000
  error="automatic compaction summarizer did not settle within 300s of starting; pending summary discarded"

The compaction events report tokenLimit=922000, while the blocking request reports limit 553200. These are the recorded values; I have not established why the budgets differ. Earlier failures in the same session also reported 553294 / 553200 and 646726 / 645400 tokens.

Related: #5054 describes the same 300-second timeout. This report adds a Linux reproduction with repeated hard context-limit failures, a failed context_limit_retry recovery, and a successful manual compaction that took longer than the automatic timeout.

Manual recovery result

Once the active inference was cancelled and the session was idle, the built-in /compact command succeeded without changing the model or reasoning setting, restarting the process, or manually editing session history:

18:29:34.652 session.compaction_start
  trigger=manual, currentTokens=718298
18:36:47.985 session.compaction_complete
  success=true, trigger=manual, tokenLimit=922000
  preCompactionTokens=687202, postCompactionTokens=15751
  messagesRemoved=1665, checkpointNumber=16

The successful manual compaction took 433.333 seconds (7 minutes 13 seconds), exceeding the automatic summarizer's 300-second deadline. Its checkpoint was persisted. Afterwards, /context showed 78k / 1050k tokens (7%), and the original process resumed its existing work. This is a recovery workaround, not a fix for the recurring automatic timeout.

No conversation contents, source code, credentials, private repository names, or full diagnostic logs are included in this report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:context-memoryContext window, memory, compaction, checkpoints, and instruction loading

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions