Agent! 1.1.1 makes context compaction leave a way back
An agent reads ten source files, fills its context window, and compacts the oldest tool results. On the next turn it knows that something was removed, but not what or why. It reads the files again. The context fills again. The loop did not begin with a weak model or bad search tool. The memory-saving mechanism erased its own recovery path.
That failure appeared in issue #37 for AgentiLoop Agent!, a small open-source macOS automation and coding agent. The reported run used a local Qwen model through LM Studio. It repeatedly read Swift files, compacted at a 17,600-token threshold, then returned to files it had already inspected. The trace shows repeat-guard counts climbing while the task fails to assemble a stable view of the project.
Agent! 1.0.99 and 1.1.1 addressed the problem in stages. Their useful contribution is simple: shortening context should not destroy the route back to evidence.
A placeholder is not a memory
Older microcompaction replaced a cleared tool result with [cleared]. That saved tokens without telling the model which result had disappeared or how to retrieve it. Rereading became the only visible recovery action.
The Agent! 1.0.99 release replaced that placeholder with a self-describing stub. It includes a two-line preview and an exact instruction:
restore_tool_result(tool_use_id:"...")
The preview identifies the missing material. The identifier gives the agent a retrieval path. Results that are already stubs are skipped on later compaction passes, so repeated passes do not keep shrinking the recovery record.
The release also scales how many recent tool results remain in full:
max(3, min(24, threshold / 6000))
The maintainers use a 131K Qwen context with an approximately 72K threshold as an example. It keeps 12 recent reads instead of the previous fixed three. Small windows retain at least three, while larger windows can retain up to 24. The release notes say the accompanying real-window fix makes compaction occur about four times later for the reported case. That figure is a project claim about this implementation, not a general benchmark of context strategies.
Tier 2 needed the same escape hatch
Microcompaction was only one path. Agent! 1.1.1 extends recovery to the heavier Tier 2 pruning stage. Before pruneMessages collapses a tool result, it spills the result to a per-project cache. The summary line carries the exact restore recipe.
The cache lives under .agent/toolcache and stops at 50MB. Each spill can trigger oldest-first eviction. “Recoverable” therefore does not mean retained forever. An active stub can retrieve evidence only while that payload remains in the cache. A long session can evict older material, and deleting the project cache removes it deliberately.
Even with that limit, the arrangement is more useful than an unqualified summary. Active context holds a small index. Disk holds the large result. Tokens are spent again only when the agent reopens a particular item.
Agent! now uses the project-local spill path across Claude, LM Studio, Ollama, vLLM, and OpenAI-compatible services. Recovery no longer depends on an opaque temporary directory for those providers. The cache also belongs in the team's data-handling model. Tool results may contain source, command output, paths, or sensitive material. Removing them from a prompt does not remove them from disk.
Compaction needs the actual window
Issue #37 exposed a timing problem too. The local model had a larger context window, but the agent began with a 32K fallback and a 17,600-token compaction threshold. An asynchronous provider query could discover the real window after the task started, yet the running loop kept using the fallback.
Version 1.1.1 refreshes the threshold on every iteration for the main loop, tabs, and subagents. LM Studio uses /api/v0/models, Ollama uses /api/show, and vLLM uses /v1/models. Once the lookup completes, the next turn can use the actual budget.
The policy itself was not the only problem. It was calculated from stale capability data. For a local or routed model, context metadata is runtime state rather than a one-time setup value.
The release also allows compaction to recover after its circuit breaker trips. Three failed attempts still pause it. If the transcript grows roughly 25% beyond the last attempt, the system tries again. A temporary failure no longer disables compaction for the rest of a long task.
Bytes are not understanding
A restorable tool result preserves bytes, not the reason the agent read them. The model may still restore the wrong result or repeat work. A two-line preview helps with selection without recreating every relationship that the full transcript once supplied.
Nor does the cache prove that old evidence is still current. Restoring a file read after another tool edited the file can introduce stale context. A recovery tool should expose age and provenance, and the agent should reread when freshness matters.
Screenshot results have another limit. Version 1.1.1 begins token-counting block-array tool results and compacts their nested text plus image cost. The release notes say text is spilled, images are dropped, and a recoverable stub remains. Teams using visual agents should test what the restore path reconstructs instead of assuming that every pixel survives.
This resembles the acknowledgement problem in our Summer Engine review. There, a durable receipt separates completed work from a lost response. Here, a recovery stub separates missing active context from missing evidence. Both retain a small, inspectable address for a larger event.
Test recovery, not only token reduction
A useful compaction test forces the agent to need an old result after the window turns over:
- Give it a repository analysis task with more files than fit below the configured threshold.
- Record every file read and
tool_use_idbefore compaction. - Check that each cleared result leaves a recognizable preview and exact restore command.
- Ask a question answered only by an evicted result. The agent should restore it instead of blindly rereading the repository.
- Modify a previously read file, then ask about it again. The agent should not present the restored old result as current evidence.
- Push
.agent/toolcachebeyond 50MB and note which stubs can no longer retrieve their payloads. - Repeat with a subagent and a screenshot-heavy task because version 1.1.1 changed both paths.
Measure repeated reads, successful restores, stale restores, cache misses, and whether the answer uses the correct evidence. Token consumption can fall while task performance gets worse.
Our TypeLens review argued that context should arrive after a concrete need appears instead of flooding the session in advance. Agent!'s recovery stubs apply the same economy after a read. Keep a small address in context, move the bulky evidence out, and retrieve it explicitly. The useful measure is evidence removed with a reliable way back, not tokens removed by themselves.
