Anthropic Adds Local Execution to Claude Code Projects

Anthropic added local execution to the Projects feature in Claude Code on September 23 (US time). Its official developer account, ClaudeDevs, posted on X that "we've just added local support to Projects in Claude Code, so threads can now run on your own machine." Projects launched in beta on September 17 and until now ran every task in cloud sessions only, so six days later the feature's reach has expanded to the user's own device.

A project is a single conversation that directs many pieces of work. According to Anthropic's September 17 announcement, you describe what needs doing and Claude splits the work into threads, runs them as parallel cloud sessions, passes context between them, and keeps going after you step away. That launch post drew 2.37 million views and 11,404 likes.

Under the hood there are two layers. According to the official documentation, Claude in the project conversation acts as the coordinator and decides what becomes a thread. Each thread is a cloud session with its own context window that takes on one piece of work on its own branch, opens a pull request when needed, and reports back. The coordinator sees what threads report, not every step they take. When two threads touch the same code, the overlap is handled as an ordinary merge conflict, just like any other pull request. In its blog post, the company explained that when you "brief Claude in the project the way you'd brief a chief of staff," it routes the work to new or existing threads.

Local support was the announced next step. In the launch blog post, Anthropic wrote that "threads run in the cloud today; running on your machine alongside your local tools and code and behind your network is coming very soon." Cloud threads can only work with GitHub repositories and uploaded files, so jobs that need resources reachable only from the user's computer, such as a local database, a device emulator, or an API behind a VPN, were the cases where the documentation recommended a local session instead of a project.

Users had been asking for it. The day after launch, one X user (@tropoFarmer) replied to the launch post that adding local folders on Windows did nothing and that there was no way to add context other than repositories after creating a project, and asked, "how might this work for local workflows?"

The official documentation METAL checked on the afternoon of September 24 still describes a cloud-only product. Its limitations section says a local session cannot be part of a project, and it states that projects are not available in the terminal CLI, Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry. The ClaudeDevs post is a single sentence, so it has not been disclosed which plans and operating systems support local threads or how local threads connect to the coordinator. At that time, the post had 316,576 views.

Access terms are unchanged from launch. According to Anthropic, the beta opened first to select Pro and Max subscribers who use cloud sessions in Claude Code and have no existing projects on the web or desktop, and the company said it would expand to more users on those plans before bringing it to all of Claude and to Team and Enterprise plans. Existing Pro and Max projects keep working as before and will be upgraded as the rollout extends to chat and Cowork. METAL previously reported that Anthropic merged Cowork and chat into one Claude on September 16; the Projects redesign arrived the next day.

The first thing engineers should look at is cost. According to the documentation, a new project runs threads on Opus at high effort and the coordinator conversation on Opus at low effort, and because each thread is a full session, a project uses plan limits faster than a single session. The enforced cap is 200 new threads per day across all projects. An idle thread watching a pull request wakes up and draws on limits again when CI fails or a review comment arrives, and on Pro and Max, sending follow-up work to a thread idle for longer than the one-hour cache lifetime makes that thread re-read its entire conversation.

Context set once reaches every thread. Project instructions of up to 16,000 characters are sent to every new thread and to the coordinator, and project memory is stored as files under a MEMORY.md index that every thread reads when it starts. The Overview pane sorts threads into six groups: ready for review, waiting on you, working, landing, idle, and resolved. Threads with no activity for a week are marked resolved automatically.

The 26-second launch demo video METAL reviewed shows this flow directly. When the user types, in one message, that p99 latency on the checkout path doubled after a deploy and should be found and fixed, that Friday's release notes need drafting, and that stripe-node should be bumped to v15, Claude spins up three threads. When the user adds that the release moved to Monday, the coordinator forwards that message only to the release-notes thread, and when the stripe-node thread gets blocked on a Node 18 issue, it moves to the waiting-on-you group for the user's decision.

From a TPM's perspective, local support changes the boundary of what a project can take on. As a cloud-only product, Projects fit work that begins and ends with code on GitHub and uploaded files, while work that needed internal-network services or local tools left developers coordinating several sessions by hand. Once threads can run on a developer's computer, a single coordinator can split work across both cloud and local tasks. The next question for teams is the part the documentation does not yet explain: how far local threads can use the permissions and network of the user's computer.