Detailed Analysis
A Reddit thread titled "Ai claude don't know me" surfaces a persistent friction point in the daily use of Claude Code: the loss of project context between sessions. The original poster describes a familiar cycle for heavy users of AI coding assistants — beginning a session, spending significant time re-explaining the project's architecture and current state, working until hitting context limits, triggering a compaction event, and then starting fresh only to face the same "what are we building?" prompt again. The user has already tried several common workarounds, including hand-written dev-docs (plan.md, context.md, tasks.md), Claude's CLAUDE.md convention for persistent instructions, and MCP (Model Context Protocol) memory servers, but reports that none of these fully close the gap without manual, ongoing documentation effort.
The specifics raised in the post point to real architectural tensions in how large language model coding tools manage context. One is the sharp drop in prompt cache efficiency after a session resume — from roughly 90% to 20% — which has direct cost implications, since re-establishing context means paying full-price token rates rather than benefiting from cached prefixes. Another is that "skills" (reusable capabilities or instructions) don't automatically activate unless the user builds a custom hooks system to force their invocation, suggesting that Claude's tool-use and context-loading mechanisms still require significant scaffolding from power users rather than working out of the box. A third is the loss of granular, in-progress state — half-finished work, open decisions, and known bugs — that gets discarded during compaction, a lossy summarization process designed to keep context windows within limits but which trades away exactly the kind of detail that matters for continuity in software projects.
This complaint matters because it cuts to the heart of a core limitation of current transformer-based LLMs: they are fundamentally stateless between sessions unless context is explicitly re-supplied, and even within a session, finite context windows force compression or truncation of history. For coding specifically, this is more consequential than for many other use cases because software projects carry long-lived, interdependent state — architecture decisions, open bugs, partial implementations, style conventions — that doesn't compress well into a short summary. The user's experience reflects a broader pattern in the Claude Code and AI-agent community: teams are increasingly building bespoke memory infrastructure (external note systems, RAG-based retrieval over project docs, custom hook systems to inject context) precisely because the tools don't yet handle persistent project memory natively.
More broadly, this thread is emblematic of an industry-wide challenge that Anthropic, OpenAI, and others are actively working to address: giving AI agents durable, efficient long-term memory without exploding costs or latency. Efforts like Anthropic's Model Context Protocol, prompt caching, and various "memory" features across products are attempts to solve this, but as this thread shows, they remain partial solutions in practice, especially for iterative, multi-session software development work. The frustration expressed here — spending more time "re-explaining" than coding — is likely to keep surfacing as a top pain point until AI coding assistants ship native, low-friction mechanisms for maintaining project state across sessions, whether through better automatic summarization, persistent vector-based memory, or tighter integration between IDEs, version control, and the assistant's context management. Until then, users will keep improvising with CLAUDE.md files, external docs, and custom tooling as stopgaps for what is fundamentally still an open problem in applied AI system design.
Read original article →