Autocompact never fires proactively at the context edge — autonomous/headless sessions park until the next user message (desktop app + Agent SDK)

The lazy compaction behavior you documented is a real gap for anyone running overnight or CI-style autonomous sessions - the silent park-until-next-input is the worst failure mode because there is no error to act on, the session just stops making progress.

A few things worth noting in the meantime:

• If you have a hook system available, a periodic wakeup hook (even a no-op ping every N minutes) can serve as an artificial input source that triggers the lazy compaction before the session goes fully dark. Not a real fix but it keeps sessions from going silent overnight.
• For the Agent SDK path specifically, wrapping the session runner in a timeout watchdog that detects "no tool calls in last M minutes" and sends a synthetic continuation prompt is a common workaround teams use for headless sessions.
• The silent stop_reason: tool_use cut mid-turn is the harder problem - surfacing that as an error rather than a quiet stop would at least make the failure observable so you can act on it.

The timestamp data in your issue is really clear - six compact_boundary events, all lazy. That should make it reproducible in a shorter test session by watching for the event in transcript logs.

Thanks @kcarriedo — that matches our data exactly. We can confirm your first point empirically: in the transcript from the issue, every one of the six compactions was triggered by an incoming input, and several of those inputs were scheduled self-wakeups. A session that habitually arms a periodic wakeup effectively self-mitigates; the overnight session in question only survived because of that.

We also run your second suggestion in our SDK-embedded app: a boundary-cut detector (abnormal stop_reason: tool_use while over the autocompact threshold) that injects a synthetic continuation prompt. It works when the signature matches, but agreed that your third point is the real fix — the mid-turn cut is silent today, so any watchdog is heuristic. Surfacing the cut as an explicit event/error (or just compacting eagerly at the threshold) would make all of these workarounds unnecessary.

Appreciate the confirmation that this repros beyond our setup.

Same root cause, opposite symptom, with numbers from a different setup.

We hit this interactively on macOS. The lazy trigger means compaction runs at the start of the next turn, so where a headless session parks forever, an interactive user instead types a message and then waits with nothing rendered while compaction runs. One mechanism, two failure shapes depending on whether an input source exists.

Measured across 256 local transcripts (224 unique compact_boundary records, 204 with trigger: auto). Records were deduplicated on uuid first, which matters: transcripts re-append prior history on resume, and one boundary can appear up to 30 times in a single file. Depth counts assistant records between the boundary and the nearest preceding human-typed message, excluding tool results, hook injections and system reminders.

| depth when compaction fires | share |
|---|---|
| 11+ assistant turns deep | 84.8% |
| 4-10 | 4.9% |
| 1-3 | 5.4% |
| 0, before any assistant reply | 4.9% |

Median 15.6 minutes since the last human message. preTokens clusters tightly around 168k.

The honest read on our own complaint: the interactive case is rare, not common. Of the 11 depth-0 boundaries, 8 are in agent-* subagent transcripts where nobody is waiting. Only 3 are sessions where a person actually typed and sat there, so the rate that matches the interactive complaint is 3/224, about 1.3%. It feels far more frequent than that because of what it costs when it happens: those three waits were 160s, 166s and 203s with nothing on screen. Salience, not frequency.

That said, the 84.8% row is the load-bearing one, and it argues for the same fix from the other side. If compaction already runs mid-turn in the overwhelming majority of cases, then running it at end-of-turn is not a behavior change for most sessions, and it is strictly better for the two tails: the headless session gets its compaction without waiting for an input that never comes, and the interactive user reads the reply while compaction happens behind it.

So we would support Ask 1's end-of-turn half specifically, with one refinement. End-of-turn compaction should be the scheduled path, not the only path. A turn that grows unusually fast can still cross the threshold mid-turn, and in that case compacting immediately is correct. The bug is not that compaction can happen mid-turn, it is that mid-turn is the only time it happens today. Keep it as the safety valve, make end-of-turn the normal case.

One caveat on our data: it is a single machine and a single workflow, heavy on subagents, so the depth distribution is skewed by that and the subagent/interactive split above should be read as specific to this setup rather than general.