Claude Code now has a beta feature called Projects that lets you hand Claude one large engineering goal and have it run the work in parallel. A coordinator, the Claude instance that plans and routes the work, breaks the goal into tasks and starts a separate thread for each one. Every thread is its own Claude Code session running on its own Git branch in the cloud. The point is to remove the manual juggling that big jobs used to require: configuring sub-agents, keeping several terminal sessions open and managing worktrees by hand. Projects is rolling out gradually to Pro and Max subscribers.
How Projects differs from a regular session
Projects is built from three pieces:
| Piece | What it does |
|---|---|
| Project | One ongoing conversation that serves as the workspace |
| Coordinator | Breaks the goal into tasks and routes every task inside that conversation |
| Thread | An independent Claude Code session that handles one task on its own Git branch in the cloud |
The biggest change is that the coordinator takes over the orchestration you would otherwise do by hand with separate terminal sessions, sub-agents and worktrees.
Because threads run in the cloud, they keep going after you close your laptop, and you can check on them from your phone. When a task needs something only your computer has, such as Chrome DevTools, you can pull that single thread down to your local machine.
The feature fits goals that span several sessions or several repositories. Two examples: removing a deprecated package from an application across multiple repositories, or changing an API endpoint and updating the backend, web front end and mobile app at the same time.
▲ Coordinator dispatching work to threads
Setting up a project
On desktop or the web, open the Claude tab and choose “New project.” The setup screen asks for three things: a name, a goal and the repositories or folders the project can work in.
A worked example shows how this looks for a website whose performance had slipped:
- Name: Site Performance
- Goal: bring p75 LCP under 2.5 seconds and CLS under 0.1 on both mobile and desktop
- Repositories: the marketing site and the API
LCP (Largest Contentful Paint) measures how long the main content of a page takes to appear, and CLS (Cumulative Layout Shift) measures how much the layout jumps around while it loads. Both belong to Core Web Vitals, a set of page-experience metrics. “p75” means 75% of visits meet the number. Writing the goal as measurable targets gives Claude a clear definition of done.
Once the project is created, it opens into the main conversation, where the coordinator greets you and suggests next steps.
From a problem report to eight parallel threads
In the example, the request to the coordinator described the symptoms plainly: Core Web Vitals for the marketing site had been dropping for a month, p75 LCP on mobile had reached 4.1 seconds, CLS was 0.28 and users kept saying navigation felt slow. The prompt ended with “Investigate and fix.”
Claude reviewed both codebases, traced the bottlenecks and returned a prioritized plan:
- Client-side navigation
- Unoptimized images
- Caching page content
- Lazy-loading scripts
- Preloading web fonts
- Splitting the JavaScript bundle
- Reserving space for a banner
- Compressing assets
After the developer approved the plan, Claude started eight worker threads at once, one per fix. Each appears as a card with a running timer and its Git branch name.
Steering the threads
Threads can run entirely on their own, but you keep full visibility and control.
- Watch: click any thread card to see Claude’s live terminal output, the code it is changing and the step it is on.
- Steer: type instructions straight into a thread to adjust its priorities, or stop it immediately. In the example, the image-optimization thread was told to keep the hero image as a priority image.
- Unblock: a Threads sidebar shows which workers are running and which are blocked waiting for your input.
When a thread finishes, it opens a pull request on GitHub automatically or asks you first before publishing. In the example, the fixes included adding explicit width and height to 34 image tags. Threads then keep watching their own pull requests: they monitor continuous integration (CI) checks, the automated builds and tests that run on each change, fix failing tests and respond to reviewer feedback. The coordinator’s feed summarizes the status of every pull request, and you can merge approved changes directly from the conversation.
Here is where the example project ended up:
| Metric | Before | Goal | After |
|---|---|---|---|
| Mobile p75 LCP | 4.1 s | under 2.5 s | 2.2 s |
| Desktop p75 LCP | not stated | under 2.5 s | 1.4 s |
| CLS | 0.28 | under 0.1 | 0.08 |
▲ Performance metrics after the fixes
The Library: shared artifacts for every thread
Projects includes a Library tab for artifacts, the documents and other outputs Claude creates. In the example, Claude was asked to write a post-mortem of the resolved issues with before-and-after numbers. It produced a report with bar charts comparing mobile LCP, desktop LCP and CLS.
The Library works as the project’s persistent shared folder. Besides generated documents, it can hold uploaded mockups and technical specs. Every current and future thread can read and update what is there, so later tasks start with the context earlier tasks built up.
Connectors and routines for ongoing checks
Connectors link a project to outside development and monitoring tools. In Environment settings, enabling the Sentry connector lets Claude query real user telemetry and error logs directly.
Routines add scheduled, recurring work. The example set one up with a single instruction: every day at 5 p.m., pull the marketing site’s Core Web Vitals and error logs from Sentry, and if anything regressed, investigate and fix it. When the daily check finds a regression, Claude starts a dedicated investigation thread and opens a draft pull request with a fix ready for review. That turns after-the-fact debugging into a proactive check that runs in the background.
Keeping usage and cost under control
Each thread is a full Claude Code session, so running several in parallel uses up plan limits much faster than a single conversation. The Claude Code team’s recommendations come down to a few settings:
| Setting | Recommendation | Why |
|---|---|---|
| Coordinator effort | Low | Its job is routing and planning, not deep reasoning |
| Default thread model | Sonnet 5.5 | Enough for well-scoped tasks |
| Hard threads | Opus 5.5 | Reserve the larger model for complex work |
| Behavior rules | Cap concurrent threads; require an outline before coding | Prevents a burst of threads you did not plan for |
Model and effort level are set separately for the coordinator and for threads in General settings, and Haiku 4.5 is also available as a lighter option. Raising the coordinator above Low rarely seems to improve coordination in a meaningful way and mainly adds token cost. Rules such as a thread cap go into the coordinator conversation; the example capped concurrency at five threads.
For standards that should apply everywhere, use project memory. A MEMORY.md file in settings holds coding standards and preferences that every current and future thread inherits. The field accepts up to 16,000 characters.
Getting started
Projects appears to pay off most on goals that cross repositories and take many steps, not on quick one-prompt tasks. A sensible first run looks like this:
- Pick one goal that spans several repositories or sessions, and write it as measurable targets.
- Connect every relevant repository, then review the coordinator’s plan before approving it.
- Set coordinator effort to Low, make Sonnet 5.5 the default thread model and cap the number of concurrent threads.
- Put your team’s coding standards in MEMORY.md so every thread follows them.
- If you run the same check repeatedly, automate it with a connector and a routine.
Projects is still in beta, so features and screens may change. Since every extra thread draws down your usage faster, start with a small, well-defined goal before handing it larger ones.