Bug: automatic pressure compaction can be skipped on the first resumed turn

[yijigao]

Environment

• DeepSeek Harness / Desktop runtime based on dsh-v0.1.2-alpha.4
• Windows x64
• Shipped standard preset
• Route: openai-codex / gpt-5.6-sol
• Model context window reported by the adapter: 1,047,576
• Exact-target compaction policy: thresholdRatio: 0.20, retainRatio: 0.08

Observed behavior

A persisted long-running session was resumed after restarting the Desktop host. On its first resumed turn, the context meter was already approximately 611,624 tokens, well above the approximately 209,515 pressure threshold. The session later reached 857,565 tokens (81.9% of the model context window).

Across the complete session log there were zero compaction/start, compaction/summary, or compaction/end events. The resumed requests were durably routed to the same provider/model, and the updated standard preset/runtime prompt was present, so the new runtime and intended policy were active.

A composition-level check confirms that a newly created agent mounted from standard receives agent/pre-step and invokes compactIfNeeded(). The gap therefore appears specific to resumed session state or pressure target resolution, rather than the preset row being absent globally.

Suspected boundary

BasicCompactionEngine.compactIfNeeded() resolves proactive pressure only through:

const target = routedTarget(agent.session)
if (target === undefined) return null

A resumed Session starts a new constructor-seed epoch. If session.requestHeader() intentionally exposes no header before the first new request header in that epoch, the first resumed pre-step can silently skip pressure compaction even though the resumed Agent already carries its restored provider/model route.

A local workaround is to fall back to the Agent route for this specific resume window, but an existing unit test explicitly protects the opposite invariant: headerless pressure must not use AgentOptions. I therefore do not think a broad fallback is appropriate without clarifying the intended durable-route contract.

Questions / suggested fix direction

Would the preferred fix be one of these?

1. Preserve/expose the last trusted persisted request route across the resume seed boundary.
2. Add an explicit trusted resumeRoute owned by Agent construction and usable only until the first new request/header.
3. Permit AgentOptions fallback for pressure compaction, with a stronger proof that the options describe the reconstructed history.

A regression test should use real persistence preparation plus ctx.agents.resume(), mount the shipped standard preset, dispatch the first resumed step above threshold, and assert that a compaction bracket is recorded. A normal newly-created/headerless session should retain the current safety behavior.

This materially affects long-running task sessions: without early compaction, every subsequent model request carries hundreds of thousands of avoidable tokens and can become progressively slower or fail before overflow recovery runs.

[Ultronen]

I do not think the constructor-seed boundary is dropping the routed header in dsh-v0.1.2-alpha.4. I checked the release tag's commit (4e84901e), not current master:

• Session.requestHeader() starts its fold at log position 0, so the restored constructor seed participates in the first read.
• foldRequestHeader() skips non-header events and retains the latest request/header. Therefore session/end-seed does not reset the fold.
• The resumed agent reads that persisted header before writing its new reason: 'resume' header.
• Pressure compaction then resolves the target from that same folded header before comparing tokenMeter.measure(session).totalTokens with the resolved target threshold.

That makes option 1 the existing invariant rather than a new fix, and an additional resumeRoute would duplicate durable route state. I would keep option 3 rejected as well: AgentOptions describes the new instance's proposed route, not necessarily the route that priced the reconstructed history.

I suggest tightening the regression before changing the design:

const handle = await ctx.agents.resume({ resumeSessionId, agentOptions })
const resumed = handle.agent

expect(resumed.session.requestHeader()?.config).toMatchObject({
  provider: expectedProvider,
  model: expectedModel,
})
expect(ctx.tokenMeter.measure(resumed.session).totalTokens)
  .toBeGreaterThanOrEqual(expectedThreshold)

Then dispatch the first resumed step and assert the compaction bracket.

• If the header assertion fails, the persisted seed has no usable request/header; the defect is in the stored artifact/load or a legacy-session migration boundary, not in compaction routing. Recording the latest request/header from the JSONL would distinguish those cases.
• If the header passes but the token assertion fails, compare the UI's projected occupancy with the canonical tokenMeter.measure() result.
• If both pass, inspect resolveModelInfo()/the exact-target policy and spy on compactIfNeeded() to separate policy resolution from listener dispatch.

For a genuinely headerless legacy artifact, I would prefer an explicit migration policy (or intentionally waiting until the first completed routed request) over treating AgentOptions as proof about old history. The integration regression should seed a real prior request/header; otherwise it can accidentally test a different, intentionally headerless case.