The old Claude Projects was, if you are being precise about it, a folder of chats with a system prompt stapled to the top. That description sounds uncharitable, but it is accurate, and it explains why the October 2026 update feels less like a feature release and more like a different product wearing the same name. The coordinator-and-threads model that replaced it changes the order of operations, the cost profile, and the failure modes, none of which will be obvious if you open a new project and start working the way you used to.

What follows is a setup guide for the new architecture, written for people who already know how to use Claude and are now trying to figure out what changed and why it matters.

What the Old Model Was and Why It Had a Ceiling

The prior Projects feature gave you a shared context window, a persistent instruction set, and a collection of chats that all drew on the same background. That was genuinely useful for keeping a model oriented across multiple working sessions, but it had a structural limit: everything ran in a single session model, which meant the "project" was really just a memory layer, not a coordination layer. You could not run parallel workstreams. You could not delegate tasks to worker contexts with their own tool access. The model knew your background, but it could not act on your behalf in more than one direction at a time.

The new architecture, as demonstrated in a practitioner walkthrough of the update, fixes that ceiling by introducing a coordinator and a set of threads. The coordinator, which defaults to Opus, acts as a project manager: it holds context, makes decisions about what to do next, and delegates work to threads. The threads are where actual work happens. Each thread runs in its own session, carries its own context, and has access to tools. If you need to draft a specification section, run a web search, and generate a code artifact at the same time, those three tasks can run in parallel threads rather than waiting in sequence.

That is a real change in what the tool can do. It is also the source of several new failure modes that the old model never had.

The Rule That Will Break Your Workflow First

The most disorienting thing about the new architecture is a constraint that feels like a bug until you understand why it exists: the main orchestrator chat cannot use tools, browse the web, run code, or create artifacts. Only threads can do those things.

This inverts the instinct most people have built. In the old model, you worked in a chat, and the chat did things. In the new model, the main chat is purely a steering layer, and the threads are the execution layer. If you open the main orchestrator chat and ask it to summarize a document, research a competitor, or write a draft, you are asking it to do something it is specifically not designed to do. It will acknowledge the task, create a thread, and hand the task off. If you are not expecting that, the behavior looks like the model is avoiding the question.

As a second practitioner walkthrough covering the orchestrator model describes it, the main chat is for orchestration only, while threads handle the actual tool use. Once you internalize that division, the orchestrator becomes exactly the right place to do the work that used to happen in your head: deciding what the project needs next, reviewing what threads have returned, and setting the direction for the next round of execution. Keep the orchestrator chat for steering. The moment you catch yourself trying to produce something in it directly, you are working against the architecture.

Build the Environment Tab Before You Build the First Thread

The update introduces a dedicated environment tab, and the correct order is to configure it completely before you create any threads. This is not a cosmetic preference. Skills and routines that run inside a thread execute in the cloud environment the tab defines, and if that environment is not set up correctly, the thread will fail in ways that are harder to diagnose after the fact than before.

The environment tab is where you set up network access controls, credential stores, environment variables, and the setup scripts the cloud session needs to initialize. It is also where you connect your context sources, through library file uploads (currently capped at 100 files), a connected GitHub repository, or a hybrid remote-control link to a local folder if you need the project to reach local resources. Each of those options has a different latency and security profile, and the choice matters for how threads behave when they need to pull information.

The specific gotcha the walkthrough surfaces is local dependency resolution. Skills that were built to run locally, referencing a SQLite database by a local file path or pointing at a folder that lives on your machine, will fail silently in the cloud execution environment because those resources do not exist there. The cloud session cannot reach your local file system. The presenter's SQLite content database and several locally pathed skill dependencies both failed during the demo for exactly this reason.

The workaround for local dependencies is a hybrid remote-control setup that points the cloud environment at a local folder, which works but requires deliberate configuration. The better long-term move is to audit every skill before you deploy it to the new environment and confirm that each dependency resolves from within a cloud context. If it does not, either refactor the skill to pull from a remote source, connect the relevant repository, or configure the remote-control bridge before the thread ever runs. Discovering this after three threads have already failed is a reasonable way to spend an afternoon, but not a necessary one.

Token Cost Is Now a Project-Level Variable, Not a Session Variable

Parallel threads running frontier models accumulate tokens fast, and the new interface surfaces this in a way the old model never had to. The second walkthrough logged 87.1 million tokens across a single project, which is not a cautionary outlier so much as an illustration of what the architecture makes possible and what it costs.

The old model's single-session structure had a natural throttle: you could only do one thing at a time, which meant token consumption was roughly proportional to elapsed time and effort. The new model removes that throttle. Parallel threads running simultaneously against Opus or a comparable frontier model can accumulate context costs at a rate that is not obvious from the interface until you look at the token log.

Set a check interval before you start running parallel threads in any project that has a real cost ceiling. The right interval depends on the model tier, the number of threads you are running, and how much context each thread is inheriting. A rough heuristic: check the token log after the first full round of thread execution, before you spin up additional threads, and after any session where you ran more than two threads in parallel. The goal is not to minimize tokens, because token consumption is how work gets done, but to avoid running up a cost you did not authorize against an outcome you have not reviewed yet.

Context Inheritance Has a Lag You Should Design Around

Threads share project memory, but with a specific timing constraint that the second walkthrough makes explicit: a new thread inherits project memory up to the moment it is created, not as a live feed. If thread A produces an artifact and you create thread B immediately afterward, thread B may not see what thread A just finished, depending on how quickly the memory layer updates.

This matters most when you are building a workflow where later threads depend on the output of earlier ones. The temptation is to create all your threads at the project's start and let them run. For truly parallel, independent tasks, that works cleanly. For sequential tasks where thread B needs to consume what thread A produced, you should wait until thread A has completed and its output has settled into the project memory before creating thread B. The orchestrator chat is the right place to do that review, which brings the constraint and the architecture's design back into alignment: the orchestrator reviews, then steers, then creates the next thread.

A Setup Sequence Worth Following

Given everything above, here is the order that avoids the most friction:

Start by opening the environment tab and doing nothing else. Identify every skill or routine you plan to use and trace its dependencies. For each dependency, confirm whether it resolves from a cloud context. If it does not, either connect the repository, refactor the skill, or configure the remote-control bridge before you proceed. Upload context to the library or connect the GitHub repo. Set environment variables and credentials. Run a minimal test thread with no dependencies before you add anything complex.

After the environment is confirmed, open the orchestrator chat and use it only for high-level steering: describing what the project is for, what the current state is, and what the next round of threads should accomplish. When a thread completes and returns an artifact or result, review it in the orchestrator before creating the next dependent thread. Check the token log at natural breakpoints, not at the end when the cost is already fixed.

Design Mode, now integrated as an artifact type within the project rather than a separate hidden feature, is worth using for any project where you need a visual output, a layout, or a board-style deliverable. It is accessible from both the desktop and iOS app, which means the orchestrator review step can happen from wherever you are, not just from a desk.

Questions to Ask Before You Run the First Thread

The most common failure mode in the new architecture is not a misunderstanding of the coordinator model or a misconfigured environment tab. It is running before the environment is ready, because the interface is inviting enough that starting feels natural before the prerequisites are actually in place. Before you spin up the first real thread in a new project, the following questions are worth sitting with.

Have you confirmed that every skill the project depends on resolves its dependencies from within a cloud context, not from a local path? If any skill points at a local database or a local file path, that thread will fail, and the failure may not be immediately obvious about why.

Does the project have a token ceiling, and have you checked the log after the first round of thread execution? Parallel threads running frontier models are expensive, and the cost accumulates faster than the old single-session model made possible.

Have you configured the environment tab completely before creating any threads? The environment is not a setting you can backfill cleanly once threads have already run against an incomplete configuration.

Do you have a clear understanding of which tasks in your project are genuinely parallel versus sequentially dependent? Parallel tasks can be threaded simultaneously. Sequential ones need the orchestrator review step in between, which means designing your workflow around the memory inheritance timing rather than against it.

And finally: are you using the orchestrator chat only for steering? If you find yourself trying to produce an artifact, run a search, or write a draft in the main chat, stop and create a thread instead. That is not a workaround. That is how the architecture is designed to work.