If you're trying to figure out how to use Claude Projects well, my advice is to treat a project as one ongoing stream of work that you brief once and keep feeding. Since the September 2026 redesign, a project is a chat with a coordinator that starts a thread for each task, and each thread is a full Claude Code session. You get the most out of it when your standing rules live in the project instructions, memory picks up your decisions as you go, and you answer the threads that are waiting on you. I run this site, davit.cc, in a project, so every example here is from my own setup.
What changed in September
Anthropic announced it on September 17, 2026, in Projects redesigned: from folder to conversation. The old Projects in claude.ai chat were basically a folder: some reference files, custom instructions and the chats you had inside it. The new ones live in Claude Code. You talk to one coordinator in the project chat, and it decides whether to just answer you or start a thread. Each thread is a cloud session with its own branch and its own copy of the repo. Threads report back to the coordinator, share one memory, and leave their files in the project's Library.
A few practical things from the Claude Code docs, as of October 2026:
- Projects are in public beta on the Pro and Max plans and still rolling out. They aren't on Team or Enterprise yet.
- You use them at claude.ai/code, in the Code tab of the desktop app and in the mobile app, but not in the terminal CLI or the IDE extensions.
- The old folder-style projects in claude.ai chat and Cowork keep working until the new version reaches them.
A lot of the guides that rank for "how to use Claude Projects" still describe the folder version. This one is about the new one.
When a project is worth it
A project makes sense when the work has a goal that outlives one session and keeps producing new tasks. The docs give examples like one change across many repos, an area you keep feeding bugs into, a migration that's bigger than a session, and work that isn't code at all, like a folder of contracts you keep asking questions about.
If it's one task that fits in one session, a normal cloud session is enough. If every step needs your own machine, a local session fits better. And a job that runs on a schedule with nobody talking to it is a routine.
My personal site is the ongoing kind. Since October 8 the davit.cc project has done a full redesign, a new favicon, four small Playground experiments and these blog posts. None of that fits in one session, and all of it follows the same rules.
Let Claude propose the setup
I didn't write my setup myself. The first thing I sent in the new project was this:
Help me set up this new project from my recent work. Look through my recent sessions and repositories, identify the main thread of work, and propose a project setup: a short name, the repositories it should include, an environment, concise project instructions drawn from what kept coming up, and one or two optional routines. Show me the proposal before changing anything.
Claude went through my last 46 sessions from the previous four weeks, picked out the one line of work that belonged here (deploying davit.cc), and came back with draft instructions and an optional weekly check of the live site. Nothing changed until I said "yes". If you already have a cloud session doing the work, "Continue as project" in its menu does the same thing from there.
Write instructions a thread can follow
Project instructions are the brief the coordinator and every new thread start from, and they can be up to 16,000 characters. A good brief says what the project is for, where the work happens (repo, branch, how pull requests are named), how a thread checks its own work, what to do when something it needs is missing, and what needs your go-ahead.
Mine for davit.cc fit in one paragraph:
Site is davit.cc, built from the main branch of davit-khaburdzania.github.io and served by a Cloudflare Worker (wrangler.jsonc). Davit is the only one working on the site, so don't open pull requests: commit and push straight to main. Every push to main deploys davit.cc automatically within about a minute (Cloudflare's GitHub connection), so a push is a production change: show Davit a preview of visual changes before pushing. Keep profile details (location "Tbilisi, Georgia", website davit.cc) consistent across the site, GitHub and LinkedIn. Verify changes on the live site after each push.
The first version was wrong, by the way. It said the site was served from the master branch. The first thread read the repo, found a Cloudflare Worker serving main, and a few minutes later the coordinator had fixed the instructions. The rule about pushing straight to main came a day later, when I told a thread to remember that I'm the only one working on the site and I don't want pull requests. The preview rule came right after that, once we'd confirmed that every push deploys.
Two things are easy to miss. Changing the instructions only affects new threads, so a thread that's already running keeps the old brief. And instructions are for rules. Facts about one repo, like build commands, belong in that repo's CLAUDE.md.
Instructions, memory and CLAUDE.md
A project keeps context in three places, and each one has its own job:
| Where | What goes in it | Example from davit.cc |
|---|---|---|
| Project instructions | Rules every thread needs from its first message | Push straight to main, and show a preview of visual changes first |
| Project memory | Decisions and pitfalls Claude collects as you work | "Pixel is better": the favicon and Pet the Shiba use the pixel-art Shiba |
CLAUDE.md or AGENTS.md in the repo |
How the code is built and styled | "Light only. Never use green accents." |
Project memory is a set of files Claude writes itself. Every cloud thread reads the index file, MEMORY.md, when it starts and opens the other files when it needs them, and you can read and edit them under Project settings > Memory. You fill it just by asking: "remember that Unposed goes last in the Projects list" is enough. Mine holds the design decisions from the redesign, the fact that Paper only runs on my Mac, and the three topics I picked for this blog.
If you only write one of the three, make it the repo file, because every session reads it, in a project or not. My AGENTS.md is 64 lines on how the site is built, shipped and styled, and CLAUDE.md just points to it, so every thread and every other agent reads the same rules.
Send work, then walk away
Once that's set up, you talk to the coordinator the way you'd talk to a colleague. A quick question gets an answer right in the chat. New work becomes a thread, or goes to a thread that's already working in that area, and if you send a few unrelated things in one message, they become separate threads. This blog started with one message from me, and the coordinator started a thread with context from memory already attached: the three post topics I'd picked two weeks earlier.
The Overview pane groups threads by state: Ready for review, Waiting on you, Working, Landing, Idle and Resolved. When a choice changes what I'm building, the thread asks on a card with two to four options and a recommendation. For my CV, the card asked whether Claude should edit the PDF or I'd export it myself, and I picked "I'll do it".
You can also just tell the coordinator how you want the project run. The docs give examples like "Propose threads and wait for my go-ahead before starting them", "Run at most two threads at a time" and "Only post when something finishes or is blocked". Claude saves these to memory and follows them, though a thread limit set this way isn't enforced.
Approvals are the one part that isn't obvious. Threads run in auto mode, so most commands just run, but when a thread does need your approval, the prompt shows up inside that thread. Telling the coordinator "go ahead" doesn't reach it, so open the thread and answer there.
Run a thread on your own computer
Some work has to happen on your own machine: a local database, a device simulator, or an app that only runs on your laptop. For me that's Paper, the design tool I use, which only runs on my Mac. A project can run that one thread on your computer through Remote Control while everything else stays in the cloud.
To set it up in the desktop app, go to Settings > Claude Code, turn on "Use this computer from your phone and claude.ai" and add the folder. Or run claude remote-control in that folder from a terminal. Both need Claude Code v2.1.280 or later. Then pick "Work locally" from the + menu in the project chat, describe the task, and allow it on the card.
A thread on your computer uses that machine's files, tools, MCP servers and settings. It gets the project instructions but not the memory files, so anything it needs to know has to be in the instructions or the task. It also pauses while the computer sleeps.
Keep usage under control
Projects use up your plan faster than a single session, because every thread is a full Claude Code session and several can run at once. New projects run threads on Opus at high effort, and you can change the models and effort for threads and the coordinator in Project settings > General. There's also a hard limit of 200 new threads per day across all your projects.
Long threads cost more than they look. The redesign thread grew to 165 replies over two days. When a thread has been idle longer than the cache lifetime (an hour on Pro and Max), the next message makes Claude re-read the whole conversation before it does anything. So now new work gets a fresh thread, and I resolved the redesign thread. Threads that watch a pull request also wake up when CI fails or a review comes in, so tell a thread to stop watching once you're done with it. The Usage tab in project settings shows where the tokens went, by thread and by model.
Frequently asked questions
When should I use a project instead of a chat?
When the work outlasts one session and keeps producing tasks, like a product, a migration or a site you keep improving. A one-off question is fine in a chat, and a single coding task fits in one cloud session.
What's the difference between Claude Projects and Claude Code?
Projects are built on Claude Code. Every thread is a Claude Code session, usually in the cloud. The project adds the coordinator, shared instructions and memory, the Library of files, and the Overview pane that keeps track of every thread.
Can I share a Claude Project with my team?
Not during the beta. A project belongs to one person, and thread transcripts can't be shared. If your team wants to give Claude work together in Slack, Anthropic points to Claude Tag instead.
Do cloud threads get my local skills and MCP servers?
No. Cloud threads get the connectors on your claude.ai account, the skills you've enabled there, and the skills, agents and commands committed to the project's repos. Anything installed only on your laptop is missing unless the thread runs on your computer.
I wrote more about the day-to-day side in my agentic coding workflow, and the rest of my background is on my CV.