What Claude Code Projects Is: How Claude Hands Out Threads, Who Can Use It, the GitHub Requirement and the Token Cost

On September 17, 2026, Anthropic announced that it had rebuilt Projects in Claude Code. The name itself is not new. It is the same word claude.ai chat has used for the box that keeps conversations and reference files together. The new Projects keeps that name and replaces everything behind it. The subtitle of the official blog post is the whole answer in itself: "from folder to conversation".

In one sentence, what changed is that the job of handing out work moved from you to Claude. You drop a request into the conversation, Claude splits it into "threads", the threads run in parallel in the cloud, and each one opens a pull request and reports back when it finishes. Closing your laptop does not stop them.

Before you jump in, though, three things are worth checking: the accounts that can use it are still limited, GitHub is a requirement in practice, and the rate at which it eats your usage limit is nothing like a single session. This article goes back to the primary sources, the Claude Code documentation and the official blog, to work through whether you can use it and what happens once you do.

1. Not a folder any more, but a single conversation

The new Projects is built from two parts: the project conversation, where Claude plays coordinator, and the threads that conversation starts.

The conversation is one long-running session. It reads what you send, answers on the spot when an answer is all that is needed, and carves out anything that amounts to work into a thread. It is not watching what happens inside those threads. It sees only what they report back.

Threads are where the work happens. Each is an independent cloud session with its own context window. It works on its own branch, opens a pull request when that is called for, and reports to the conversation when it is done. The documentation describes thread states as lining up in a list called Overview, like this.

The point worth holding on to here is that working in parallel is not the new part. Claude Code already had subagents, agent view, agent teams and dynamic workflows. What Projects adds is not parallelism but two other things: you no longer do the routing and the tracking yourself, and the work does not vanish when you close your machine. The documentation says as much, stating plainly that being able to run things in parallel is not what Projects is for.

2. Same name, but not the old Projects

What makes this confusing is that claude.ai chat has "Projects" too. That one is a container for conversations and files, with no threads and no coordinator. The identical name invites the mix-up, but the documentation treats them as separate features.

3. Who gets it — how to tell whether it has reached you

As of September 19, 2026 it is a public beta going out in stages. The conditions are written down in some detail, so here they are, close to verbatim.

The second one is the easiest to miss. The more old projects you have built up on the chat side, the later new Projects reaches you. The official blog says existing projects keep working for the time being and get upgraded as the rollout widens. In other words, it is not the heavy users who go first: it is the accounts with a clean slate.

If it is not in your sidebar, your turn has not come. In that case you can put your name on the waitlist. Looking in the right place matters more than it sounds, too: it appears on the Code side, in the sidebar at claude.ai/code or in the Code tab of the desktop app. However long you search the chat sidebar, what you find there is the old Projects.

4. It needs GitHub, and this is where people drop out

This is the constraint that bites hardest in practice. The only code a thread can touch is code on github.com, and the Claude GitHub App has to be installed on that repository. The documentation lists the conditions like this.

• The code lives on github.com. GitHub Enterprise Server, GitLab and Bitbucket are out
• The connected GitHub account has push access to that repository
• The Claude GitHub App is installed on that repository. A token you added with /web-setup works for other cloud sessions but is not enough for project threads
• On an organization's repositories, only an organization owner can complete the installation (anyone else gets an approval request instead)

Which means an individual developer working from a bare repository on their own git server or on shared hosting is out of scope as things stand. The same goes for an API behind a corporate VPN, a database on your laptop, a device emulator or a production server you reach over SSH: threads live outside your machine, so they cannot touch any of it.

Does that leave nothing at all for people who do not use GitHub? Not quite. A project can be created with no repository. Uploading a folder of contracts or an export of support tickets, giving a thread a job like "list the ten integration mistakes that come up most often in here" and picking up the result on the Library tab is a use the documentation explicitly anticipates. Files you upload are readable from a thread under /mnt/project-files.

If the work is code and it needs your own environment, the thing to reach for is running local sessions side by side in agent view instead. That runs on your own machine, so your VPN, your local DB and your SSH all still work.

5. What a thread starts with

A thread does not start from nothing every time. It boots with the context the project gives it, and there are four things it carries.

• The project's repositories and files — every registered repository is cloned each time, whether or not the task touches it
• Project instructions — a shared brief that reaches every thread. The cap is 16,000 characters
• Project memory — notes Claude writes for itself. It reads the MEMORY.md index at startup and opens individual files when it needs them
• The cloud environment — which network destinations are allowed, environment variables, API credentials, and the tools installed in advance

The part of that baggage most likely to cause an accident is this: repository configuration files are treated differently depending on whether the project has one repository or several. Tidying up the documentation's table gives the following.

The reason is simple: permissions, hooks and environment variables are only ever read from the .claude/settings.json in the directory the thread started in. With more than one repository, the thread starts one level above the clones, so no repository's settings sit anywhere that gets read. Adding a single extra repository quietly switches your hooks off, and nothing tells you. For multi-repository projects the documented advice is to put shared rules in the project instructions and environment variables in the cloud environment.

On MCP, while we are here: the MCP servers a thread can use are the connectors on your claude.ai account. An MCP server installed only on your machine never reaches it. And the project conversation itself has no connectors at all, so work that needs one has to go to a thread rather than be asked in the conversation.

6. How much more it costs in tokens

This is the question most people have before switching it on. The documentation is blunt about it: a project draws on your limits faster than a single session does, and on Pro in particular you should expect to hit your limit sooner on the days you run one. The increase comes from several things stacking up.

④ deserves particular care. When a project thread opens a pull request, it watches that PR with auto-fix on by default. Even if you have turned auto-fix off for your other cloud sessions, project threads are handled separately. It will fix failing CI, respond to review comments and report back once everything passes, and in exchange it keeps eating into your usage for as long as you leave it there. To stop it, tell that thread to stop monitoring the PR.

So how much more is it? No multiplier has been published for Projects itself, but for agent teams, which work on the same idea of splitting one task across several sessions, the documentation puts the figure at roughly seven times a standard session when the teammates run in plan mode. Running things in parallel is a way to buy speed, not a way to save, and that much they have in common.

It is also worth knowing where the brakes are and how well they hold.

• There is no cap on how many threads run at once. You can say "keep it to two", but the documentation is explicit that this is an instruction Claude tries to follow, not a setting that is enforced. The only hard limit is 200 threads a day (across all projects)
• A thread that hits your usage limit waits on its own and resumes automatically once the limit resets. Leave it alone and it will start spending the next window without asking (to stop it, hit Stop on the thread or pause the project). The exception is a thread started by a routine, which errors out instead of waiting
• The cloud virtual machines themselves cost nothing extra. Tokens are the only thing that goes up
• An idle project — no running threads, no PRs being watched, no new messages — uses no allowance at all

7. Choosing between the five ways to work in parallel

Claude Code now has five ways to get work done in parallel. Projects is one of them, and what sets it apart from the rest is who hands out the work and where it runs. Rearranging the documentation's comparison around how you would actually choose gives this.

Drawing the line for your own situation comes down to roughly two questions. Does the work need your own environment (a local DB, a VPN, SSH)? If it does, Projects is not an option. Will the work be finished today? If it will, moving it to the cloud buys you little and agent view is enough. For the difference between subagents and agent teams, a separate article compares the two in detail.

8. What to do before you send the first batch

The documentation lists four things to do "before your first batch", and every one of them is expensive to fix later.

1. Write the project instructions — which branch to cut from, what to run before calling something done, what needs your approval first. The official example tells a thread to name exactly what it cannot reach in its first message and stop there, rather than substituting, mocking or guessing.
2. Send exactly one real job, then open it and read it — check how it reports and what it actually left on the branch
3. Revisit the model and the effort level — leaving the default Opus at high is the fastest way to burn through your limit
4. Say "propose before you start" and "keep it to a few threads at a time" — drop those once a few rounds come back the way you expect

One more, less glamorous but worth knowing. A thread's sandbox pauses between turns and resumes for the next one. If it cannot resume, the work restarts from a fresh clone, which means uncommitted changes can be lost. On longer jobs the documented recommendation is to tell the thread to commit and push as it goes.

Summary

The new Projects is not "a feature that lets you run things in parallel" but "a feature that takes the hassle of running things in parallel off your hands". The handing out, the chasing and the re-explaining of the same context every time all disappear. If you have work that runs and runs, it lives on github.com, and you are on Pro or Max, the odds of a good fit are high.

It is a poor fit, on the other hand, for work that needs your own environment, for your own git server, and for one-off jobs that finish today. And the thing that holds in every case is that parallelism buys speed by spending tokens. The default is Opus at high, there is no enforced cap on how many threads run at once, and threads watching a PR wake themselves up. Run a project for a day without knowing those three and the drop in your allowance will surprise you. Lower the settings first, keep the thread count small, and get a feel for it over a single round trip before widening out. That is the safest way in.

If you want to turn research from a project into a proposal or procedure that you can refer back to, see our guide to Claude Docs. Use Projects for ongoing work and Docs for creating and editing documents, according to what you need to accomplish.

FAQ

Q. What happens to the projects I already have in chat?

A. They keep working as they do for the time being. The official blog says existing Pro and Max projects remain usable, and that they will be upgraded as the rollout widens to chat and Cowork. Note, though, that the new Projects is going out first to accounts with no existing projects, so the more you have built up, the later your turn comes.

Q. Can I use it from Claude Code in the terminal?

A. No. The three places it works are claude.ai/code, the Code tab in the desktop app and the mobile app. Access through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry is out of scope as well. The CLI's claude project command, incidentally, is a different feature that happens to share the name.

Q. I don't use GitHub. What are my options?

A. For actually running code there are two, for now. Put the repository on github.com and install the Claude GitHub App, or use agent view, which runs on your own machine. That said, a project with no repository can be created without GitHub at all: upload your material, have threads research or draft from it, and collect the results on the Library tab.

Q. Is it realistic on the Pro plan?

A. Yes, but turn the settings down before you start. The documentation itself warns that on Pro in particular you should expect to hit your limit sooner on the days you run a project. A new project defaults to threads on Opus at high, so lower that first, keep the number of threads running at once small, and widen out while watching what you actually spend under the project's Usage settings.