TLDR
A Claude Project is a self-contained workspace with its own chat history and its own knowledge base, configured through two layers: project knowledge (uploaded files) and project instructions (a standing behavioral brief). Claude Help Center: what-are-projects Nothing said in one chat automatically becomes visible to other chats in the same project - only what's explicitly placed in knowledge or instructions persists, and keeping those instructions swapped and current is a recurring maintenance task, not a one-time setup step.
What it is
A Project is distinct from a plain one-off chat: every chat started inside a Project belongs to that Project and draws on a shared knowledge base and shared instructions, so a recurring piece of work, a client account, a role, a workflow, doesn't require re-explaining context every conversation. What's shared is the knowledge and the instructions, not the conversational memory itself - each individual chat inside a Project is still its own separate thread, and one chat's back-and-forth is not automatically visible to another chat in the same Project. Two configurable layers do the sharing. Project knowledge is whatever gets uploaded, documents, text, or code the project can draw on. Project instructions is a standing brief telling Claude how to behave inside that project specifically, tone, role, or industry perspective, separate from any single chat's back-and-forth.
Configuring a Project is only half the objective. The other half, informing, maintaining, and updating that configuration as needs change, is just as tested: a Project set up once and never revisited drifts stale exactly the way a document left unedited does. Swapping an outdated uploaded file for a current one, or editing instructions when a role or engagement changes, is the ongoing maintenance half of this skill, not a one-time task.
How it works
Setting up the two layers is a UI action, not engineering. To add knowledge, click "+" on the project's knowledge panel and upload documents, text, or code. To add instructions, click "Set project instructions," write the brief, and click "Save instructions." Projects are available to every user, including free accounts, though free accounts are capped at a maximum of five projects.
Context does not silently carry across chats. A single chat's back-and-forth inside a Project does not automatically become project-wide context for other chats, only content explicitly placed in the knowledge base or the instructions persists across every chat in that Project. This is the single most commonly tested misunderstanding in this domain.
Knowledge capacity scales without manual setup. RAG (retrieval-augmented generation) for Projects is now available on every plan, free, Pro, Max, Team, and Enterprise, and activates automatically once project knowledge approaches its context-window limit, retrieving only the most relevant snippets per query instead of loading the whole knowledge base every turn. This expands effective capacity by up to 10x with no configuration required, and the system can revert to standard processing if the content volume later shrinks.
Instructions exist at three separate tiers, and only one is Project-specific. Account-wide "Instructions for Claude" apply to every conversation regardless of Project. Project instructions apply only inside that one Project. Skills add reusable behaviors or capabilities Claude can invoke, a related but distinct "styles" control also exists for response formatting specifically, so a business user configuring a Project should default to Project instructions for anything scoped to that Project alone, not the account-wide layer.
Maintaining a Project (CCAOF-D5-O4) means keeping instructions concise and swapping stale knowledge, not writing a longer brief. Anthropic's own guidance is that Claude performs best when project instructions carry general context, key guidelines, and Claude's role, while task-specific detail for one particular ask belongs in the individual chat instead, because shorter instructions leave more context budget for the knowledge that actually needs to be retrieved. When an underlying document changes, a renegotiated contract, an updated policy, the maintenance action is replacing the uploaded file and revising instructions if the role or tone shifted too, not layering a correction into a single chat that other chats in the Project will never see.

Where you'll see it
Client onboarding Project
A PM uploads the client's SOW, prior meeting notes, and a style guide to project knowledge, then writes project instructions telling Claude to answer as a senior consultant in a formal tone, every new chat inherits both automatically.
Ongoing policy-reference Project maintenance
An HR team keeps an internal policy-Q&A Project current by replacing the uploaded policy PDF each time a policy updates, rather than letting the Project answer from a stale document indefinitely.
Side-by-side
| Layer | Scope | Persists across chats in the Project? | Best for |
|---|---|---|---|
| Instructions for Claude (account-wide) | Every conversation, any Project | Yes, everywhere | General preferences that apply no matter what you're working on |
| Project instructions | One Project only | Yes, within that Project | Role, tone, and general context specific to this Project |
| Project knowledge (uploads) | One Project only | Yes, within that Project (via RAG once large) | Reference documents the Project needs repeatedly |
| A single chat's own conversation | That one chat only | No | Task-specific, one-off instructions for the current ask |
Decision tree
Will multiple future chats in this Project need this information, not just the one you're in now?
Is the underlying source document (contract, policy, SOW) now out of date?
Is the instruction general (role, tone, scope of the Project) rather than specific to one task?
Does the Project's knowledge base now approach the context-window limit?
Question patterns

A consultant has a long, detailed discussion about a client's edge-case pricing scenario in one chat inside their "Client X" Project, then opens a fresh chat in the same Project expecting Claude to already know about it. What happens?
"anything discussed in any chat within a project is automatically available to other chats in that project" overstates it - that blanket automatic sharing is not the default behavior.A PM writes a 2,000-word project instructions document containing step-by-step formatting rules for one specific Friday deliverable. Is this the right place for that content?
"put all task-specific detail into project instructions since it's more thorough" inverts the actual best practice.A free-tier user already has 5 active Projects and tries to create a 6th. What should they expect?
"free accounts have unlimited projects since Projects launched to everyone" confuses availability to all users with an unlimited count, Projects are available to free accounts, but with a five-project ceiling.A Team-plan Project's knowledge base grows past its context-window limit over several months of uploads. What does the admin need to configure to keep the Project working well?
"the admin must manually enable RAG mode in project settings before it activates" describes a configuration step that does not exist, activation is automatic.A vendor contract inside a "Q3 Vendor Review" Project's knowledge base gets renegotiated with new terms. The PM pastes the new terms into today's chat so the current conversation reflects them. Is this sufficient maintenance?
"paste the new terms into today's individual chat so this conversation has them" fixes the symptom in one chat, not the underlying stale configuration every other chat in the Project will keep seeing.Frequently asked
Is everything discussed in one Project chat automatically remembered by other chats in the same Project?
Do I need to manually turn on RAG when a Project's knowledge base gets large?
Work this with your AI
Work this concept hands-on with Claude Code, Codex, or claude.ai. Copy a prompt, paste it into your assistant, and practise in tandem. Each one keeps you active (explain it back, get drilled, or build) rather than just reading.
- Drill it like the exam (scenario MCQs)Practice in the exam's scenario-MCQ format with trap awareness.
- Explain it back (Feynman)Build durable, transferable understanding of a concept you can half-state.
- Test me, adapting the difficultyActive recall practice on a concept you think you know.
- Check my prerequisites firstBefore studying a concept that keeps not sticking.
- Find the high-leverage 20%When a domain feels too big and you are short on time.
