Claude Code Projects now talks back: 7 facts about the proactive coordinator, /btw and /fork

On November 13 Anthropic's developer account @ClaudeDevs announced "big updates" to Projects in Claude Code. Projects is the mode where one coordinator conversation splits your work across parallel threads, and per Anthropic's docs each thread is a full Claude Code cloud session with its own copy of the repository and its own Git branch. The update changes who does the talking: the coordinator now answers your questions in the project chat and posts status updates on running threads without being asked.

I have not run it yet. The beta is staged and narrow, and my accounts are not in it. What follows is a close read of the announcement thread, its follow-up posts and the docs coverage, because several details change how you would brief a project before you ever get access. The same week the CLI itself shipped plugin version-range pinning, so the surface is moving fast.

What shipped on November 13

Five follow-up posts from @ClaudeDevs listed the additions: the proactive coordinator, /btw and /fork now working inside projects, reminders on threads, read-only sharing links for individual threads, and a recents row with artifact thumbnails in the threads panel. Project settings and local folder access got simpler too. It is a public beta on the paid individual plans (Pro and Max in the announcement, Ultra also listed in the docs), rolling out in stages with a waitlist. Team and Enterprise come later.

The coordinator answers in chat, and it reports summaries

Fact 1. The coordinator is now "much more proactive", in Anthropic's words. You can ask the project chat which threads are still running, which pull requests need review and what is blocked, and it reports back. It also posts updates as threads progress instead of waiting to be polled. If you have been babysitting five terminal windows to know what finished, that is the pain this aims at.

Fact 2. The coordinator reports what its threads tell it. It does not see every internal step of every thread, so status is a summary the threads produce. When a thread goes wrong, the project chat will not show you the failing command or the tool call that returned garbage. You open that thread and read its transcript. The coordinator reduces how often you poll, not how carefully you debug.

/btw becomes a worker, /fork becomes a branch

Fact 3. /btw has existed in terminal Claude Code for a while. There it asks a side question and shows the answer in an overlay, and while answering it cannot read files or run commands. Inside Projects it does something bigger: it opens a separate thread that can do real work, and the thread you were in stays on topic.

Fact 4. In the terminal, /fork copies your whole current session into a background session alongside the original. In Projects it starts a new thread from the one you are in, meant for trying a different approach on the same task. The first thread keeps going. Two attempts at the fix from one brief, and you keep whichever pull request turns out better.

Anthropic's demo runs the exact flow worth internalizing:

# thread: "Upgrade date library"
/btw why is the orders page slow?

# a new thread finds it: the order list looks up each customer
# separately, so a page of 50 orders runs 51 queries (1 list + 50
# customer fetches). It merges them into one query.

# back in that new thread:
/fork try caching instead

# a second thread branches off and adds a short-lived cache for
# customer lookups. Both fixes run side by side, and the
# date-library thread never stops.

That is a context-hygiene primitive. The old failure mode is stuffing the side question into the current session and watching the agent lose the plot.

Merge conflicts are the only sync point

Fact 5. Each thread works its own branch of its own repo copy. When two threads touch the same code, the overlap surfaces as an ordinary Git merge conflict in a pull request. There is no resolution layer on top. I find that honest architecture, and it makes your briefing the real concurrency control: split work by repo or module so branches do not collide, and treat any conflict as a planning bug, not a Git problem.

Reminders and read-only shares, and one boundary worth keeping

Fact 6. You can set a reminder on any thread, or ask Claude to set one. The thread moves out of the way until the set time, then comes back, and the coordinator raises it in the project chat. For work blocked on a review or an external dependency, the thread stops occupying your attention instead of sitting open as a tab you keep re-reading.

Fact 7. Any individual thread can be shared as a read-only link to anyone signed in to Claude, from the thread's Share menu. Threads that had access to your computer cannot be shared at all. That boundary is the right call. Transcripts of local sessions can carry file paths, command history and tokens, and we just spent a whole piece on how much sensitive material sits in plain-text agent traces. A share button on those transcripts would be a short path to the same leak.

Five threads is five sessions

A new project runs Opus everywhere: worker threads at high effort, the coordinator conversation at low effort, per the docs. Threads draw on the same plan limits as any other Claude Code session, so five parallel workers burn your plan roughly five times faster than one session, and a thread that hits its ceiling pauses and resumes on its own rather than failing loudly. Coverage of the rollout also cites a cap of 200 new threads per day across all projects, though that number comes from AlphaSignal's reporting, not Anthropic's post. Set the model and effort per role before you hand over a big goal, and check the project usage view after the first run.

Four rules before you fan out, and what is still missing

1. Start with one bounded goal. Migrate one endpoint or profile one page, not the platform.
2. Set the dials before starting. You pick the model and effort for the coordinator and the workers separately, plus how often the coordinator checks in. A heavy model on the coordinator plus five workers on the same model is the most expensive default available.
3. Brief so branches do not collide. One thread per repo or per module, and any merge conflict means the plan was wrong.
4. Read every pull request. A coordinator assembling PRs from five threads is assembling drafts. More threads means more output, not more review capacity.

What is missing: Projects runs on the web, desktop and mobile apps, not yet in the terminal CLI, the VS Code extension or the JetBrains plugin. Local threads, the version that runs on your own machine, are "coming very soon" per the coverage, which is the piece that matters if your code cannot leave your network.

The competitive frame is compressing. Cursor shipped its multiplayer Projects three days before this, with shared rules files and task boards rather than a coordinator chat, and I wrote up what that means for shared agent context. Both products are converging on the same shape: one shared context, many workers, a human at the merge. The differentiator is not the fan-out, everyone can fan out. It is who keeps the context coherent while it happens.