v2.0.32: every compaction runs twice, the same transcript is summarized again #57805

Activity

1. opencode-agent commented on Oct 21, 2026

   

   opencode-agentBot

   on Oct 21, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed write-up. I tried to reproduce this on v2.0.32 with a simulated model that reports token usage, using a small ceiling like yours:

   • limit.input 12000, compaction.buffer 2000, one turn in which the model reads a ~57 KB file
   • limit.input 8000, compaction.buffer 1000, keep.tokens 3000, two turns (a short exchange, then the file read), so the checkpoint keeps a recent tail

   In both cases auto-compaction ran exactly once: one summary request, then the run continued from the new checkpoint. I couldn't get the compaction row to land somewhere other than the end of the loaded history, which is the case your proposed fix targets.

   These would help us reproduce it:

   1. Your exact reproduction config (the provider/model block with limit, plus the full compaction section) and the prompt you used. Was it a subagent (task) session, like the original evidence?
   2. For one affected session, the ordered list of messages around the pair: type, reason, status, and timestamps for the two compaction rows and whatever lies between and after them. In particular, what was the last message in the history when the second compaction started?
   3. Whether anything else was happening at the same time, e.g. a queued prompt, a tool still running, or an interrupt.

   You can reply here, or edit the issue and leave a comment saying it's updated.
2. maximkone commented on Oct 21, 2026

   

   maximkone

   on Oct 21, 2026

   Author

   More actions

   The patch above only covers the case where the runner re-runs the auto check right after a compaction. There is a second, more direct cause visible in the session data: the request rebuilt right after a compaction still holds the transcript that was just compacted.

   The write that carries the checkpoint lands a moment after the compaction returns. When the runner reloads the history before that write lands, the request is rebuilt from the old transcript, the provider sees the same context again, and the session compacts over the same messages a second time. In a session on v2.0.32 that is visible as pairs of compaction messages with the same cached prefix (cache.read 267451 for both, 1.4 s apart).

   So the fix has two parts: skip one auto check after a compaction, and wait for the checkpoint to reach the loaded history before the next request is built.

       /**
        * Waits for a finished compaction to reach the loaded history. The write that carries the
        * checkpoint lands a moment after the compaction returns. A request rebuilt before it lands
        * still holds the transcript that was just compacted, so the provider sees the same context
        * again and the session compacts a second time over the same messages.
        */
       const settleCompaction = Effect.fn("SessionRunner.settleCompaction")(function* (sessionID: SessionSchema.ID) {
         for (let attempt = 0; attempt < 20; attempt++) {
           const loaded = yield* prepareContext(sessionID).pipe(
             Effect.flatMap(context.load),
             Effect.catchCause(() => Effect.succeed(undefined)),
           )
           if (!loaded) return
           const last = loaded.messages.at(-1)
           if (last?.type === "compaction" && last.status === "completed") return
           yield* Effect.sleep(50)
         }
       })

   and in runStep:

         let compactedOnce = false
         while (true) {
           const loaded = initial ?? (yield* prepareContext(sessionID).pipe(Effect.flatMap(context.load)))
           initial = undefined
           if (compactedOnce) {
             compactedOnce = false
           } else {
             const compacted = yield* compaction.compact({ reason: "auto", context: loaded })
             if (compacted.status === "failed") return yield* new StepFailedError({ error: compacted.error })
             if (compacted.status === "completed") {
               compactedOnce = true
               assistantMessageID = SessionMessage.ID.create()
               yield* settleCompaction(sessionID)
               continue
             }
           }

   Tests

   With the patch applied to v2.0.32:

   • packages/core/test/session-compaction.test.ts, session-compact.test.ts: 16 pass, 0 fail
   • packages/core/test/session-runner.test.ts, session-step.test.ts, session-run-coordinator.test.ts: 258 pass, 0 fail
   • all packages/core/test/session-*.test.ts: 645 pass, 1 skip, 3 fail - the three failures are shell-message tests that time out at 5 s under parallel load and pass on their own, with and without the patch

   Built and run on Windows: bun run --cwd packages/cli build --single --target=opencode-windows-x64, installed over the v2.0.32 binary, and the paired compactions are gone.
3. maximkone commented on Oct 21, 2026

   

   maximkone

   on Oct 21, 2026

   Author

   More actions

   Here is the exact setup and the ordered messages around one affected pair.

   1. The setup that produced it

   It was a subagent (task) session, started from a desktop chat on the app's own server (opencode serve, the CLI the desktop app ships). The model and the limits come from the global config ~/.config/opencode/opencode.jsonc:

   "compaction": { "auto": true, "keep": { "tokens": 15000 }, "buffer": 20000 },
   "provider": {
     "zen-proxy-minimax": {
       "npm": "@ai-sdk/openai-compatible",
       "options": { "baseURL": "http://127.0.0.1:13579/v1" },
       "whitelist": ["minimax-m3.1-flash-free"],
       "models": {
         "minimax-m3.1-flash-free": {
           "reasoning": true,
           "tool_call": true,
           "limit": { "context": 350000, "input": 286000, "output": 64000 }
         }
       }
     }
   }

   The provider is an OpenAI-compatible endpoint in front of the model, so the ceiling is 286000 - 20000 = 266000. The prompt was the subagent task (write a research report to a file), nothing special about it.

   2. The ordered messages around one pair

   From the session store (session_message, ordered by seq):

   seq	type	time_created	reason	status	tokens
   1133	assistant	1792582793101			input 5731, output 85, cache.read 260716
   1135	assistant	1792582799349			input 6735, output 93, cache.read 260716
   1146	compaction	1792582823235	auto	completed	input 842, output 3593, cache.read 267451
   1154	compaction	1792582824658	auto	completed	input 1629, output 2060, cache.read 267451
   1157	assistant	1792582863403			input 2429, output 170, cache.read 8960

   Nothing at all sits between the two compaction rows: no assistant message, no user message, no synthetic message. The last message in the history when the second compaction started was therefore the compaction row 1146 itself.

   Both compactions sent the same 267451-token cached prefix, so the second one summarized the same transcript again; only 1.4 s separated them. The reply that came after (1157) used a small request (input 2429, cache.read 8960), so the checkpoint was in place by then.

   The same session has four more such pairs, with the same shape (2225/2228, 4023/4033, 4783/4793), all with a cached prefix of ~266k on both sides of the pair.

   3. What else was happening

   Nothing was queued: no pending user prompt, no tool still running, no interrupt around that time. The session was a background subagent while the parent chat was active, and several other sessions were running on the same server at the same time.

   4. A detail that may matter

   The compaction rows are written by the projector for session.compaction.ended, and the row of the first compaction (1146) was already status: completed in the store when the second compaction started. If the reload right after a compaction does not see that row yet, the runner measures the old context again (267451) and the check fires a second time over the same messages. The second patch in this thread (waiting for the checkpoint to reach the loaded history before the next request is built) is aimed at exactly that window; the first one (skipping one auto check after a compaction) covers the case where the row is the last message and the check would still fire on the stale measurement.
4. opencode-agent

   closed this as not plannedon Oct 24, 2026
5. opencode-agent commented on Oct 24, 2026

   

   opencode-agentBot

   on Oct 24, 2026 – with OpenCode Agent

   Contributor

   More actions

   Closing this for now, since we haven't heard back. On v2.0.32 with a small context ceiling, auto-compaction ran only once per turn in every setup we tried, so we couldn't confirm the double compaction, and the details we asked for never arrived.

   If it still happens for you, please comment here or open a new issue with:

   • your model limit and compaction config
   • the prompt you used, and whether it was a subagent session
   • the ordered messages around the two compaction rows: their type, reason, status and timestamps

   We'll take another look then. Thanks for the detailed analysis and the proposed patch.
6. opencodejr

   reopened this on Nov 3, 2026