Auto-memory at heavy scale: MEMORY.md size budget forces working sessions into constant index-curation (55-byte trims mid-task)

Auto-memory at heavy scale: the always-loaded MEMORY.md budget turns every memory write into an index-curation tax on working sessions

Environment

Claude Code (macOS), single project used daily for ~1 year with auto-memory enabled.

Scale data point

• 1,200+ memory fact files (~26 MB) in one project's memory/ directory
• MEMORY.md index pinned at its ~17 KB auto-load budget for weeks
• ~8–10 new memories written per day at peak (≈2 KB/day of index growth)

The problem

The memory instructions tell the model to add a one-line pointer to MEMORY.md after every memory write, and MEMORY.md has an effective size budget because it auto-loads every session. At heavy usage those two rules collide: the index reaches the budget and stays pinned there, so every subsequent memory write forces the working session to stop mid-task and hand-trim the index.

Observed verbatim in a session transcript today, mid-task:

"MEMORY.md went 55 bytes over cap — trimming my own line."

That session was doing product work; it detoured into index prose-surgery over 55 bytes. Across sessions this compounds — we counted nine hand-compactions in sixteen days before building workarounds. The curation tax lands on the most expensive resource (an in-flight session with the user's real task in context) instead of on a batch process.

Feature requests (any subset would help)

1. Native index lifecycle. Harness-side eviction/aging for MEMORY.md entries (TTL for dated entries, archive-not-delete), so the model isn't the garbage collector.
2. Hysteresis, not a hard ceiling. Treat the budget as a high-water mark with tolerance; when compaction happens, compact to a low-water mark so headroom is restored in one pass instead of 55-byte trims every session.
3. Move compaction off the critical path. Let index maintenance run out-of-session (background/scheduled), never as an interruption to a working session.
4. Usage telemetry for memories. Expose which memory files were actually recalled/read per session, so eviction can be evidence-based (hit-count ranking) rather than judgment calls.
5. Relevance-scoped index loading. If the harness can load only the index sections relevant to the session's early context, the always-loaded surface shrinks and the byte budget stops being the binding constraint.

Workaround we built (kept harness-native on purpose)

A PostToolUse hook + daily launchd "custodian" that (a) makes working sessions append-only — the hook never asks a session to trim; (b) ages dated index lines out after 21 days to an archive file; (c) watermark-compacts 16.5 KB → 13.5 KB by moving whole lines to the archive. We deliberately kept the stock format (one fact file + frontmatter, MEMORY.md as index) so future harness-side memory improvements land cleanly — which is also why we'd prefer this class of maintenance to move into the product.