A Claude project is a workspace inside Claude that groups chats and gives every one of them the same instructions, the same knowledge files, a shared memory and, on paid plans, scheduled tasks. A single chat holds one conversation and loses it at the context limit; a Claude project holds what every conversation needs to start from. Projects are available on free accounts, capped at five, and on all paid plans. I run one project per goal, marketing, one web app and one large redesign, and I stopped searching my chat history.
TL;DR
- A project holds four things a chat cannot: instructions, knowledge files, its own memory, and scheduled tasks (paid, through Cowork).
- What a project does not do: a new chat does not load the old transcript. Memory is topics and a summary, not a log; the truth stays in the repo files, and only the live position travels when a chat rotates.
- One project per goal. I run three (marketing, web app #1, web app #2 redesign), and the 500+ component redesign is the one that made the rule.
Why I stopped searching my chat history
Claude names a chat after your first message. By the time you need that chat again you remember the word you had in your head, not the one you typed, and the search runs through the whole list. I work across Claude, Claude Code and Claude Design every day, so the sidebar fills faster than I can read it.
The fix turned out to be organisational, not technical. One project per task, work or goal, and every chat about it lives inside. Right now I have three: marketing, web app #1, web app #2 redesign. The names are plain. A name I would type into a search box beats a clever one.
A project is a container with four things a plain chat does not have.
What | A single chat | A project |
|---|---|---|
Instructions | Pasted again into every chat, or forgotten | Set once, loaded into every chat |
Knowledge | Files attached to one chat | Files shared by every chat, RAG-expanded on paid plans |
Memory | Account-wide memory only | Its own memory space and project summary |
Scheduled tasks | None | Recurring tasks scoped to the project (Cowork, paid plans) |
Chat search | Across all chats outside projects | Only inside the project |
Project instructions: the prompt I never paste again
Every project has a Set project instructions field. Whatever you save there is loaded into every chat started inside the project, which makes it the one prompt you write once and never paste again. The redesign project's instructions run to a page and read like a contract, because that is what they are: what the project is (the chats here play one role, the advisor in a relay where I carry the messages, Claude Code builds on my machine and Claude Design draws the sheets in a project of its own), the source-of-truth order, the principles, the operating mode, and the hygiene rules for the chats themselves. Three lines from it, unedited:
Product repo > design sheets (design-v3/) > advisor documents > any chat memory.
Commissions <=25 lines, rules referenced by name never restated, only deltas travel.
A gate is never edited to pass in the batch it failed.
Every principle in that file is there because something broke once. The file is the receipt.
The instructions are loaded into every chat, so every line you keep costs context in every conversation. Keep them to what a new chat cannot infer on its own: the role, the rules, the standard the output has to meet. Anything that changes with every batch belongs in a file that travels fresh, not here. The discipline is the same one I described in How to properly configure your AI skills: one place, a structure, and an audit when the output starts drifting from the rule.
What goes into project knowledge?
Project knowledge is the file panel: documents, text, code, anything a chat in the project should be able to read. Every chat inside the project can use it. On free accounts it has to fit the context window; on paid plans Claude switches to RAG mode when the knowledge approaches the limit and expands the capacity by up to 10x, which means it retrieves the relevant parts instead of reading everything.
This is also where the honest line sits, straight from the help center: context is not shared across chats within a project unless it is added to project knowledge. A new chat sees the instructions, the knowledge and the memory. It does not see the previous chat. If a decision has to survive, write it down where the project can read it, or tell Claude to remember it. The trap is staleness. The redesign codebase moves with every batch, so the four repo files that govern it, CLAUDE.md, the design state file, the amendment log and the handoff method, come into each new chat as fresh copies. One stale download once overwrote a live repo copy and destroyed a decision ledger; since then no destructive step in the relay runs without an echoed confirmation, and a stale copy never overwrites a repo copy. Knowledge is for what stays true from batch to batch. What changes with every batch travels with the chat.
Does a Claude project remember previous chats?
Here is the case that made me care. Web app #2 is a codebase that grew for almost a year with code added every day: 500+ components, 100+ screens, and I am redesigning all of it. With AI in the loop the context limit is the wall you hit first. The first chat fills up, you write a summary, you paste it into a second chat, the second fills up, and after a few rounds you no longer know which chat is the live one and which is burned. Moving the summary is slow and you lose things every time. It is the least creative part of a redesign, and it happens on every long one. And the context limit is not even the only killer: image limits alone have ended two advisor chats in this project, and attachments have arrived empty about ten times, which is why the instructions now say text over images and call an empty arrival out the moment it happens.
A project gives that work a floor. Each project has its own memory space and its own project summary, separate from other projects and from ordinary chats. Claude saves what mattered as topics while you work, a decision here, a naming rule there, and you can also say remember this and it does. Memory is on by default on Free, Pro and Max, and everything it holds is listed under Topics in Settings, where you can edit or delete any of it. Memory is not the transcript. It is the list of what mattered, and that is exactly what a burned chat used to take with it. It is also the lowest authority I allow: in the redesign instructions chat memory sits last in the source-of-truth order, after the repo, the design sheets and the advisor documents. What still travels when a chat rotates is the live position only, a short handoff note, because the standing rules are already in the instructions and the truth is already in the repo. The same idea drove my Claude Code setup in Claude Code + Obsidian without the flat log: keep the current state small and current instead of dragging a log behind you.
The counterweight: on paid plans Claude can also search past chats, and inside a project that search only looks at that project. Good for focus, bad if you expected it to find a chat you started outside.
Can a Claude project run tasks on a schedule?
Yes, on paid plans, through Claude Cowork. A project can carry scheduled tasks of its own: you describe the job once, pick the cadence, hourly, daily, weekly, weekdays or on demand, and Claude runs it as a separate session at that time, remotely, even when your computer is asleep or the app is closed. Each run can use the same connectors, skills and plugins as a normal task and lands on the Scheduled page for review. This is the automation layer of a project, and it is the one most people have never opened.
A scheduled task is a full session that runs while you are not watching, so scope it like a cron job, not like a chat. One narrow prompt, one clear output, and one manual run before you trust the schedule. In the redesign the unattended work sits on the Claude Code side, under an overnight protocol that self-commits green batches and ends in a morning review; the one run without that protocol caused the program's only quality collapse. Whatever runs while you sleep needs a protocol, scheduled task or not.
What a project does not do
A project is a container for context, not a bigger context window. The limit per chat is the same; the project just makes starting the next chat cheap. Five more things the guides skip:
- Free accounts get a maximum of five projects. The RAG expansion of knowledge is paid only.
- Scheduled tasks live in Cowork and need a paid plan.
- Claude Code does not have projects. It has
CLAUDE.mdand its own memory, and Anthropic lists project support for Claude Code as planned. If your redesign also runs through Claude Code, the repo files carry that side; the project carries the chats. - Skills are managed for the whole account in Customize > Skills. There is no per-project skill list; the project-level equivalent is the instructions field.
- Claude does not see the project name and description. Put anything Claude must know into the instructions, not the title.
How do I set up a Claude project properly?
The order I use now, for a new goal:
claude.ai/projects, New Project, named after the goal in the words I would search for. Claude never reads the name, so it is for me.- Set project instructions: the goal, the principles, the standard the output has to meet. Short enough to reread in a minute.
- Knowledge: only the files a fresh chat would ask me for. Replace them when they go stale, do not stack versions.
- When a decision lands in a chat, say remember this. That is the moment memory earns its keep.
- On a paid plan, the recurring job goes into the project's scheduled tasks, tested by hand once first.
- When a chat nears the limit, write a handoff of the live position only, then open the next chat inside the project with the opener, that handoff and fresh copies of the governing files. The rules never travel; they are already in the instructions. If the new chat is missing something, that is a gap in the files, and the fix is a file, not a longer paste.
Open your sidebar and count the chats that start with the same first message. That number is how many projects you should already have.
The context limit ends a chat. It should never end the work.
Ogtay Iskandarov
Designer and full-stack developer running klauzzdcode, a one-person studio in Baku. Freelance since 2023, I ship products from Figma to deploy and write down what survives contact with production.