Feature: salience-weighted memory decay and style-scoped memory banks
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Auto-memory has no mechanism for prioritisation or forgetting. Entries have equal weight forever, files grow until manually pruned, and all memories load into every session regardless of context (coding vs. writing vs. life admin).
Proposed Solution
1. Salience scoring. Give each memory entry a score that spikes on useful retrieval and decays over time. The decay rate itself decreases with each reinforcement, so frequently useful memories consolidate while one-off notes fade naturally. This could drive auto-sorting, truncation at the line limit, or a "fading memories" review prompt.
2. Style-scoped banks. Let memory files or directories associate with output styles, so a "homelab" style loads homelab memories and a "writing" style loads writing memories. MEMORY.md stays universal; scoped banks load conditionally. Pairs naturally with the existing style system and with #26807 (skill-scoped memory).
Prior Art
- Spaced repetition (Anki/SuperMemo) reinforcement-decay curves
- LRU/LFU cache eviction
- Adjacent issues: #28841 (sync timing), #26807 (skill-scoped memory)
P.S. — DIY workaround and a question
A user could approximate this today: use --append-system-prompt to instruct Claude to maintain salience metadata (score, decay rate) as YAML frontmatter on memory files, while a separate background service (cron job, systemd timer) performs the actual decay arithmetic and pruning between sessions.
This avoids calling the claude binary from a script (which we understand isn't permitted), but it does involve an external process modifying files under ~/.claude/. Is that considered a supported pattern, or are the memory/skill dotfiles expected to be modified only by Claude Code itself?
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗