Feature request: memory decay and freshness — salience scoring or TTL for auto-memory files

Feature request

Auto-memory files persist indefinitely with equal weight. A memory saved three months ago is presented to the agent with the same authority as one saved yesterday — even if the underlying facts have changed. This creates a growing reliability problem: stale memories silently pollute reasoning alongside fresh instructions and skills, with no signal to the agent (or the user) that something is outdated.

Proposed solution: salience-weighted memory decay

Memories should decay over time unless reinforced by use. This mirrors how human memory works — frequently relevant context stays sharp, while one-off notes fade naturally.

Core mechanics:

• Each memory gets a salience score that decays over time (exponential or stepped)
• When a memory is retrieved and useful in a session, its score is reinforced (spike + slower future decay)
• Memories that are never reinforced gradually fade — either deprioritized in context or surfaced with a staleness flag
• The decay rate itself decreases with each reinforcement, so durable knowledge consolidates while ephemeral context fades

What this enables:

• Agent can weigh fresh memories more heavily than stale ones without user intervention
• Frequently useful memories naturally persist; one-off notes self-prune
• Users don't need to guess TTLs upfront or manually audit memories quarterly
• Memory budget stays lean over time without explicit cleanup

Behavior options for faded memories:

| Strategy | Behavior |
|----------|----------|
| Soft fade (recommended) | Memory still loads but flagged as low-confidence / potentially stale |
| Hard prune | Memory excluded from context below a score threshold |
| Review prompt | Agent periodically surfaces faded memories: "Is this still true?" |

Simpler alternative: explicit TTL metadata

If salience scoring is too complex for a first pass, a simpler version would let users declare a TTL in memory frontmatter:

---
name: example-memory
description: Current deployment architecture for service X
metadata:
  type: project
  ttl_days: 30
  created: 2026-05-14
---

Memories past their TTL would be flagged as potentially stale or excluded from context. This is less elegant — users have to guess the right TTL at write time — but it's a meaningful improvement over the current "everything is equally current forever" behavior.

Why this matters

• Operational agents that maintain context about infrastructure, team structure, or project state accumulate memories that silently become wrong
• Long-lived projects build up memory files that no one audits — the cost of manual pruning scales with how much the agent has learned
• Different facts decay at different rates — user preferences are nearly permanent, project status changes weekly, integration details change when dependencies update. You can't predict this at write time, but usage patterns reveal it naturally
• Stale memories pollute reasoning silently — the agent doesn't flag "I'm using a 3-month-old memory here." It blends outdated context with fresh instructions and the user never knows

Prior art

• Spaced repetition systems (Anki/SuperMemo) — reinforcement-decay curves for knowledge retention
• LRU/LFU cache eviction — usage-based retention in systems programming
• v2.1.75 added last-modified timestamps to memory files (#34153), which is a building block but doesn't change how Claude weighs old vs. new memories
• #29867 proposed this exact pattern (salience decay + style-scoped banks) but was closed as stale before implementation. That issue is now locked, so this request revives the core idea.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>