Anthropic Rebuilt Claude Code Projects Around Threads and a Coordinator Instead of Folders

Anthropic redesigned Claude projects from a folder into a conversation on September 17, 2026, releasing the new structure in beta inside Claude Code. In a redesigned project the user sets a goal and a repository, and Claude scopes the request, delegates the work, coordinates parallel threads, reviews the outputs, and assembles the finished result. Each thread is a Claude Code cloud session working on its own branch and copy of the repo, and when two threads touch the same code the overlap is resolved as a merge conflict just like any other pull request. The beta opened first to select Claude Pro and Max subscribers who use cloud sessions in Claude Code and have no existing projects on web or desktop. ASAP separates out how this structural change moves two axes that matter more than the convenience features: cost and merging.

The definition of a project moved from a folder holding files to a conversation delegating work

What Anthropic changed is the definition of the project unit itself, and the announcement title says so directly: from folder to conversation. Until now, work spanning multiple sessions required the user to divide the work, juggle handoffs, and stitch the results back together. In the redesigned project, you describe what needs to get done and Claude manages the work.

Starting a project means selecting a goal plus the repo or context. Claude then suggests work it can pick up right away. The configurable surface covers the project's cloud environment, connectors, plugins, instructions, and model.

There are two paths for following progress. You can monitor and guide from the main project chat, or dive into each individual thread to examine and steer the details. Anthropic describes the usage pattern as briefing Claude in the project the way you would brief a chief of staff, after which it routes work to new or pre-existing threads. You can steer from your phone, and the work keeps going after you step away from your computer.

One thread is one cloud session and one branch

In the internals Anthropic describes, each thread is a Claude Code cloud session working on its own branch and copy of the repo, with the coordinator sitting above them keeping the work organized. With repositories connected, a thread opens pull requests and runs your tests. With documents connected, it reads them and drafts.

There is one more layer of subdivision available. Each thread can further split its delegated work into pieces using subagents, loops, and workflows when needed, which Anthropic frames as a way to make large assignments finish faster.

The two scenarios in the announcement show what the structure is for. One sets a goal of reducing an app's checkout p75 latency, then profiles each endpoint, tests optimizations, and opens PRs in parallel threads. The other connects API, web, and mobile repos with a goal of retiring a deprecated v1 endpoint, where Claude creates a thread per repo to migrate the callers, run the tests, open PRs, and then tells you which ones need to merge first.

The sentence about merge conflicts carries more design information than any feature claim

The most informative sentence in this announcement is not about performance but about conflict handling: if any threads work on the same code, Anthropic writes, the overlap is resolved as a merge conflict just like any other PR. The coordinator's job is to keep work organized, not to prevent threads from stepping on each other in advance.

Read that as a design decision rather than an evasion. Preventing collisions between agents editing one codebase in parallel would require locking at the file or symbol level, or partitioning the work so scopes cannot overlap. Both approaches either reduce parallelism or assume the coordinator knows the real dependency structure of the code. Handing the problem to branches and merge conflicts drops that assumption and gives integration to tooling that has been validated for decades.

The cost lands on the user. When five threads have opened pull requests, the work of checking that they do not contradict each other does not disappear; it moves to review time. The detail in the v1 endpoint example, where Claude tells you which PRs need to merge first, is the mechanism meant to absorb that load, and how accurate that guidance turns out to be will decide whether parallel threads pay off. The hard part of parallel agent work is the joining, not the splitting, and this design puts that difficulty in a familiar place rather than hiding it.

Shared memory and a library accumulate at the project level

Alongside the thread structure, the axis Anthropic emphasizes in this redesign is memory: every thread adds to and draws from a shared memory. The company states that this reduces the need for complex prompt engineering.

The examples given of what gets remembered show what kind of feature this is. Claude can remember that the release moved to Friday, why the export was dropped, or who to check in with before touching the billing service. None of that lives in the code; it lives in conversations and decisions. Claude also remembers your working and communication style, and you can ask it to adjust how often it checks in, how frequently it starts new threads, or how detailed to make each update.

Next to memory sits a library. It collects the files you add and the artifacts produced by Claude, making it easier to find relevant materials and letting new work build on past efforts. Anthropic states that projects are designed for long-running or agentic workflows, meaning work that takes longer than one reply and has more than one part.

Usage limits are the real price tag on this design

The first thing Anthropic raises under "What's next" is not a feature but a cost: because projects run several threads at once and each one is a full Claude Code session, projects can reach usage limits faster. In response, you can check project-specific usage and select the model and effort levels used by the coordinator chat as well as by the worker threads.

That paragraph exposes the economics of parallel agent products directly. Adding threads reduces wall-clock time but does not reduce total token consumption, and it likely increases it, since each thread reads repository context on its own. Inside a subscription, opening this structure makes limit exhaustion the first wall a user hits.

That is why choosing models and effort separately for the coordinator and the workers looks less like an extra setting and more like a required control. Coordination and review are judgment work where a stronger model pays off, while workers performing a defined migration repeatedly are often fine on a lighter setting. Without that separation, the gain from parallelism gets eaten by the rate at which limits burn down. The first thing a team trying projects should do is not open many threads but measure, on their own repository, which assignment across the two layers produces the best output per unit of quota.

Cloud first and local later is what decides who can adopt this now

In this beta, threads run in the cloud today, and running on your machine alongside your local tools and code and behind your network is described only as coming very soon. The eligibility rules point the same way: access opened first to Pro and Max subscribers using cloud sessions in Claude Code who have no existing projects on web or desktop.

Cloud-first follows from the product's central promise. Work continuing after you step away from your computer, and steering from your phone, only holds when execution lives outside the user's machine. Local execution makes that promise harder to keep.

The ordering does split the field of adopters for a while. Organizations whose code cannot leave the internal network have no way to evaluate the benefit of parallel threads yet and must wait for local execution to actually ship. Environments built on network segregation and export controls, such as finance and public-sector work in Korea, fall into that group. For teams already working in cloud development environments, the opposite holds and now is the time to test the structure. The note in the same announcement that existing Pro and Max projects keep working as they do today, and will be upgraded as the rollout expands to chat and Cowork, reads as an attempt to keep the transition from breaking all at once.

The absence of any numbers is the most conspicuous gap in this announcement

Anthropic's September 17, 2026 announcement contains zero quantitative figures, with no concurrent thread count, no speedup and no success rate anywhere in it, offering only a structural description and 2 usage scenarios. For a launch built on parallelism, the absence of any measurement of parallelism is itself worth noting.

The unconfirmed items line up as follows. First, the upper bound on how many threads one project can run at once is not stated. Second, the criteria the coordinator uses to assign work to threads, and the basis for its merge-order guidance, are not explained. Third, the path for correcting or deleting a shared memory that recorded something wrong does not appear in this post. Fourth, the size of the beta cohort, the pace at which the waitlist clears, and the specific criteria for the expansion "over the coming week" are not disclosed.

That narrows what a team can decide today to one thing: counting how many genuinely independent tracks of work their own repository actually supports. If that number is small, the thread structure mainly burns quota faster. If it is large, the accuracy of the merge-order guidance determines the real gain. Either way, the basis for the judgment comes from the codebase, not the announcement.

Source: Projects redesigned: from folder to conversation (Anthropic, September 17, 2026)