Heads up: some links below are referral links. They cost you nothing extra and never change what we recommend. How this site makes money.
The short answer
A Project is a self-contained workspace with its own chat history, its own uploaded knowledge, and its own custom instructions. Everything you say inside it inherits that context automatically.
Free accounts get up to five Projects. Paid plans get unlimited Projects plus retrieval, so the knowledge base can be far larger than a single conversation could hold.
| Free | Paid (Pro / Max / Team) | |
|---|---|---|
| Number of projects | Up to 5 | Unlimited |
| Knowledge base | Yes | Yes, with retrieval |
| Custom instructions | Yes | Yes |
| Scales past the context window | No | Yes, via RAG |
| Share with teammates | No | Team & Enterprise |
What a Project actually is
Three things bundled together:
- A knowledge base. Documents, code, notes — uploaded once and available to every conversation in the Project.
- Custom instructions. Standing directions that apply to every chat inside it: tone, role, house style, things to always or never do.
- Its own chat history, so work on one topic stays together instead of scattered through your main conversation list.
The point is eliminating repeated setup. Every conversation starts already knowing the context.
Why the paid version is different
On a free account, project knowledge has to fit the context window. That's a real constraint once you have more than a handful of documents.
On paid plans, Projects use retrieval — Claude pulls the relevant parts of a large knowledge base as needed rather than loading everything at once. In practice that means you can put a genuinely large body of material in and it still works.
This is one of the more concrete reasons to upgrade, and it's rarely mentioned in plan comparisons.
When a Project is worth setting up
The test: are you pasting the same context more than twice a week? If yes, make a Project.
Cases where it pays off quickly:
- Writing in a consistent voice. Put your best existing writing in the knowledge base and style instructions in the custom instructions. Every draft starts closer to right.
- A specific codebase. Architecture notes, conventions, key files — so you stop re-explaining how the project is structured.
- A client or account. Their background, preferences and past decisions in one place.
- A recurring report. Format, definitions and previous editions, so each new one matches.
Not worth it for one-off tasks. The setup only pays back through repetition.
Getting custom instructions right
The most common mistake is being vague. "Be professional" does almost nothing.
Specific and testable works far better:
You are writing for experienced engineers. Assume they know the fundamentals. British spelling. No bullet-point lists unless I ask. Never open with "In today's fast-paced world". If a claim needs a source and I haven't given you one, say so rather than inventing it.
Each of those is checkable. Vague instructions produce vague compliance.
Common questions
How many projects can I create?
How big can a project knowledge base be?
Can I share a project with my team?
Do projects use more of my usage allowance?
Projects work on the free tier
You get five to experiment with before deciding whether unlimited projects and retrieval are worth upgrading for.