Context cost of N file uploads
What you'll learn
N attached files cost roughly N × file_size of context every chat — there is no caching, no retrieval, no separate budget.
- Per-message cost ≈ N × file_size, paid every turn. No caching at this layer.
- Conversation budget = window − attached files. Heavy Projects shrink the budget visibly.
- Quality degrades from attention competition before the hard window limit fires.
B1.1 established the qualitative claim: a Claude.ai Project is in-context file storage, not retrieval. B1.4 makes that quantitative. Every file you attach to a Project is concatenated into the system context on *every* chat, every turn — there is no caching, no on-demand load, no top-k. The per-message cost of N files is roughly N × file_size in tokens, paid every turn for the life of the Project.
Two things follow from that. First: the budget the conversation and the model's answer get is what's left of the context window after the files are loaded. With a 200 KB context budget and 150 KB of attached files, the user message and the answer share the remaining 50 KB. The 'context window feels small' complaint on a heavily-loaded Project is a direct consequence of this math, not a subscription tier issue.
Second: even when N × file_size still fits, attention quality degrades non-linearly. The model has to find the relevant tokens inside an ever-growing wall of content. Distractor passages compete for attention with the actual question. The breaking point arrives long before the hard window limit — usually as 'answers get vaguer / cite the wrong file' rather than as a visible error.
The decision rule is mechanical. If the access pattern is *every chat needs all of it*, a Project is the right shape and you must size N × file_size to leave conversational headroom. If the access pattern is *only the relevant slice should land in context*, you've outgrown a Project and you need retrieval (RAG / MCP server / search tool). Adding more files to a Project that's already too big does not help. It is the failure mode.
Key points
- Per-message cost ≈ N × file_size, paid every turn. No caching at this layer.
- Conversation budget = window − attached files. Heavy Projects shrink the budget visibly.
- Quality degrades from attention competition before the hard window limit fires.
- Threshold question: must every chat see all of it? If no, switch to retrieval — don't add files.
Examples
Window: ~200,000 tokens. Files: 12 PDFs, ~10,000 tokens each = 120,000 tokens of system context every chat. Conversation + answer share ~80,000 tokens — usually fine. Now add the 13th file at 100,000 tokens (a long policy doc): you've blown past the window and the Project will start dropping content silently. The fix is not 'shorten the conversation' — it's pulling that 13th file out of the Project and behind retrieval.
User reports: 'Claude is forgetting earlier turns sooner than usual.' Project has 8 files attached. Total: ~140,000 tokens of files in a 200,000-token window. The conversation budget is ~60,000 tokens — earlier turns are being squeezed out by the file load, not by anything wrong with the conversation. The fix is structural: drop files that don't need to be in every chat.
Pitfalls
- Believing 'Claude.ai caches Project files between turns.' It does not at this layer; cost is paid every turn.
- Assuming a separate 'file context budget' exists. There is one window, shared by files + conversation + answer.
- Treating 'add another file' as the default response when answer quality drops. The opposite is usually correct: pull files out and switch the access pattern.
Source notes: 00-academy-basics/notes/01-claude-101.md
Ask Claude
Build a prompt with this lesson + your question, copy it, and open the Claude Project in a new tab.