Claude Code Projects: Coordinator Agents at 200 Threads/Day

Claude Code Projects relaunched September 17, 2026 as a fleet manager for coding agents. One coordinator conversation splits an engineering goal across parallel cloud sessions called threads. Each thread runs on its own branch with its own repo copy, opens pull requests, auto-fixes CI failures, and shares project memory that persists across days. Beta is limited to select Pro and Max users on web and desktop, capped at 200 new threads per day.

The essentials for leads in a hurry:

• Each thread is a full Claude Code cloud session. Four parallel threads burn roughly four times the tokens of one session.
• Project instructions hold up to 16,000 characters plus a shared MEMORY.md file pushed to every thread.
• Threads open PRs, watch CI, and push fixes on their own. Overlaps resolve as normal merge conflicts.

I tested Projects on a three-repo API retirement at SaaSNext this week. The goal I gave the coordinator was plain English: retire the v1 billing endpoint across API, webhooks, and docs, with tests green before any merge. It spun up three threads, one per repo. Two finished clean. The third rewrote a shared auth helper and collided with thread one. Git did exactly what git does. I spent 40 minutes resolving a conflict the coordinator should have prevented.

From folders to orchestrators

Old Projects were containers. You stored files, instructions, and one chat. New Projects are orchestrators. You brief the coordinator the way you would brief a chief of staff, and it decides what to answer directly versus what to hand to threads. Threads can further split work with subagents, loops, and workflows when an assignment turns out larger than expected.

The shared memory layer is the real change. Every thread reads from and writes back to the same project memory. A thread learns the billing service needs sign-off from a specific reviewer, and every later thread sees that fact. The library collects user files plus Claude-produced artifacts, so new threads pull design specs without you re-uploading them.

I track coordinator patterns like this in my LangGraph on Temporal durable loops guide, and the cost math behind parallel sessions in Price per Task vs Price per Token.

Default model on new projects is Opus at high effort for threads and low effort for the coordinator. You can tune model plus effort per side, which is your main throttle. Anthropic exposes a per-project Usage tab. Watch it after every multi-thread run before you scale further.

Production war story 1: six threads, one invoice shock

My first real run used six threads to parallelize input validation across five endpoints plus docs. Each thread was fast. Each PR looked reasonable. Total wall time was 52 minutes against roughly 4 hours sequential. Then I opened the Usage tab.

We burned through 78% of the day's allocation in that single session. Each thread held its own context window, its own API calls, its own retries. One thread hit a usage limit mid-run, paused, and resumed on its own when capacity returned, which delayed its PR by 90 minutes. The coordinator never warned me. It just kept spawning.

Fix was operational, not clever. I capped parallel threads at three, set threads to Sonnet for mechanical edits and Opus only for the auth path, and added a rule: no new thread while two are waiting on CI. Token spend per merged PR dropped 41% the next day. Parallelism without a budget is just a faster way to hit the ceiling.

Architecture: coordinator, threads, memory

Project goal
  -> Coordinator (low effort, answers quick questions inline)
  -> Thread per workstream (own branch, own repo clone)
     -> Subagents and loops inside heavy threads
     -> Open PR -> watch CI -> auto-fix -> report back
  -> Shared MEMORY.md + library (decisions persist)
  -> Human review (merge in dependency order)

Permission rules, hooks, and environment variables apply only from the directory the thread starts in. Single-repo projects respect them. Multi-repo projects do not fully inherit them. MCP tools connected to your claude.ai account are thread-only. The coordinator itself cannot call connectors. I learned this when a thread could reach our tracker while the coordinator insisted it could not.

For long jobs I mirror the checkpoint discipline from Kafka, Temporal and LangGraph fraud agents. Every thread writes a DONE note with files touched and test status to MEMORY.md before opening its PR. The next thread reads those notes instead of re-discovering the same context.

Step 1: Project instructions that prevent collisions

You get 16,000 characters. Spend them on boundaries, not prose. Here is the template I now paste into every project.

PROJECT_INSTRUCTIONS.md

# Project: v1 billing retirement

## Goal
Retire POST /v1/billing/charge across api, webhooks, docs.
Tests must pass per repo before merge. Merge order: api, webhooks, docs.

## Thread rules
- One thread per repo. Never touch files outside your repo.
- Shared file: libs/auth/helper.ts is OWNED by api thread. Others read only.
- Max 3 parallel threads. No new thread while 2 wait on CI.
- Open PR per thread. Title format: chore(api): retire v1 billing charge.

## Memory writes
- Append to MEMORY.md: date, thread, files touched, test result.
- Record decisions like release date moves and reviewer requirements.

## Stop conditions
- If CI fails twice on same check, stop and report. Do not loop.
- If overlap detected, api thread wins. Others rebase.

requirements note: this beta runs on web and desktop only, no CLI. Users with existing projects on web or desktop are excluded from the first wave. Team and Enterprise come later, then Cowork and plain Claude chats. Local execution behind your own network ships soon but has no firm date. Cloud-only today means repos you cannot mirror to Anthropic cloud stay out.

Step 2: Coordinator script and thread budget guard

I run a small guard outside Claude that watches thread count and spend. It is not fancy, but it stopped the second invoice shock.

coordinator_guard.py

import os, time, json
from dataclasses import dataclass

MAX_PARALLEL = 3
MAX_THREADS_PER_DAY = 180  # stay under the 200 cap with margin
STOP_AFTER_CI_FAILURES = 2

@dataclass
class Thread:
    name: str
    repo: str
    status: str  # running, ci_wait, done, failed
    ci_failures: int = 0

def can_spawn(active: list[Thread], spawned_today: int) -> bool:
    running = [t for t in active if t.status in ("running", "ci_wait")]
    if spawned_today >= MAX_THREADS_PER_DAY:
        return False
    if len(running) >= MAX_PARALLEL:
        return False
    return True

def should_stop(t: Thread) -> bool:
    return t.ci_failures >= STOP_AFTER_CI_FAILURES

# Poll your Usage tab export every 60s and page when spend per PR exceeds baseline.
# I page at 1.8x the single-session cost of the same task.

Run contained tasks first. My smoke test is always the same: add input validation to five endpoints and open one PR per endpoint. It tells me within an hour how the coordinator splits work, whether PRs are reviewable, and what the real token cost per merge looks like.

Production war story 2: the auth helper collision

Thread one owned the API repo and rewrote the shared auth helper to drop v1 token support. Thread two owned webhooks and, reading a stale library copy, added a v1 compatibility shim into the same helper from its own branch. Both PRs passed CI in isolation. Merged in the wrong order, they broke every webhook test.

Root cause was mine. The library had two copies of the helper spec, and the project instructions did not name an owner. Fix was the ownership line you see above: one file, one owner thread, everyone else read-only. I also switched merge order enforcement to branch protections plus a required check that greps for v1 strings. Second run merged clean in dependency order.

Idle threads cost money too. A thread waiting on CI wakes when a check fails or a review comment lands, then consumes tokens again. I now close threads the hour their PR merges instead of leaving them warm. Small habit, measurable savings.

Benchmarks and limits worth memorizing

Coordinator quality decides everything. A coordinator that splits badly produces six conflicting PRs faster than one engineer produces one good PR. Research on harness quality keeps saying the same thing: orchestration matters as much as the model. Anthropic is now shipping the harness, and the beta will show whether the coordinator decomposes well or just parallelizes mistakes.

I pair this workflow with hardened artifact storage from Hardened Postgres MCP at 38ms so every thread note and PR link lands in a table with row-level security instead of scattered chat logs.

When NOT to use Projects

Skip it when code cannot leave your network, when CI is flaky enough that auto-fix loops will spin, or when your review pipeline cannot absorb three concurrent agent PRs. It is also the wrong tool for single-file edits where one session is cheaper and clearer. Parallel fleets shine on large refactors and multi-repo retirements with solid branch protections.

Do not use it as a background daemon yet. Idle wake-ups on CI events can surprise you on spend, and the Usage tab is the only visibility you get. Until spend-per-thread alerting improves, keep a human in the merge path and a hard cap on parallel threads.

Verification checklist before you scale

1. Confirm your Pro or Max account shows the redesign. CLI-only teams wait.
2. Start single-repo, verify permissions and env scoping, then go multi-repo.
3. Seed instructions plus MEMORY.md on day one with owners and merge order.
4. Review Usage after each run. Compute cost per merged PR, not per session.
5. Enforce CI green plus required reviewers before any agent PR merges.

My verdict after two weeks: genuine force multiplier for bounded refactors, expensive toy for vague goals. Brief it like a chief of staff with crisp boundaries and it returns clean PRs. Brief it loosely and it returns six confident drafts of the wrong change.

By Deepak Bagada, Founder and Editor-in-Chief at Daily AI World. I run multi-agent coding fleets at SaaSNext and only recommend patterns that survive real branch protections. More field notes at deepakbagada.in.