Claude Code Projects Opens: Building a Mini Project Coordinator in TypeScript

Anthropic Opens Claude Code Projects: Build a Mini Coordinator in TypeScript

Anthropic's Claude Code Projects is now officially open to Pro and Max users, and the core idea is clear — a project is no longer a folder of chat logs, but a coordinator session responsible for defining goals, distributing work to parallel threads, reviewing results, and assembling the final deliverable. The official wording puts it plainly: "Projects have worker threads, and a coordinator that directs them."

This article doesn't recap the news. Instead, it rolls up its sleeves and builds a miniature version in TypeScript to understand what problems a coordinator actually needs to solve.

Parallelism Is Easy, Coordination Is the Product

Most multi-agent demos open the same way: spin up three agents, give them the same goal, and pray they don't step on each other's toes. Occasionally it works. More often you end up with three PRs touching the same file, plus a fourth conversation explaining why.

There's one key detail in Anthropic's design worth remembering: each thread is actually a Claude Code cloud session, running on its own branch and its own copy of the repo. The coordinator organizes the work, and if threads touch the same code, the overlap gets resolved as a merge conflict, just like a normal PR.

That distinction matters. If you can spin up five agents but can't say who owns which files, you don't have a project — you have a traffic jam with logs.

The coordinator must answer four questions: Which work should be its own thread? How many threads can we open today? Who has claimed which files? What can the finished pieces deliver? Most agent loops only answer the first — cram the whole goal into one prompt and let merge conflicts answer the third for you.

The correct order is: scope first, then cap, then claim files, then assemble. The order itself is the design.

Multi-Agent System refers to an architecture where multiple autonomous agents collaborate to complete a task. Common topologies include pipeline-style, blackboard-style, and coordinator-worker-style. Anthropic adopts the third: a single coordinator handles planning, assignment, and review, while multiple worker threads execute in parallel. This pattern traces back academically to the master-worker paradigm, whose advantage lies in centralizing global decisions to prevent agents from fighting over scope; the cost is that the coordinator becomes a bottleneck and a single point of failure. Understanding this topology helps justify the four questions in the article — they are essentially global state the coordinator must maintain: who's doing what, how many we can open, who owns which resources, and how outputs merge.

Building a Minimal Coordinator in Three Steps

Shared Memory: A Keyed Whiteboard

Anthropic says every thread pulls information from shared project memory — release date, decisions, who to ping before touching billing. In the miniature version, memory is just a list of facts, where remember writes or overwrites a key and recall reads it.

A human writes release=Friday, a thread reads it when it finishes, and the assembled board stays consistent without re-prompting. This isn't RAG — it's just a keyed whiteboard.

RAG (Retrieval-Augmented Generation) is another concept often compared against shared memory: it dynamically retrieves relevant fragments from a large document collection via vector similarity and injects them into the model context, emphasizing "unstructured recall." Shared memory, by contrast, is explicit key-value pairs, emphasizing "structured write and overwrite," letting any thread deterministically read a fact like release=Friday. The two solve different problems — RAG answers "where is the relevant knowledge," while shared memory answers "what has this project already confirmed." When multiple parallel threads need a consistent worldview, key-value memory is more appropriate than retrieval-based memory, because the former guarantees all threads see the same truth rather than diverging on different retrieval results.

Scoping Goals: The Coordinator Owns the Right to Split

A real system would call a model at this step. In the example, the planner is simulated — two demo goals return fixed thread plans, each with an id, title, and list of files it will touch.

Anthropic's article uses the same shape: retire a deprecated v1 endpoint, one thread per repo; or run performance profiling and open PRs in parallel. The most critical point — the coordinator owns the right to split, threads cannot invent their own scope. Bad splits are worse than no splits.

Thread Caps and File Claims

Every thread is a full session, so Claude Code Projects hits usage limits faster than ordinary usage. Anthropic's docs describe project-level usage controls, and press coverage at waitlist time mentioned a daily new-thread quota — but that number should be treated as media reporting, not as a direct quote from the official article.

In the example, the daily cap is an input: the first project gets three threads per day. Threads that fit the cap start as running; the rest stay queued with a reason attached. Queuing isn't failure — it just means waiting for tomorrow, or for a human to raise the cap manually.

File claims are stricter and earlier than Anthropic's: a thread must claim a file before it can complete, first-come-first-served. If another thread already claimed api/routes/checkout.ts, the new thread becomes blocked and prints the reason. You want conflicts in the coordinator log, not in a PR turf war that erupts on Friday.

The Board Is the Deliverable for Humans

A coordinator that never summarizes is just a process incubator. The assemble function organizes project state into a board: listing memory, completed threads, blocked threads, and queued threads.

Running npx tsx coordinator.ts shows two demos: the first retires the v1 checkout, three threads start, docs is queued because of the daily cap, and memory carries release=Friday into every completion. The second lowers p75 latency, profile and cache complete, and query is blocked because profile has already claimed api/routes/checkout.ts.

Humans read the board, and the agent should leave one behind.

Where This Model Breaks

Honestly, the example has clear limitations: scoping is simulated — a real coordinator needs a model or a human to split the work; file claims are too coarse — real repos need finer locks, or intentional shared ownership with merge rules; memory is a flat map with no provenance, no expiry, no access control — shared memory without rules becomes shared contamination; daily thread count is not the same as a token budget, a dollar budget, or a risk budget, and you might need all three; the example has no review step, whereas Anthropic's coordinator reviews outputs before assembling — here we just count status; and queued work doesn't auto-resume — raising the cap and draining the queue is left as an exercise to the reader.

A merge conflict is a common issue in version control: when two branches modify the same region of the same file, Git can't automatically decide which to keep and asks a human to choose. In Claude Code Projects, each thread runs on its own branch and repo copy, so conflicts don't blow up during thread execution — they're exposed at merge time. That's both the strength and the limitation. The strength is that threads don't block each other and can advance in parallel; the limitation is that conflicts get deferred to integration and may pile up into a one-shot batch of human arbitration. The file-claim mechanism is precisely meant to reduce the conflict surface at the source: grab the file first-come-first-served, making other threads blocked early rather than discovering overlap at merge time.

Coordination Is Becoming the Main Battleground of Multi-Agent Systems

Anthropic puts the coordinator session on top of parallel cloud threads, and the direction is right. Google's Gemini agents, Meta's Muse Wonder focus loop, and OpenAI's tool-heavy stack are all converging on the same shape from different angles.

Different products, same direction. Parallelism is a feature, coordination is the product.

The question truly worth asking is no longer "how many agents can we run," but "who coordinates them."

Background Notes

The daily thread quota and token budget mentioned in the article touch on a fundamental distinction in cost control for agent systems: concurrency budget and economic budget are not equivalent. A thread-count limit controls how many sessions are consuming resources at the same time — that's rate control. Token budget and dollar budget control the total amount you can spend — that's volume control. Risk budget constrains which operations require approval or must be reversible. All three need to be designed separately, because a system can have plenty of tokens but a concurrency blowout, or have idle concurrency but runaway economic cost. Real multi-agent systems often need to maintain all three budget dimensions simultaneously to balance availability and controllability.

One-line Summary

Anthropic defines Claude Code Projects as a coordinator session, and a TypeScript mini-implementation shows that multi-agent coordination is the real product.

Paragraph Summary

Anthropic reframes Claude Code Projects as a coordinator session rather than a folder of chat logs. Each worker thread is a cloud session running on its own branch and repo copy, with overlapping edits resolved as merge conflicts. The article builds a mini coordinator in TypeScript demonstrating five mechanics: shared memory (a keyed whiteboard), simulated goal splitting, a daily thread cap, first-come-first-served file claims, and a status board. The author stresses that a coordinator must answer four questions: which work becomes its own thread, how many can open today, who claims which files, and what the finished pieces deliver — the order itself is the design. The example has limitations: simulated splitting, coarse-grained file locks, memory without provenance, no review step, and no queue resumption. The author argues the main battleground for multi-agent systems has shifted from "how many agents can we run" to "who coordinates them" — parallelism is a feature, coordination is the product.