TL;DR: A Claude Project is a reusable workspace with its own chat history, its own standing instructions, and its own knowledge base. To make one, log in at claude.ai, go to claude.ai/projects, click New Project, name it, and fill in two things: the instructions (how you want Claude to behave in every chat here) and the knowledge base (the files and notes you’d otherwise paste in each time). The part worth getting right on day one is that split. Instructions are how Claude should act; the knowledge base is what it should know. Free accounts can currently keep up to five projects.
If you use Claude for the same kind of task over and over — drafting in a particular voice, reviewing code against one repo, answering questions from the same set of documents — a lot of each new chat is just setup. You paste the same background, restate the same preferences, re-upload the same file, and only then get to the real question. A project is where you put all of that once.
Anthropic describes projects as self-contained workspaces, each with its own chat history and its own knowledge base (the files it can draw on). Everything you set up in a project stays in that project, and every chat you start inside it opens with the same instructions and the same background already loaded. That’s the part an ordinary chat can’t do: a normal conversation starts blank every time, and a long one eventually loses track of what you said up top. A project is where that setup lives.
Making one from zero
Log in at claude.ai and open claude.ai/projects. Click New Project in the top right, then give it a name and a short description. One thing worth knowing up front: Claude doesn’t actually see the name or description. They’re labels for you, to find the project again later, not context for the model.
That leaves you on the project’s page, where two controls matter. The knowledge base is on the right; click the + button to add files, which can be documents, text files, or code. You edit the instructions through Set project instructions: open it, type the standing rules, and save. New chats start from the project’s own chat box, and each one opens with the instructions and the knowledge base already loaded. Nothing on the screen tells you which of your material goes where, though, and that is the part worth thinking about.
Instructions or knowledge base
This is what decides whether a project saves you anything.
Project instructions are standing directions for how Claude should behave in every chat in the project. Claude follows them in every chat, so this is where the rules that never change go: the role you want it to play, the tone, the language to answer in, the format you want back. Write it once, and every new chat in that project already follows it.
The knowledge base is the reference material Claude can draw on: the documents, text files, and code you’d otherwise paste at the start of each chat. Anything you put there is available to every chat in the project, and Claude uses it to understand the background for your questions. This is where the source files, the specs, the notes, and the examples go.
The chats inside a project don’t share memory with each other, though: each one starts from the instructions and the knowledge base, but nothing said in one chat carries into another. The only way information reaches every chat is to put it in the knowledge base.
A concrete case makes it easier to place things. Say you set up a project to help draft blog posts in a consistent voice. The instruction is the part that doesn’t change from chat to chat: write in the first person, keep paragraphs short, skip the marketing language. The knowledge base is the material Claude should have in front of it every time: a few of your past posts as voice samples, a style sheet, maybe a running list of topics you’ve already covered. Open a new chat to draft a post and both are already in place; you just say what the post is about.
A coding project divides the same way. “Follow our naming conventions and explain the reasoning behind your changes” is an instruction; it’s about behavior. The API spec, the schema, and the file you keep referring back to belong in the knowledge base, because they’re what Claude needs to read. Nothing breaks if you mix them up, but keeping the split clean is what makes each new chat short: the standing rules and the reference material are both already loaded, so the only thing you bring is the task.
Free and paid
Free accounts can currently create up to five projects, which the docs give as the cap. That is enough to find out whether the workflow fits how you work.
The paid difference is how much you can load into the knowledge base. On paid plans (Pro, Max, Team, and Enterprise), when a project’s files grow too big for Claude to hold at once, it switches to a retrieval mode called RAG: instead of loading every file whole, Claude pulls in the parts relevant to your question. The docs say this expands capacity by up to tenfold. For a first project of a few files and a page of instructions, that ceiling is a long way off.
Start with the chat you keep restarting
You don’t have to plan it all up front. Put the rules you always end up repeating into the instructions, drop the files you always end up pasting into the knowledge base, and start a chat. You’ll adjust both once you see what Claude picks up on its own and what it misses; the setup isn’t meant to be final on the first pass. So — is there a kind of chat you keep starting from scratch? That’s the one to turn into a project first.
