The new Claude Projects: a working setup for one-person teams

On September 17 Anthropic rebuilt Claude Projects around parallel work: one conversation that splits your backlog into cloud threads and reviews what comes back. By September 28 my competitor tracker had Riley Brown's walkthrough at 105,300 views, 3.21 times his channel's baseline, so the interest is measured. I read the docs and the fine print. The redesign is real, the defaults are expensive, and the beta will not even let most longtime users in. Here is the setup I would run as a one-person team.

Published October 13, 2026 · By Dmitry Tolstoi · 9 min read

What actually changed in Projects?

In short: a project stopped being a folder with chats and turned into one conversation that spawns and reviews parallel Claude Code cloud sessions.

The old Projects, the one most people know from claude.ai, was storage: a folder holding files and a stack of chats that shared them. The redesigned project is one long-running conversation where Claude works as a coordinator. Anthropic's announcement describes the loop in one sentence: "Claude scopes the request, delegates the work, coordinates parallel threads, reviews the outputs, and assembles the finished result." You paste a bug report, a spec or a list of tasks; the coordinator decides what becomes a thread and collects what each one reports. Threads run in the cloud, so they keep working after you close the laptop. The beta opened on September 17, 2026 (MarkTechPost's launch coverage). "Describe the goal, come back to pull requests" is exactly what a person running a company alone wants to believe in; whether it holds up depends on the details below.

The three parts: conversation, threads, Overview

In short: you talk to one coordinator, each thread is a full Claude Code session on its own branch, and Overview shows which threads need you.

Everything enters through the project conversation. A quick question gets an answer in place; new work becomes a thread or lands in one already covering that area. The coordinator sees what threads report; it does not watch every step they take. A thread is a complete Claude Code cloud session with its own context window, its own clone of the repository and its own branch. When it changes code it can open a pull request, and from that point it watches the PR with auto-fix on: it pushes fixes when CI fails and answers review comments. The Overview pane groups threads by state - Ready for review, Waiting on you, Working, Landing, Idle, Resolved - plus a Library tab for files. For one person that pane is the morning standup: what finished overnight, what is blocked on your answer. If you have been juggling parallel sessions by hand, the discipline is the same one senior engineers run in the agentic engineering workflow I broke down earlier, with the handoffs automated.

Can you even get the beta?

In short: only Pro and Max accounts that used cloud sessions and have no old projects get in; everyone else joins a waitlist.

The access conditions are the sore spot. The beta started with select Claude Pro and Max subscribers who use cloud sessions in Claude Code and, read this twice, "don't have any existing projects on the web or desktop." Luis Chavez-Mattos at MindStudio put it plainly in MindStudio's September note: "if someone has been using the older Projects feature at all, they are currently locked out of the new one, regardless of their subscription tier." So the people who used Projects hardest wait the longest. Existing projects keep working as they do today, Team and Enterprise plans come later, and there is a waitlist if Projects does not show in your sidebar at claude.ai/code. Join the list and spend the wait on the setup below, so day one is not spent discovering the defaults.

A first setup that does not waste your week

In short: install the Claude GitHub App, add the one repository most tasks touch, send one small task, and read the thread before batching.

The prerequisites are specific. Your code has to live on github.com; GitHub Enterprise Server, GitLab and Bitbucket are out for now. Cloud threads need the Claude GitHub App installed on the repository, and the token from /web-setup that covers normal cloud sessions is not enough for a project's threads. Then create the project, give it a name and a one-line goal, and add the one or two repositories nearly every task touches; a thread can pull another repository into itself when a single task needs it. Then resist the batch. Send one small piece of real work, then read how the finished thread reported and what it did on its branch. Anthropic's Projects docs themselves suggest telling Claude to "propose threads and wait for my go-ahead before starting them" until a few come back the way you want. Twenty minutes of that beats a day of cleaning up eight threads that all inherited the same wrong assumption.

Project instructions: the brief every thread starts from

In short: one block of up to 16,000 characters reaches every new thread; it is where a solo operator encodes judgment once.

Every new thread starts from the project instructions, so a rule you state once reaches all of them. Mine would carry four things, in this order: which branch to start from and how to name pull requests; how a thread proves its work before calling it done (run the tests, paste the summary lines); what to do when something is missing - the example brief in Anthropic's docs says "say exactly what's missing in your first message and stop. Don't substitute, mock, or guess", which is the single best line to steal; and what needs my explicit go-ahead. That last one matters more for a one-person company than for a team, because there is no colleague to catch a thread merging its own pull request. The human-gate rule from my one-person agent playbook applies unchanged: anything that spends money, touches production or talks to a human waits for me. Corrections go to project memory. Tell Claude to remember a pitfall after one fix, and later threads start knowing it.

What does a project do to your usage limits?

In short: every thread is a full session on the same plan allowance, so a project reaches your limit noticeably faster, on Pro especially.

The New Stack headlined its coverage "Anthropic's new Claude Code feature could drain your plan before lunch", and the documentation quietly agrees: a project "uses your limits faster than a single session does, and on a Pro plan in particular you should expect to reach your limit sooner." Each running thread is a full Claude Code session, several run at once, and the coordinator itself spends tokens reading reports and deciding what happens next. A limit you set in conversation, like "run at most two threads", is a preference Claude keeps to; the only enforced ceiling is 200 new threads per day across your projects. Two behaviors matter before you leave a project running overnight. An idle thread watching a pull request wakes and spends again when CI fails or a review comment arrives. And a thread that hits your five-hour or weekly limit waits and continues on its own when the window resets - convenient for the work, surprising for the owner who assumed everything had stopped. On the $20 Pro plan I would treat a running project as the main consumer for that day; the $100 and $200 Max tiers exist for exactly this pattern.

Settings that cut the bill

In short: drop the default Opus-at-high-effort threads to a cheaper model and effort, prefer fresh threads over reviving old ones, and cap parallelism.

A new project runs everything on Opus, threads at high effort and the conversation at low. That default is the most expensive position in the menu; Project settings let you set thread model and effort separately from the coordinator's. Opus 5.5 did get 20 percent cheaper in September - I took that launch apart in the Opus 5.5 and Muse guide - and a flagship model on every lint fix is still the wrong trade; route routine work to a smaller model and keep high effort for tasks that earn it. The second lever is thread hygiene. A follow-up sent to a thread idle longer than the cache lifetime, an hour on Pro and Max, re-reads that thread's whole history before doing anything, so a fresh thread for new work is often cheaper than reviving a large old one. Third, have the coordinator answer small questions in place, and tell a thread to stop watching a pull request you already merged. An idle project with no watched pull requests and no new messages spends nothing.

Code is optional

In short: a project with no repository still runs research and writing threads and delivers the files to the Library tab.

A project does not need a repository at all. Threads can research, draft documents and run code in their own sandbox, and they deliver files to the Library tab. The intake limits are concrete: one pick adds up to 100 files and 2 GB with a single file up to 480 MB, a folder comes in as its first 100 files up to 200 MB with nothing over 30 MB, and a project holds up to 10 folders. Uploads are copies: edit a file locally and you upload it again. The docs' own non-code example: a support-ticket export you keep questioning, like "find the ten most common integration mistakes in these tickets." For anyone running content as an operation the shape is familiar: a standing project per publication stream, source material in the Library, one thread per draft, and instructions that carry your voice rules. That maps onto my own pipeline more closely than any chat interface Anthropic has shipped before.

Where it breaks for a solo operator

In short: cloud sandboxes can drop uncommitted work, threads inherit setup gaps together, and a project cannot be shared or run from a terminal.

Four edges to know before you lean on it. A cloud thread's sandbox pauses between turns, and if it cannot be resumed the thread continues from a fresh clone, so uncommitted changes can be lost; on long tasks, ask threads to commit and push work in progress, and put that line in the instructions. When several threads come back wrong in the same way, the cause is usually one gap in the project's setup; ask the coordinator what each open thread assumed or could not reach, fix the gap once, then resend the work. A project belongs to one account, with no sharing, no handing a thread to a contractor, and no share option on thread transcripts during the beta. And Projects live at claude.ai/code, the desktop app and mobile; the terminal CLI and IDE extensions are not invited, except that a thread can run on your computer through Remote Control (Claude Code v2.1.280 or later) when a task needs your local tools.

Where this comes from

The mechanics, limits and quoted sentences are from the Claude Code documentation page on Projects and from Anthropic's launch post, both read on October 13, 2026. The launch date and beta conditions are from that post and MarkTechPost's September 17 coverage; the lockout quote is from MindStudio's September 19 note by Luis Chavez-Mattos; The New Stack is cited for its headline. Plan prices are Anthropic's public tiers. The view counts are my own tracker's log from September 28, 2026. I have not moved my own operation into the beta yet; when I do, the before-and-after lands here the same way. Nothing above is a promise about how your account or your workload will behave.