Projects: what belongs in one, what poisons it

A project is a folder of chats that share a body of uploaded knowledge and their own memory. Upload the style guide once and every chat in the project has it, which saves re-attaching the same files forever.

The thing to understand before you fill one up is that a project has two modes, it switches between them on its own, and it does not tell you when it has.

The switch that happens without asking

While the knowledge base is small, its contents sit in the context window and the model reads all of it. As the project grows, Anthropic's documentation says retrieval takes over "when your project approaches or exceeds the context window limits", which raises capacity to "up to 10x more content".

In that second mode Claude uses a project knowledge search tool: "Instead of loading all project content into memory at once, Claude intelligently searches and retrieves only the most relevant information needed to answer your questions."

So past a threshold you cannot see, the model stops reading your documents and starts searching them. Anthropic states that accuracy stays consistent between the two modes. Treat that as the vendor's position — no evidence for it is published, and it is a claim about average behaviour, which is a different thing from a guarantee about the one document you needed.

What belongs in one

Material that is stable, reusable across many chats, and that you would otherwise paste repeatedly: style guides, schemas, standing requirements, terminology, a description of how your team works.

Name the files so the names say what is inside. Under retrieval, the filename is part of what gets matched, so pricing-policy-2026.md earns its place in a way that final_v3.docx does not.

What poisons one

Volume for its own sake. The instinct to upload everything relevant is the instinct that pushes the project over the threshold and converts a read into a search — and the material that pushes it over is usually the material you cared about least.

Superseded versions are the sharpest version of this. Two drafts of the same policy in one knowledge base means retrieval can surface either, and the answer gives no sign which one it used. Delete the old one rather than keeping it for reference.

One-off material belongs in the chat, not the knowledge base. A document you need for a single question costs every other chat in the project if you put it in the shared space.

Limits worth knowing

Project files are capped at 30 MB each, with no limit on the number of files beyond what the context window can hold. Files attached to a single chat get a higher ceiling — 500 MB each, up to 20 files per chat — which is another reason one-off material belongs there.

Try this

Open a project you have used for a while and read its knowledge base as a list. For each file, answer: would I paste this into most chats here? Anything that is a no is either chat-level material or dead weight, and removing it is the cheapest quality improvement available.

What goes wrong

Uploading the whole drive. More project knowledge is not more capability past the point where it triggers retrieval. It is the same material, less reliably reached.

Keeping old versions "just in case". Retrieval has no concept of which document you consider current. Both are equally eligible.

Reading a project summary as a brief. The summary reflects what has been discussed, so it tracks your recent activity and not your standing requirements. Requirements go in the knowledge base where you control the wording.

One project for everything. Projects earn their keep by scoping context. A project holding three unrelated workstreams has the retrieval problem and the context problem at once.

How to check it worked

Ask a question whose answer sits in one specific uploaded file, and ask it to quote the passage it used. A verbatim quote means the material was reached. A paraphrase that could have come from general knowledge means it may not have been, and that is the moment to prune the knowledge base rather than to trust the answer.