Claude Code Projects: Coordinator Blind to Thread History, Memory Becomes Source of Truth
Claude Code Projects coordinates work by spawning isolated cloud threads that report back results, but the coordinator sees only thread summaries — not full histories — forcing cross-thread decisions into persistent project memory, while a hard quota of 200 new threads per day replaces soft concurrency preferences.
When Not to Use Projects
The documentation lists four scenarios where Projects should not be used:
A task completable in a single session (e.g., fixing a flaky login test) — just open a cloud session.
Tasks requiring local machine resources (local database, device simulator, VPN-gated API) — use local sessions or agent view for parallel runs.
Recurring, scheduled tasks with no conversational context (e.g., weekly dependency report) — create a routine instead.
Multiple people dispatching and steering tasks together in Slack — that is Claude Tag.
The threshold for Projects is not "many tasks" but "a goal that outlives a session and continuously generates tasks." Tasks that don't need coordination shouldn't be parallelized for its own sake. A Project shares quota with other Claude Code sessions and consumes it faster.
Coordinator Only Routes and Reduces
The model has two roles:
Project — a long-lived conversation where Claude acts as coordinator: it receives input, decides which items become new threads, which go to existing threads, which it answers itself, and tracks every thread it has spawned.
Thread — the worker layer. Each thread is an independent session with its own context window, performs one task, and reports back. Cloud threads work on their own branches and open pull requests when needed.
The Overview panel groups threads by status; a "Waiting on you" group holds threads needing your reply, approval, or that have failed. The Overview button shows a dot when threads await you.
Critical visibility constraint: the coordinator "only sees the content threads report back, not every step they took." Two consequences follow. First, a decision existing only in your messages to the coordinator survives only while the coordinator's context retains it — and that context does not run on full history. Second, a thread's internal waits (e.g., permission prompts) do not surface in the project conversation; you must enter that specific thread to respond (identifiable via the "Waiting on you" group).
What Each Cloud Thread Receives at Startup
Every cloud thread begins with four items:
The project's repositories and files, plus its instructions and memory.
Each repository's CLAUDE.md and skills; if the project has only one repository, that repo's permission rules and hooks are also included.
Connectors from your claude.ai account.
A cloud environment defining network access, environment variables, network secrets, and pre-installed tools.
An important boundary: permission rules and hooks only reach cloud threads when the project has a single repository. With multiple repositories on an Anthropic-hosted environment, no repository's permission rules arrive — you must rely on auto mode and per-thread approvals (self-hosted environments follow different rules). Additionally, cloud threads inherit nothing from your local Claude Code configuration — skills, MCP, plugins, tools must be provided on the thread side via repository commits or project settings.
Runtime Isolation
Threads share only the "startup snapshot." After launch, each has its own context window and auto-compacts; overflow shows "Claude ran out of context on this turn." Branches and sandboxes are also isolated.
Two timing gaps matter:
A thread can temporarily add a repository mid-task, but that repo's CLAUDE.md and skills are absent at thread start and won't exist for subsequent threads.
The coordinator side has no connectors; any task needing a connector must be dispatched to a cloud thread.
Where State Belongs: Three-Tier Separation
Project memory — Claude-written notes about the project (requirements, decisions, pitfalls) stored as files. Each cloud thread reads the index file MEMORY.md at startup and opens other files as needed. You write via "ask Claude to remember this" or edit directly in Project settings > Memory.
Project instructions — a text block (≤16,000 characters) sent to every new thread and to the coordinator. Suits rules every thread must follow: "start from branch X," "self-check before finishing."
Repository CLAUDE.md — read from each thread's own clone. Holds per-repo build commands and conventions.
Do not mix them. Per-repo guidance goes in that repo's CLAUDE.md; project-level notes go in project memory. Exception: threads running on your machine via Remote Control receive project instructions but do not load project memory files.
What Consumes Quota
Three quota-burning sources:
Running threads — each is a full session; multiple can run simultaneously (no fixed cap documented).
The coordinator conversation — it reads thread reports, decides next steps, and spends tokens itself.
Threads watching pull requests — an idle thread wakes on CI failure or review comments, consuming quota again; disable by telling the thread to stop watching.
Hidden cost from wake-ups: routing a follow-up message to a thread idle beyond cache lifetime (1 hour on Pro/Max) forces a full re-read of that thread's conversation before acting. Starting a fresh thread for new work can be cheaper than reviving a large, stale one.
Default settings increase cost: new projects run both threads and coordinator on Opus — threads at high effort, coordinator at low effort — the most expensive configuration. Lower model or effort for tasks not needing maximum capability.
Two Design-Level Takeaways
Because both coordinator and thread contexts lose information, project memory is not an optional scratchpad. Project instructions are pre-written rules; project memory is the living notes Claude accumulates during the project, re-read by every new thread at startup. To make a decision survive the whole project, merely stating it in conversation is insufficient — you must have Claude remember it.
Likewise, the real limiter is not "how many at once" but "how many new per day": concurrency is a preference the coordinator follows voluntarily, while the enforced hard limit is 200 new threads per day across all projects. Idle threads watching pull requests also continuously drain quota.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architecture Development Notes
Focused on architecture design, technology trend analysis, and practical development experience sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
