Feature: Dynamic context lifecycle management (auto-compress + evict stale files)

Problem

Aider's repo-map is excellent at giving the model structural awareness of the full codebase without loading everything. But once a file is explicitly added to the chat context, it never leaves unless the user manually calls /drop. Over a multi-task session, the active context accumulates files that were relevant several tasks ago but are now dead weight — silently consuming the context window.

This matters most for local model users (the majority of aider's self-hosted userbase), where a 14B or 32B model on a 16K–32K window degrades measurably with every stale file that stays loaded. But it also affects cloud users paying for tokens that no longer contribute to the active task.

What I built

I built a proof-of-concept called context-pilot-mcp that implements dynamic context lifecycle management as an MCP server. It tracks file relevance per turn using a multi-factor staleness score and automatically recommends compression or eviction.

Repo: https://github.com/Sanyam-ahuja/context-pilot-mcp

Staleness scoring factors (weighted):

• Turn decay (40%) — sigmoid decay since last reference
• Edit recency (25%) — recently edited files stay sticky
• Token cost (20%) — expensive files are prioritized for eviction
• Dependency graph (15%) — files imported by actively edited files are protected

Compression: Before dropping, stale files are AST-compressed to signatures-only via tree-sitter. The model continues to see structure, not nothing.

Benchmarks on aider's own codebase:

File	Original Tokens	Compressed	Savings
base_coder.py	21,575	7,858	64%
commands.py	15,557	5,796	63%
repomap.py	6,825	2,080	70%
Total	43,957	15,734	64%

In a simulated 10-turn session with a 16K budget, the engine reclaimed 23,479 tokens dynamically without deleting active context.

Proposed contribution

I'd like to contribute this into aider natively — not as an external MCP dependency but as a first-class context lifecycle layer sitting alongside the existing repo-map.

The integration point I'm thinking about is base_coder.py — specifically the abs_fnames set that tracks added files. A staleness tracker could shadow this set and surface suggestions (or act automatically in a new --auto-drop mode) after each turn.

I'm happy to submit a PR. Before I do, I'd like maintainer input on:

1. Whether this belongs in core or as an optional plugin/flag
2. Whether the --auto-drop vs --suggest-drops distinction makes sense for aider's UX
3. Any architectural constraints I should know about before touching base_coder.py

Happy to discuss here before writing the PR.