Microcompact count trigger wipes tool results every 11 calls and drives tool-call loops

[6653302wy]

Summary

Count-based microcompact rewrites live tool results on a fixed cadence that has nothing to do with token pressure. On any turn with more than ~10 compactable tool calls, the agent wipes earlier observations and the model starts re-running the same commands. Hosts (AionUi / AionCore) surface this as a repeating Microcompact: cleared 6 tool results tip until the context is burned.

This is still the default behavior on v0.2.11, which is the tag currently pinned by AionCore / AionUi (aioncoreVersion: "v0.2.1"). I know PR #266 later disabled legacy microcompact on main and replaced it with tool_output_max_bytes; this issue is to (1) get that change into the tag hosts actually ship, and (2) fix the remaining footguns if microcompact_enabled is turned back on.

Environment

• aionrs: v0.2.11 (AionCore git dependency)
• Host: AionUi Desktop, aionrs / Aion CLI backend
• Model: Qwen-class (observed with Qwen3.8-27B)
• Trigger: attach a large Office/PDF and ask the agent to read or summarize it

Symptoms

• The transcript ends in an unbounded tool loop. The UI tip is almost always exactly Microcompact: cleared 6 tool results.
• Measured sessions:
  • 106 tool calls, 96 results cleared, 16 microcompacts, ~2M input tokens
  • 155 tool calls, 25 microcompacts, 12.1M input tokens
  • other sessions: 329 / 53 and 498 / 76
• Converted files were already on disk (e.g. api_doc.md ~151KB). Later ls results were still live, but the model kept re-listing and re-converting.
• Prompt rules (“do not re-run after Microcompact, read the file instead”) did not stop it.

A 24K-token session compacted 16 times. A 77K-token session compacted 0 times (tools not in the compactable set). This is not a context-window overflow.

Root cause

crates/aion-agent/src/compact/micro.rs (count_trigger):

live compactable tool_result count > micro_keep_recent * 2

Defaults: micro_keep_recent = 5 → fire when live results > 10.

Then microcompact keeps the 5 most recent live results and replaces older Read / ExecCommand / Grep / Glob / Write / Edit bodies with [Tool result cleared]. Thinking and assistant text are not touched. Token usage and context_window are not consulted.

Steady state:

11 live results → clear 6 → keep 5 → grow to 11 → clear 6 again

That is why the tip is always cleared 6. Any task longer than ~10 tool steps loses its earlier observations, so the model retries.

Docs still describe this as designed (docs/advanced.md on the v0.2.11 line: count > 10 or a 1-hour gap).

Config merge footgun (hosts cannot raise the default cleanly)

AionCore passes project_dir = conversation workspace and forwards config.compact through resolve_aionui_config. aionrs Config::resolve reads <workspace>/.aionrs.toml.

When merging a project [compact] block, if context_window is still the crate default 200000 and enabled is not false, the entire project compact section is discarded. Hosts that write:

[compact]
micro_keep_recent = 80

get a no-op unless they also change context_window to something other than 200000 (we used 131072).

Suggested fix

1. Ship PR fix(cli): stabilize tool context and terminal rendering #266 (or equivalent) in a release AionCore can pin. Hosts still run v0.2.11 with microcompact on.
2. If count-based microcompact remains for compatibility:
   • drive it from real token pressure, not keep_recent * 2
   • raise the default micro_keep_recent well above 5
   • do not drop a project [compact] block just because context_window equals the crate default
3. Prefer bounding a tool result once when it enters history (tool_output_max_bytes) over rewriting earlier turns.

Workaround used by hosts today

Write this into the session workspace before agent bootstrap:

[compact]
context_window = 131072
micro_keep_recent = 80

That changes the trigger from “> 10 live results” to “> 160” and avoids the merge discard. It is a host-side band-aid, not a substitute for fixing the trigger.

Related: iOfficeAI/aionrs#266, docs/advanced.md.