[FEATURE] Server-side persistent context store for API and CLI users

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

There is a specific and recurring failure that makes this problem more severe than it appears: the "Wasted call" problem.

When Compaction occurs mid-session, previously injected context is silently discarded from the context window. However, the system still treats those files as "already read this session" — and blocks re-reading them, returning a "Wasted call — file unchanged since your last Read" message instead.

The result: the context is gone, but the system believes it is still present. The user has no way to know this has happened, and cannot force a re-read without workarounds such as manually updating file timestamps to trick the system into re-reading.

This is the operational reality that makes a server-side persistent context store not just convenient, but necessary. A server-side store would survive Compaction by design — because it lives outside the context window entirely.

Every Claude session starts from zero. Rules, project structure, preferences, and work-in-progress state all have to be re-injected at session start — manually or through workarounds like CLAUDE.md, hand-maintained handoff files, SessionStart hooks, and log files.

This is not a complaint about Claude's capabilities. It reflects a structural gap: there is currently no server-side location where a user's persistent context can live and be reliably available across sessions, at the API and CLI level.

Users who build serious workflows on top of Claude — paying subscribers who rely on Claude Code and the API daily — have been solving this individually, each building their own layer of scaffolding to compensate. That scaffolding works, but it consumes context tokens, requires maintenance, and breaks down when Compaction kicks in mid-session and silently discards what was just loaded.

We're not pointing this out as a criticism. We understand that solving persistent context at the platform level is architecturally non-trivial. We're raising it because we believe Anthropic is well-positioned to solve it thoughtfully — in a way that reflects the transparency and user-control values already visible in projects like Managed Agents Memory.

Proposed Solution

A Persistent Context Store: a server-side, per-user storage layer that is automatically available at the API and CLI level.

Core behavior:

• User-defined rules, profiles, and project state are stored server-side
• Injected automatically at session start (no manual re-loading required)
• Fully visible and controllable by the user: view, edit, delete, rollback via dashboard or API
• Available consistently whether the user is on claude.ai, Claude Code, or the API
• Injection volume is user-configurable (full / summarized / priority-ordered)

This is intentionally scoped to structured, user-defined context — not open-ended memory synthesis. The user decides what goes in. That distinction keeps it tractable and keeps the user in control.

Alternative Solutions

We have built a working workaround using local files and hooks:

• CLAUDE.md (Projects feature): injects rules and project structure at session start
• Hand-maintained handoff files: preserve work-in-progress state across sessions
• SessionStart hooks: automatically re-read local files at session start
• Workaround for "Wasted call" issue: update file timestamps to force re-reading after Compaction

This approach works, but has real costs: it consumes context tokens on every session start, requires ongoing manual maintenance, and breaks down silently when Compaction discards injected content mid-session. There is no way to know when this has happened without checking manually.

Other AI platforms have partial solutions — OpenAI's memory synthesis and Gemini's personal context — but none of them extend to the API or CLI level. The gap we are describing exists across all major platforms as of June 2026.

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

A paying subscriber uses Claude Code daily to manage a structured project with detailed rules, role definitions, and session state.

Every session start requires re-injecting approximately 3,000 tokens of context from local files. When Compaction occurs mid-session, that injected content is silently discarded and must be reloaded — sometimes in the middle of a task, without any warning.

With a Persistent Context Store:

1. Session start automatically loads the user's stored context from the server
2. Compaction does not erase it
3. The user works without interruption; Claude has what it needs throughout the session
4. The same context is available whether working via claude.ai, Claude Code, or the API

This single change would eliminate the most frequent source of workflow interruption for power users who have built serious operations on top of Claude.

Additional Context

Why this matters for Anthropic

We raise this not just as a user request but as an observation about where the product could differentiate:

• OpenAI's memory (Dreaming V3) is the most advanced today, but it has drawn criticism for reduced transparency in what gets remembered and why.
• Anthropic's design values — transparency, user control, auditability — are exactly what a well-designed persistent context store would embody.
• Anthropic has already built the underlying capability: Managed Agents Memory (public beta, April 2026) is filesystem-mounted, fully auditable, and developer-controlled. The gap is scope — it does not yet extend to Claude Code (CLI) or direct API access. The ask is not to build something new from scratch, but to extend what already works to the surfaces where power users actually operate.
• The users most affected (API and CLI power users, paying subscribers) are also the users most likely to advocate for Claude if their core workflow friction is resolved.

We'd love to see Anthropic solve this in a way that only Anthropic would: structured, transparent, user-controlled, and available where the work actually happens.

This request is submitted by the same user who filed #65982. That issue explored a related problem (fact-check gates at response-commit time) and the discussion there helped clarify the structural gap described here.