← Reddit

Help me understand the type of caching used by Projects

Reddit · iPutMilkNbowlB4Creal · August 16, 2026
A researcher working on a long-running project questioned whether uploading static files to Claude Projects rather than including them in each session would reduce token consumption. The inquiry references project documentation indicating that uploaded documents are cached for future use with only new portions counting against limits, causing confusion about whether this represents a different caching mechanism than the previously understood one-hour cache duration.

Detailed Analysis

A Reddit thread in r/ClaudeAI surfaces a genuine point of confusion around how Anthropic's Projects feature handles document caching, and whether it meaningfully reduces token usage for users running long-lived, file-heavy workflows. The user describes a common pattern for research-oriented Claude usage: a handoff.md file to carry context between sessions, a boot prompt, several small Python files, and a large Jupyter notebook with roughly 100 cells. Their question is whether moving static, infrequently-changed files into the Project's persistent knowledge base—rather than re-uploading them at the start of every chat—would reduce the "usage bite" they experience each time they start a new session, especially as a Claude Max 5x subscriber trying to manage rate limits.

The confusion centers on a real ambiguity in Anthropic's documentation. The Projects feature states that uploaded documents are "cached for future use" and that only new or uncached portions count against usage limits on subsequent references. But this language sits awkwardly next to the well-documented behavior of Claude's prompt caching system, which typically operates on short time windows—roughly five minutes for standard cache, with an extended one-hour option available via the API (notably used in tools like Claude Code). Prompt caching, as originally designed, is a session-level optimization: it lets repeated context within a bounded window skip re-processing costs, not an indefinite storage mechanism. The user's confusion is well-founded because "cached for future use" in the Projects context implies something more persistent than the ephemeral caching most Claude users and developers are familiar with from API documentation.

This distinction matters because it shapes how power users architect their workflows to conserve usage, particularly on capped plans like Max 5x where hitting rate limits can interrupt research momentum. If Project knowledge files are cached indefinitely or reindexed efficiently at the account/project level (as opposed to being re-tokenized fresh each session), users like this one could substantially cut their per-session costs by separating static reference material (the notebook, boilerplate scripts) from dynamic session-starting content (the boot prompt, updated handoff notes). Conversely, if the "caching" language in Projects documentation is describing something closer to retrieval-augmented context injection rather than literal token-level prompt caching, the practical benefit could be much smaller than users assume, and the marketing language may be creating false expectations about cost savings.

The episode reflects a broader pattern in AI tooling: as context windows grow and users adopt increasingly sophisticated, file-heavy, persistent workflows—effectively treating chat interfaces like lightweight IDEs or research environments—the underlying infrastructure for managing context (caching, retrieval, chunking, reindexing) becomes as consequential to usability and cost as the model's raw capabilities. Anthropic, along with competitors like OpenAI and Google, has been iterating on these mechanisms (extended cache windows, project-level memory, persistent knowledge bases) precisely because power users are pushing against the limits of session-based interaction. However, threads like this one highlight a recurring friction point: documentation that uses everyday language ("cached for future use") without precisely specifying scope, duration, or mechanism leaves technically sophisticated users unable to reliably optimize their own usage, forcing them into speculative workarounds rather than informed engineering decisions.

Read original article →