The Agent Lab
Ashrey

Claude Code Projects Gets Parallel Agents: A Coordinator, Shared Memory, and Plugin Evals

Anthropic redesigned Claude Code Projects to run parallel agent threads with a coordinator, shared memory, and a project library. Plus: claude plugin eval brings CI-grade testing to agent extensions.

On September 17, Anthropic shipped the most substantial change to Claude Code since auto mode went default: a redesigned Projects experience that turns a project into a persistent, multi-threaded workspace where a coordinator splits a goal into parallel cloud sessions, each a full Claude Code instance running on Opus by default. The beta is live for select Pro and Max subscribers.

At the same time, claude plugin eval landed in v2.1.269 (September 11), giving plugin authors a reproducible way to score their extensions against a no-plugin baseline, with JSON and HTML reports, configurable graders, and exit codes that work as CI gates.

Together, these two releases signal a shift: Claude Code is becoming a parallel agent runtime, and the tooling around it is maturing toward production-grade evaluation.

What Changed in Projects

The old Projects model was a collection of manually managed sessions. You opened a project, started a session, worked, closed it. Context lived in the session. If you wanted parallelism, you opened multiple terminals and copied context between them.

The new model introduces three primitives:

  • Coordinator — A lead agent that receives your goal, decomposes it into independent threads, assigns each thread to a cloud session, and tracks progress.
  • Parallel threads — Each thread is a full Claude Code cloud session (running on Opus by default) with its own working directory, git branch, and tool access. Threads run concurrently, modify code independently, run tests, and open pull requests.
  • Shared memory + project library — A persistent knowledge layer that survives across threads. Files, artifacts, decisions, and context written by one thread are visible to the coordinator and other threads.

The unit of work shifts from "a session" to "a project goal." You describe what you want built. The coordinator plans, spawns threads, monitors them, merges results, and presents a unified outcome.

How the Coordinator Works

Based on the beta documentation and early access reports, the flow looks like this:

  1. You create or open a Project and state a goal (e.g., "Add user authentication with JWT, refresh tokens, and rate limiting to the API").
  2. The coordinator analyses the codebase, identifies independent workstreams (auth middleware, token service, rate limiter, tests, docs), and spawns a thread per workstream.
  3. Each thread gets a fresh cloud session on Opus, a dedicated git branch, and access to the project library.
  4. Threads execute in parallel. They can read shared memory, write artifacts to the library, and push commits to their branches.
  5. The coordinator monitors thread health, resolves git merge conflicts when threads touch overlapping files, and synthesizes a final result — typically a set of PRs ready for review.

This is not "Claude Code with multiple tabs." It is a multi-agent system where the coordinator is itself an agent, and the threads are agents. The coordinator does not just dispatch tasks; it reasons about dependencies, detects conflicts, and steers progress.

Shared Memory: The Missing Piece for Long-Running Work

Before this, context persistence across sessions was manual — you copied files, wrote notes, or relied on git history. The project library changes that:

  • Files and artifacts written by any thread persist in the library. A thread that builds a type definition can publish it; another thread consuming that API reads it from the library.
  • Decisions and rationale are stored explicitly. The coordinator can record "chose JWT over sessions because..." and future threads inherit that context.
  • Cross-repo work is supported. A project can span multiple repositories; the library sits above them.

This makes Projects viable for work that spans days or weeks — refactors, feature epics, migrations — where a single session would hit context limits or lose thread.

Plugin Evals: CI for Agent Extensions

While Projects handles orchestration, claude plugin eval handles verification. Released September 11 in v2.1.269, it runs a plugin's eval suite against Claude Code and produces scored, reproducible results.

Key capabilities:

  • No-plugin baseline — Every case runs with and without the plugin. The delta tells you whether the plugin actually helps.
  • Six grader types — Exact match, semantic similarity, JSON schema validation, code execution, LLM-as-judge, and custom graders.
  • Configurable models — Pin the agent model (--model claude-sonnet-5) and judge model (--judge-model claude-haiku-4-5) so scores stay comparable over time.
  • CI-ready exit codes — 0 = all cases above threshold, 1 = at least one below, 2 = cost ceiling hit. The --threshold flag (default 1.0) sets the pass line.
  • Cost control — --max-cost-usd caps spend; partial results are returned if hit.
  • Reports — JSON (--json results.json) for archiving, HTML (--report report.html) for human review, with per-grader verdicts and judge votes.

A documented CI invocation:

claude plugin eval . \
  --trust-plugin \
  --json results.json \
  --threshold 0.8 \
  --model claude-sonnet-5 \
  --judge-model claude-haiku-4-5 \
  --no-publish \
  --max-cost-usd 20

This is the first time agent extensions have had a standard, reproducible evaluation harness. It plugs into GitHub Actions, GitLab CI, or any runner that can execute the CLI.

What This Means for Developers

Projects changes how you plan work. Instead of breaking a feature into sequential tasks for one agent, you describe the outcome and let the coordinator parallelize. The mental model shifts from "I drive the agent" to "I define the goal; the system orchestrates the agents."

Plugin evals change how you ship extensions. You can now gate merges on eval scores. A plugin that regresses on a test case fails the build. This is table stakes for any plugin you depend on in production.

Both features are beta. Projects is gated to select Pro and Max users. Plugin evals are available to all on v2.1.269+. Expect rough edges: coordinator plans may need correction, merge conflicts may require manual resolution, eval flakiness exists (the docs note results vary between runs).

What to Watch

  • General availability of Projects. The beta is limited. Wider rollout timing is unannounced.
  • Opus-by-default pricing. Parallel Opus sessions multiply cost. Anthropic has not published per-thread pricing for Projects.
  • Eval stability. The --runs flag (multiple runs per case) mitigates variance but increases cost. Best practices for threshold-setting will emerge.
  • Integration with MCP. Projects threads are full Claude Code sessions. They can spawn MCP servers, call tools, and use the project library as a shared context store — effectively making the library an MCP-compatible memory layer.

Practical Next Steps

  1. If you have Pro or Max, check for the Projects beta in your Claude Code UI. Try a small multi-file refactor as a first test.
  2. If you maintain a Claude Code plugin, add an eval suite and wire claude plugin eval into CI. Start with --threshold 0.8 and --runs 3.
  3. If you build on MCP, consider how the project library could serve as a shared memory layer for your own multi-agent workflows.

If this was useful, you can support my open-source work on Ko-fi or check out my services.