Run a first Claude Code Projects goal and track its cost

If you have a Pro or Max plan and a real repository, the first Claude Code Projects goal should be a burn test. In a comparison of Codex, Claude Code, and Kimi Code, dynamic concurrency raised token use to between 1.41 and 3.31 times sequential execution, while end-to-end success moved from an 11.9 percentage point drop to a 2.3 percentage point gain.

Claude Code Projects launched on September 17, 2026, after Anthropic reworked Projects so one coordinating conversation could manage Claude Code work. The beta opened to all applicants with Pro or Max plans on October 10, 2026. It is a public beta for Pro and Max plans, rolling out gradually, and not yet on Team or Enterprise plans. The coordinator is where you decide what to scale, and the first goal should tell you whether it is worth the burn.

A parallel worker is only worth scaling after it survives a small goal

Pick a repository you know well enough to judge a diff quickly. Make the goal small enough that a bad thread is cheap, and record the baseline before any worker starts. A cheap failure is a thread you can discard without touching production. Your job is to learn how much plan a useful thread costs.

The first goal should be narrow enough that you can read every diff without missing anything. One endpoint, one test suite, one metric. A goal that needs a product decision is too big for a burn test. A thread that asks what to do means the goal was too vague. You want a number, not a narrative.

Make the first goal cheap enough to fail

• Define one measurable goal. Use the optional one-line goal field for a checkable target, for example holding the 95th percentile API latency below 200 ms. Choose a metric your tests can assert, and record the baseline before any thread starts. The metric should be visible in your normal test run. Your target should be a sentence that fails if the code regresses.
• Write instructions under the tool's limit. Project instructions can run up to 16,000 characters. Put repository conventions, test commands, and no-go areas in the project's shared index, and keep that index short enough for a new thread to read quickly. Do not paste the same rules into every thread prompt. Threads read the MEMORY.md index at start; later edits to instructions, repositories, plugins, or environment settings affect only newly created threads. Finish with a stable instruction set before the batch starts.
• Start with two or three threads. Threads begin when you press Start for each recommended thread, not fully autonomously. The project allows at most 200 new threads per day. Start a second batch only after the first is closed, and skip any recommended thread that duplicates work. Review the small batch before the queue grows.
• Check plan usage before the batch finishes. A project uses the same limits as the rest of your Claude Code usage, and it drains them faster. Check project-specific usage and set model and effort levels for the coordinator chat and worker threads. Watch for repeated context reads, including idle-cache re-reads, in the usage numbers. Write down the number before and after the batch. Compare the usage number to the value of the goal, and hold the batch at its current size if the number is already high.
• Accept only pull requests that pass your own tests. Each task gets an isolated cloud Claude Code session and its own git branch; after the session codes, tests, and opens a pull request, it sends the outcome back to the coordinator. Run the same tests you would run for a human pull request. Treat a thread that changes tests to pass as failed. Do not merge because the thread says it worked. Make the merge decision from your test suite, not the thread's summary.

Stop when the numbers say stop

When the first goal burns more plan than the work saves, shrink the goal, lower the effort, or run sequentially. Leave with a measured burn rate and a list of pull requests you would actually merge.