Repository navigation
ACP turn repeatedly compacts and rereads unchanged files for 47 minutes #1686
Description
Versions
Observed: graff 0.302.46; latest release: v0.302.46. Harness 0.2.128. Surface: Harness / ACP. OS: macOS, arm64.
Observed behavior
A small UI implementation follow-up spent approximately 47.4 minutes in one turn. The transcript repeatedly alternated Compact context with reads of the same unchanged source files before eventually making edits and starting verification.
Sanitized local trace aggregates:
- 58 API events, totaling 42.9 minutes of request latency.
- Reported context stayed between 638,593 and 644,378 tokens.
- 29 responses exceeded 1 MB; aggregate response bytes were approximately 298 MB.
- 27 shell events totaled only 1.42 minutes, including the initial verification attempts.
Thus shell execution and simulator startup were not the primary delay. The visible compaction/reinspection cycle consumed most of the turn. The trace alone does not establish why compaction failed to reduce the effective context; the large responses are not independently proven to be compacted state.
Expected
Detect repeated compaction without meaningful context reduction, and avoid repeatedly rereading unchanged files. Surface a recoverable no-progress condition rather than spending most of an hour on the same inspection cycle.
Relevant source and related reports
The server compaction policy and threshold are described at v0.302.46:src/agent_server_compact.zig:95 and v0.302.46:src/agent_server_compact.zig:103; automatic compaction entry points are at v0.302.46:src/agent_server_compact.zig:424. These are investigation pointers, not a confirmed faulty line.
Searched open and closed issues for compaction loops, Compact context, and compaction before every tool call. Related but distinct: #706 concerns unresolved local compact_cut boundaries; #1620 concerns explicit compact rollback reporting. This report concerns repeated visible compaction during an ACP turn on the current release.
Activity
yxlyx commentedon Oct 20, 2026
Harness: 0.2.128 (latest: 0.2.128)
graff: 0.302.46 (latest: v0.302.46); #1687 is merged but not in this installed release
App: desktop
Platform: macOS
Additional accounting diagnostic from the affected conversation, including a later short confirmation-only turn:
This narrows the diagnosis beyond repeated compaction: the opaque-state byte estimate itself can keep a nearly empty visible history above the configured window. It does not establish the provider's exact usable occupancy, but the displayed over-limit value is not evidence of actual over-limit input. Please include large opaque-state accounting in follow-up validation; #1687's backoff retains a 95% wall, so backoff alone should not be assumed to resolve an inflated estimate already above that wall. Related accounting discussion: #1582.
justrach commentedon Oct 20, 2026
no. @yxlyx
compaction: hold the next pass when the last one bought no room
compaction: count opaque state by the provider's own measure