The Day "Folders" Became "Coordinators"
On September 17th, Anthropic completely redesigned and released a beta version of Claude Code's "Projects" feature. Previously, Projects were like "folders," bundling several files and a single chat. The new Projects system is reborn, with a single ongoing conversation acting as a coordinator, breaking down larger goals into multiple parallel threads for execution. The title of the announcement, "From Folders to Conversations," succinctly expresses the essence of this change.
A Two-Tier Structure: "Coordinator" and "Workers"
From a technical design perspective, the two-tier architecture of project conversations and threads is interesting. The project conversation acts as the command center, interpreting user instructions, answering simple questions on the spot, and creating threads for the parts requiring actual work. Each thread is an independent Claude Code cloud session, each with its own dedicated branch and repository copy. The thread opens a pull request, runs tests, reads the documentation, and reports a summary of the progress to the coordinator. The coordinator doesn't see every step of the thread; they only receive the reported summary. This design makes sense in preventing context bloat.
Practical Examples
The examples accompanying the presentation are easy to understand. If you want to reduce the p75 latency (the time it takes for 75% of requests to receive a response) of the checkout process, Claude profiles each endpoint and opens a pull request while trying multiple optimizations in parallel threads. Alternatively, if you connect multiple API, Web, and Mobile repositories and give the goal of "retiring deprecated v1 endpoints," Claude creates a thread for each repository, handles caller migration, test execution, pull request creation, and even reports which pull requests should be merged first. The ability to parallelize the tedious but time-consuming migration work across multiple repositories has a significant practical impact.
Differentiating Models and Effort Levels by Role
Another practical design consideration is the ability to individually set the model and effort level (thought level) used for both coordinators and worker threads. This allows for flexible resource allocation; for example, assigning the highest-level model and high effort to coordinators handling complex tasks like situation assessment and task decomposition, and assigning the standard model and low effort to workers handling routine test execution and single-function refactoring. There are reports that by default, each thread is set to run Opus at high effort, which can be seen as an engineering technique to reduce token consumption while maintaining quality.
A Practical Caution: Faster Usage Consumption
A practical caution that cannot be overlooked is that parallel threads consume the plan's usage limit faster than usual. There is a limit of 200 new threads per day, and without paid additional credits, threads that reach the plan limit will wait until it is reset. Threads started by routines are an exception; if they reach the limit, they will terminate with an error in that turn, and the user will need to send a message again after the reset. The parallelization-driven productivity improvements come at the cost of increased operational challenges, particularly in managing usage limits.
Phased Rollout Plan
Currently, the beta is limited to a select group of Pro and Max subscribers using cloud sessions, targeting users without existing projects on chat or Cowork. The plan is to expand to Pro and Max users over the next few weeks, followed by Team and Enterprise Plan users. Existing projects will continue to function as usual until the rollout is complete.
What Engineers Should Note
From single-prompt responses to collaborative work involving multiple agents managed by a coordinator—this shift indicates that AI coding tools are moving from "question and answer" to "autonomous project-based progress management." This makes it an attractive option for tasks where parallel exploration is beneficial, such as migration across multiple repositories or performance tuning. On the other hand, the speed at which usage limits are consumed, and the risk of oversights due to coordinators not having a detailed understanding of the thread's progress, will become clearer as the beta expands, revealing how much it can be relied upon in actual operation.