Batch Pi transcript mutations to preserve provider prefix-cache stability

[foreverwow001]

Summary

On long, tool-heavy Pi sessions, independently scheduled transcript mutations can repeatedly change an old prompt prefix across adjacent provider calls. This causes avoidable prompt-cache misses even though each individual cleanup is correct.

The mutation sources observed on 0.41.2 include queued drops, heuristic/auto reclaim, reasoning cleanup, protected-tail/emergency publication, and M0/M1 history refresh. Fixing only delayed ctx_reduce operations is therefore insufficient.

Evidence

From a long Pi session on 0.41.2:

• Calls with a fresh old-prefix mutation: 136, average cache-read ratio 46.6%; 121/136 below 70%.
• Calls with a stable old prefix: 138, average cache-read ratio 91.8%; only 10/138 below 70%.
• The session contained only two explicit ctx_reduce calls that day, so automatic mutation paths were material contributors.
• The longest near-zero-cache run was 18 adjacent calls; the longest below-70% run was 26 calls.

An isolated same-process Pi RPC reproduction used a 30-step tool chain plus 12 follow-up turns. A prototype common-exit batch gate reduced transform bust records from 39 to 3 and improved the final-20-call cache-read ratio from 96.1% to 98.2%, with all tool calls/results and instructions preserved.

Suggested behavior

At the common Pi transform exit rather than in only one cleanup source:

1. Allow at most one fresh old-prefix mutation batch per real user turn at normal pressure.
2. Permit one additional batch when pressure enters a higher force band.
3. Keep the absolute 95% emergency path unrestricted.
4. Do not apply tiny pending batches merely because one protected tag aged out; wait for a material batch or higher pressure.
5. Continue deterministic replay of already-persisted drops/reasoning on every pass, but do not classify identical replay as a fresh bust.
6. Defer M0/M1 materialization within the same turn when a valid cached snapshot exists.

This preserves the existing fail-safe emergency behavior while giving the provider prefix a stable interval after each batch.

Acceptance ideas

• One user turn with many tool calls and queued drops does not mutate the old prefix repeatedly.
• Protected-tail and emergency paths participate in the same batching decision.
• At >=95% pressure, cleanup remains unrestricted.
• No loss of current-turn tool results, unresolved errors, or user decisions.
• Session reopen/reload and deterministic replay remain byte-stable.

[ualtinok]

It seems you haven’t ask your agent to clone the repo and do a proper exploration. Please do and notice almost every claim in this issue is wrong. MC’s north star is cache stability and every decision for modifying cached prefix is deferred and batched together at specific execute thresholds.

If you’re seeing unexpected cache busts please open an issue with doctor so we can have proper diagnosis.