Anthropic opens Claude Code Projects to every waitlisted Pro and Max user

What did ClaudeDevs announce on 9 October?

The dated object for this update is a short thread from @ClaudeDevs on 9 October 2026, mirrored in secondary roundups such as VibeLeaderboard. The first post says every Pro and Max user from the Claude Code Projects waitlist had just been admitted and points to a four-minute walkthrough. A follow-up defines a project as “an ongoing conversation where Claude coordinates the work for you, running each task as its own thread in parallel,” and links the docs. A third post keeps the product in beta, invites people who have not signed up to join the waitlist, and says more Pro and Max users will be let in as capacity allows.

That wording matters. The admission claim comes from ClaudeDevs, not from a dated newsroom post on anthropic.com/news. The Projects redesigned article still frames the redesign as a beta that began for select Pro and Max subscribers who use cloud sessions and do not already have projects on the web or desktop, with a wider rollout “over the coming week” and Team/Enterprise later. The docs we fetched on 11 October still say Projects are in public beta on Pro and Max, rolling out gradually, and that if Projects is missing from the sidebar you should join the waitlist at claude.com/form/projects.

So the practical reading is: waitlisted Pro and Max applicants were told they are in; the product remains a capacity-gated beta; people who never joined the waitlist may still need the form; Team and Enterprise are out of scope for this admission.

How does a project actually run work?

The Claude Code documentation page “Let Claude coordinate ongoing work with Projects” is the operational primary source. A project is one long-running coordinator conversation. You paste bugs, stack traces, migration goals, or document questions; Claude starts a thread per task or routes follow-ups to an existing thread. Each thread is usually a cloud Claude Code session working on its own branch and copy of the repository, and it can open a pull request, run tests, and report back. Threads run in parallel. Cloud threads keep going after you close the laptop; a thread on your machine runs only while that computer is awake with Remote Control on.

Standing context is split on purpose. Project instructions—up to 16,000 characters—are injected into each new thread and into the coordinator. Project memory is a set of files indexed by MEMORY.md; every cloud thread reads that index at start and opens other memory files as needed. Repositories, uploaded files, connectors on your claude.ai account, and a cloud environment (network allowlist, secrets, installed tools) also travel with each cloud thread. The Overview pane groups threads into states such as ready for review, waiting on you, and working, and it surfaces Library, Pull requests, and Routines tabs.

The docs are explicit about what Projects are not. They are available at claude.ai/code, in the desktop app’s Code tab, and in the Claude mobile apps—not in the terminal CLI, the VS Code extension, the JetBrains plugin, Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry. You cannot drag a local session you started yourself into a project; the project reaches your machine only by asking a thread to run there through Remote Control. GitHub.com with the Claude GitHub App and push access is required for code work; a `/web-setup` token that is enough for ordinary cloud sessions is not enough for project threads.

• Coordinator conversation: routes work, tracks threads, does not see every tool step inside them
• Cloud thread: own context window, own branch, can open a PR and fix CI
• Local thread via Remote Control: uses the machine’s tools and settings; inherits instructions but not memory files
• Hard cap called out in docs: 200 new threads per day across your projects

Who can use it, and what are the limits?

Access, on the documentation we opened, is Pro or Max with Projects visible in the sidebar. Team and Enterprise are not supported yet. The waitlist form remains the documented path when the sidebar entry is missing. ClaudeDevs’ 9 October posts admit the existing waitlist batch and still point newcomers at that form, so “everyone on the waitlist” is not the same sentence as “every Pro and Max subscriber worldwide.”

Cost is not a separate Projects SKU. Usage counts against the same plan limits as other Claude Code sessions, and the docs warn that a project burns those limits faster—especially on Pro. A thread that hits the limit waits and continues when the window resets. Extra spend requires usage credits you enable yourself; a thread cannot turn credits on for you. For teams comparing agent sandboxes and coding hosts, that plan-limit coupling is as important as the feature list—see also our notes on GitHub Copilot local sandboxing GA and the AX Practitioner Playbook for how other vendors talk about agent evaluation and containment.

The docs also name an enforced product limit: 200 new threads per day across your projects. A soft preference such as “run at most two threads at once” is not a hard cap; the 200-new-threads figure is. Folder uploads into a project are capped in the docs at a copy of the first 100 files up to 200 MB, excluding files over 30 MB, hidden files, and node_modules. Those are documentation numbers, not measurements we reproduced.

What should teams try first?

The documentation’s own fit list is concrete: one goal across many repositories (a lint upgrade with a thread per repo), a service you keep feeding with bugs and review comments, a build or migration larger than one session, or a non-code corpus you keep re-querying. Poor fits are also named: a single flaky test that fits one session; work that always needs a local database or VPN; a pure scheduled report with no conversation; and Slack-channel group steering, which the docs redirect to Claude Tag.

If you already run Anthropic’s hosted agent products, keep the product lines straight. Managed Agents dynamic workflows are an API-side orchestration story with their own caps. Claude Code Projects are a Pro/Max coding surface centered on git branches and pull requests. Confusing the two will produce the wrong security review and the wrong cost model.

Before treating Projects as a team default, confirm three things on a real repository: the Claude GitHub App is installed with push access; the cloud environment can reach the package registries and secrets you need; and your Pro or Max usage window can absorb several parallel cloud sessions without stranding overnight work. The docs say a limit-blocked thread resumes on its own when the window resets—plan for that resume, or stop the thread deliberately.

1. Confirm Projects appears for a Pro/Max account that was on the waitlist (or join the form if it does not).
2. Install the Claude GitHub App on a github.com repo with push access; do not rely on a /web-setup token alone.
3. Write project instructions once (branch policy, review rules, “do not open a PR until…”).
4. Run one multi-repo or multi-bug pilot and watch Overview for waiting-on-you states before scaling thread count.

What remains unverified?

We did not create a Claude account project, join the waitlist, measure how many waitlisted accounts actually received the sidebar entry on 9 October, or time how fast Pro limits drain under parallel threads. ClaudeDevs’ posts do not publish a capacity figure or a completion date for Team and Enterprise. The docs’ “rolling out gradually” language still applies even after the waitlist admission claim.

Vendor claims about coordinator quality, merge-conflict handling when two threads touch the same files, and how often auto mode needs human approval are not independently scored here. Treat the walkthrough video linked from ClaudeDevs as a product tour, not as a benchmark.