Feature Request: Pluggable Context Manager with Intelligent Context Retrieval
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
During long development sessions, Claude Code continuously accumulates conversation history, previously loaded source code, and project context.
As the session grows, every request becomes increasingly expensive because large amounts of unchanged or irrelevant context are repeatedly sent to the model.
This leads to:
- Higher token usage
- Slower response times
- More context noise
- Reduced efficiency for long-running projects
In many cases, only a small portion of the previous context is actually relevant to the current task, but the entire accumulated context still needs to be processed.
Proposed Solution
I'd like Claude Code to provide an intelligent context management mechanism.
Instead of always including the complete accumulated context, Claude Code could:
- Automatically summarize older conversations and large code contexts.
- Rank previous context based on relevance to the current request.
- Include only the most relevant summaries by default.
- Expand and retrieve full context only when additional details are required.
The goal is not to reduce the available context window, but to prioritize relevant context over repeatedly transmitting unchanged information.
This would improve efficiency while preserving the quality of reasoning during long-running development sessions.
Alternative Solutions
Currently my workaround is to manually start a new Claude Code session after it becomes too large.
I also manually summarize previous discussions or copy only the relevant code into a new conversation.
While this helps reduce token usage, it interrupts the workflow and loses valuable project context.
Priority
High - Significant impact on productivity
Feature Category
Performance and speed
Use Case Example
Example:
- I have been working on the same project for several days.
- Claude Code has accumulated a large amount of conversation history and code context.
- I ask a new question about the authentication module.
- Most of the previous discussions about Docker, deployment, and unrelated modules are not needed.
- Instead, Claude Code should prioritize only the authentication-related context and retrieve additional details only if necessary.
This would reduce unnecessary token usage while maintaining continuity during long development sessions.
Additional Context
I believe this feature could significantly improve long-running software development workflows.
The proposal is conceptually similar to retrieval-augmented context management, where only relevant context is loaded by default while additional context can be retrieved on demand.
The goal is not to replace large context windows, but to make them more efficient.
This could also be designed as a pluggable context provider interface in the future, allowing different retrieval strategies without changing Claude Code's core architecture.
4 Comments
A pluggable provider would be most useful if it returns a bounded evidence pack, not another opaque block of text. I would make the interface expose three things:
That separation matters because conversation compaction and durable memory solve different problems. Compaction preserves continuity inside one long run; retrieval brings back selected facts, decisions, and corrections across runs. A provider should not silently promote old chat residue into durable truth, and its write path should be independent from read-only retrieval.
GoodMemory is an open-source reference for this boundary (I maintain it): scoped recall, bounded context assembly, read-only retrieval traces, and an opt-in write tool rather than implicit mutation. It works through MCP today, but this is not a claim that it replaces Claude Code's native compaction or context manager. A native provider interface with the plan/candidates/assembly trace above would make integrations like this inspectable and testable instead of prompt-dependent.
One distinction worth adding to @hjqcan's framing: "which unchanged context is actually relevant right now" splits into at least two different problems — retrieval over prior session facts/decisions (what GoodMemory targets) and retrieval over the codebase's own structure (symbols, callers, blast radius, dependency edges). The second one is narrower and much easier, because the graph is deterministic — no LLM or DB needed to build it, it's just parsing.
We hit this daily running agents across a large multi-module repo and ended up building a static knowledge-graph indexer for exactly that half: ctx-optimize (MIT), a plain Go binary — no MCP server, no vector DB, everything local. It pre-indexes the repo once, then answers "who calls X", "what breaks if I change Y", "where is Z" straight from the store (file:line, signature, callers) in one call instead of the agent doing five Read/Grep round-trips to re-derive the same structure every session.
It doesn't touch the durable-memory-across-runs half of what you're describing — that's a genuinely separate problem, and GoodMemory's plan/candidates/assembly-trace framing above is a good shape for it. But if part of the bloat is "re-discovering the same code structure every session," that half is solvable today without a native provider interface. Happy to have people kick the tires and report where it breaks.
@deemwario Agreed — this is a clean decomposition. Deterministic code-structure retrieval and governed cross-session fact/decision retrieval solve different sources of repeated context work.
A future provider interface could consume both, but it should keep their provenance, freshness rules, and token budgets separate: symbol/caller facts come from the current code graph, while historical decisions and corrections come from durable memory. Thanks for making that boundary explicit.
The place a provider interface most has to get the split right is probably the invalidation model, since that's what "freshness" actually reduces to:
So the "freshness" field in the assembly trace probably isn't one scalar — it's closer to two distinct states: verifiably-current-as-of-commit vs last-asserted-at. Collapsing them is exactly where old chat residue gets silently promoted into durable truth, since a stale assertion and a fresh derivation would otherwise look identical to whatever consumes the pack.