Skip to content

Bug: Context compaction causes an infinite resend loop when an attached file exceeds the context limit #51346

New issue
New issue
Closed as not planned
Closed as not planned
Bug: Context compaction causes an infinite resend loop when an attached file exceeds the context limit#51346
Assignees
jlongster

Description

@Lead-Byte
Lead-Byte
opened on Sep 25, 2026

Description

When submitting a prompt with an attached file that exceeds the model's context limit — either by itself or together with the existing conversation context — OpenCode compacts the context and resubmits the request.

Instead of stopping and reporting that the request still exceeds the context limit, OpenCode appears to repeat this process in a loop:

  1. Send the prompt and attached file.
  2. The request exceeds the context limit.
  3. OpenCode compacts the context.
  4. OpenCode resubmits the same request, including the oversized attachment.
  5. The request exceeds the context limit again.
  6. The process repeats.

This can consume the entire token budget without producing a response.

Steps to reproduce

  1. Start a conversation with enough existing context to significantly reduce the remaining context window.
  2. Submit a prompt with a large file attachment.
  3. Ensure that the combined prompt, conversation history, and attachment exceed the model's context limit.
  4. Observe the automatic context compaction and retry behavior.

Expected behavior

OpenCode should detect that the request still exceeds the context limit after compaction and stop retrying.

It should instead:

  • Abort the request safely.
  • Display a clear error message.
  • Explain that the attached file or combined context is too large.
  • Avoid repeatedly resending the same oversized request.
  • Preserve the remaining token budget where possible.

Possible recovery options could include:

  • Asking the user to remove or reduce the attachment.
  • Offering to summarize or process the file in chunks.
  • Asking whether older conversation context may be discarded.
  • Retrying only if the request size has actually been reduced.

Actual behavior

OpenCode repeatedly compacts and resends the request while the oversized attachment remains part of the request.

This creates a retry loop and consumes all available tokens without completing the request.

Impact

This is potentially very expensive and can exhaust the complete token budget of a session. It also provides no useful result and gives the user no opportunity to intervene.

Suggested fix

Add a guard around automatic context-compaction retries:

  • Track the effective request size after each compaction.
  • Detect whether compaction actually reduced the request below the context limit.
  • Detect repeated retries with equivalent request content.
  • Set a strict maximum number of compaction retries.
  • Abort with a user-visible error if the request remains too large.
  • Do not count failed retry attempts against the user's token budget, if possible.

A message such as the following would be helpful:

The request is still too large after context compaction. The attached file exceeds the available context window. Please remove the attachment, reduce its size, or ask OpenCode to process it in smaller parts.

Environment

  • OpenCode version: v1.18.32
  • Interface: Desktop
  • Attachment type and approximate size: filetype: json 2MB
  • model: GPT-6 Astra low
  • context limit of the used model: 1'050'000

Activity

  1. github-actions
    assigned
    jlongster
    on Sep 25, 2026

  2. github-actions commented on Sep 25, 2026

    @github-actions
    github-actionsBot
    on Sep 25, 2026 – with GitHub Actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    • #27924: Infinite compaction loop when compression fails to reduce context below the token limit.
    • #48827: Auto-compaction loop when irreducible context exceeds the model’s usable window.

  3. datamaq-automation commented on Oct 4, 2026

    @datamaq-automation
    datamaq-automation
    on Oct 4, 2026

    Hi @jlongster, noticed you are assigned to this issue.

    I ran into this compaction loop and reproduced it with a unit test in packages/core/test/session-runner.test.ts. Traced two issues in V2:

    1. compactAfterOverflow continued attempting compaction when summaryContext was empty because previousSummary existed.
    2. runTurn lacked a bound on compaction retries per turn when an oversized prompt still exceeds the context window post-compaction.

    In our local fork, we resolved this by:

    • Returning false from compactAfterOverflow when summaryContext.length === 0.
    • Bounding automatic compaction to at most one retry per turn in runAfterCompaction.
    • Checking compaction.exceedsContext({ model, request }) post-compaction and surfacing a clean context-overflow error without re-sending the oversized request.

    Branch and tests are passing locally. Happy to open a small, clean PR if you haven't tackled this yet or if it helps save you time.

  4. sargentomiraflores commented on Oct 10, 2026

    @sargentomiraflores
    sargentomiraflores
    on Oct 10, 2026

    Confirming this with a real-world reproduction on OpenCode 1.18.34 (opencode web) with the DeepSeek provider (deepseek/deepseek-flash, model context 1,048,576).

    Trigger: one oversized attachment — a 1.48 MB .svg (which embedded a 1254×1254 PNG, ~1.04 MB) — added on top of an already large session.

    Observed loop (provider errors, all against maximum context length is 1048576 tokens):

    • requested 1384125 tokens (1352125 in the messages, 32000 in the completion)
    • next turn: requested 2188244 tokens (2156244 in the messages …)
    • compaction attempt: requested 1069278 tokens (1037278 …)
    • then 2188283 …, and compaction again 2102769 …

    Misleading UI: the context indicator showed 19%. It came from the last successful message (a compaction summary with tokens.input=184848); failed requests store tokens=0, so the gauge stayed at ~19% while the real payload was 7–11× larger.

    Root causes (as I read 1.18.34):

    1. SessionCompaction.isOverflow compares the last message's tokens (v.tokens) instead of estimating the next assembled request, so it never fires in time once a compaction resets the counter to the summarized head size.
    2. The compaction request re-sends the whole history with no size budget (same as "Session too large to compact" — the summarization request itself has no size budget #48844), so once the history exceeds the limit it can never succeed.
    3. compaction.prune defaults to off, so tool outputs / media are never pruned.

    Impact: the loop keeps re-sending a ~1.4–2.2M-token payload on every retry, burning the token budget.

    What mitigated it locally:

    • compaction: { auto: true, prune: true, reserved: 120000, preserve_recent_tokens: 80000 }
    • a plugin on experimental.chat.messages.transform that caps oversized parts (text/tool-output >16K, data-URLs >256K) on non-current messages, preserving the last message so the current turn's image still reaches the model.

    Related: #48844, #50187, #51251.

  5. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  6. thdxr
    closed this as not plannedon Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions