[FEATURE] Persistent project-scoped prompt cache, independent of thread/session lifetime

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

Prompt caching today is scoped to a single conversation's exact token prefix and expires on a short TTL (~5 min default, up to 1h on long-TTL). Users who work across many independent threads on the same project over hours or days re-process the stable, shared part of every prompt — CLAUDE.md, project instructions, memory files — at full price on every single thread, because no thread ever reuses another thread's cache. Neither /clear nor opening a fresh tab avoids this: both start uncached.

For projects with a large CLAUDE.md/memory hierarchy (multi-thousand-token context files loaded on every first message), this cost is paid repeatedly and is proportional to how much stable context the project carries, not to how much actually changed between sessions.

### Proposed Solution

A cache tier scoped to the project (or user account) rather than the thread, so content known to be stable and shared across sessions — the CLAUDE.md hierarchy, memory files, other auto-loaded context — can be cached once and reused by any subsequent thread that loads the same content, regardless of which session created the cache entry or how much time passed in between.

From a user perspective: I open a new thread on a project I haven't touched in hours or days, and the portion of my prompt that hasn't changed since the last thread (context files) is served from cache instead of reprocessed at full price.

### Alternative Solutions

Staying within the existing per-thread TTL window by not letting sessions go idle — not viable for a return-hours-or-days-later workflow, since the TTL (even at 1h) is shorter than the gap between sessions.

Keeping context files as lean as possible to reduce the fixed cost paid on every thread's first message — helps, but doesn't eliminate the redundant reprocessing across threads.

### Priority

Medium - Would be very helpful

### Feature Category

Performance and speed

### Use Case Example

I work on a single project across many separate threads, often returning hours or a full day later rather than continuing the same thread. Each new thread reloads the same CLAUDE.md hierarchy and memory files as every prior thread on that project, and reprocesses them at full price because no cache is shared across threads. A project-scoped cache would let the Nth thread of the day/week reuse what the 1st thread already cached.

### Additional Context

Related: #66966 (closed as stale, not resolved) found that even a byte-identical first-message envelope across separate sessions fails to hit cache, suggesting today's cache key includes something session-specific beyond prompt content alone — likely a prerequisite fix before project-scoped caching is feasible.

Acknowledged complexity: persistent server-side cache storage is a real infrastructure cost for Anthropic, so this is a bigger ask than a client-side setting. Likely most valuable to heavy multi-thread, multi-day, large-project-context users rather than a universal win.

Start by reading the existing prompt-caching behavior described here and related issue #66966, focusing on why identical first-message envelopes across sessions miss the cache. Define the project-scoped cache requirements and verify that unchanged CLAUDE.md, memory files, and other auto-loaded context are reused across independent threads while changed content is not.

Escrito por el modelo de indexación a partir del texto del issue.