Claude Projects Are Being Rebuilt Around a Memory Every Thread Writes Into — Anthropic Moves the Project You Already Have Later (2026)

Two posts, one day apart, both about where work lives.

The projects post is dated September 17, 2026. It describes a two-layer structure: "Projects have threads that do the work and a coordinator that directs them." Each thread is not a lightweight task. Anthropic is specific: "Under the hood, each thread is a Claude Code cloud session working on its own branch and copy of the repo."

Because each thread has its own copy, code collisions get a documented resolution path: "The coordinator keeps work organized, but if any threads work on the same code, the overlap is resolved as a merge conflict just like any other PR." Threads can also subdivide — "Each thread can further split its delegated work into pieces using subagents, loops, and workflows when needed so large assignments finish faster." Where that subdivision leaves context is its own question, one we took up in what subagents do and don't share.

Then the context section. Anthropic frames projects as built "for long-running or agentic workflows: work that takes longer than one reply and has more than one part," and describes the memory as cumulative: "Over time, Claude learns more about the project details and applies them to its work." The examples given are decisions, not code — "Claude can remember the release moved to Friday, why the export was dropped, or who to check in with before touching the billing service." Alongside it, "projects now include a library that collects the files you add and the artifacts produced by Claude."

The rollout language is the part almost nobody quoted. Access began, in Anthropic's words, for "select Claude Pro and Max subscribers who use cloud sessions in Claude Code and don't have any existing projects on the web or desktop." If you have been using projects, that clause is about you. And the follow-up sentence says what happens next: "Existing projects on Pro and Max plans keep working as they do today. We'll upgrade them as the rollout expands to chat and Cowork."

The second post, dated September 16, 2026, is the structurally identical event one day earlier: "Starting today, Claude Cowork and chat are merging into one Claude." Anthropic's own explanation of why names the problem in the clearest terms anyone has managed: "We built Cowork as a separate place for bigger work, and Design for visual work. People used both, and told us the frustrating part was deciding where a task belonged. What they'd started in one also didn't carry into the other."

That is a vendor writing down, in a launch post, that its own containers did not pass context between themselves. The fix is stated just as plainly — what those surfaces can do is now "available from any conversation, with the context, skills, and connectors you already have" — and for people already inside Cowork, "everything is where you left it: your chats, projects, artifacts, connectors, and skills."

It changes who writes. Until now, a project accumulated context mostly because you put things in it. In the redesigned project, every thread adds to the shared memory as it works. The writing side went from one author to many, and the authors are sessions rather than people. A coordinator handing work out has the same shape as an agent team, and where that context lands is the question we took up in what agent teams share.

It changes where reading happens. Anthropic describes inspection at two levels: "You can monitor and guide progress in the main project chat, or dive into each individual thread to examine and steer the details." So there is a place to look. The thing to build a habit around is looking at it — the shared memory is now a working artifact, not a settings panel you configure once.

It changes the cost profile. "Projects can run several threads at once, and each one is a full Claude Code session. Because of this, projects can reach usage limits faster." Anthropic pairs that with controls: "You can check project specific usage and select the model and effort levels used by the coordinator chat as well as the worker threads."

It does not change where threads run, yet. "Threads run in the cloud today; running on your machine alongside your local tools and code and behind your network is coming very soon."

It does not change your existing project today. It keeps working as it does today, and gets upgraded later. That is a gap with a shape: the project you are using now is on one side of a conversion you have not seen yet.

It does not make a project a durable record. A project is where a body of work lives while it is live. The reasoning behind a decision is worth more than the decision, and it outlives the container — which is the distinction we drew in why a long context window isn't memory.

"Shared memory means I can stop writing things down." The post says the shared memory reduces "the need for complex prompt engineering," which is a claim about prompts, not a claim about your records. The things Anthropic lists as examples — a moved release, a dropped export, a person to check with — are exactly the things you want written somewhere you can read next quarter, in your own words.

"Parallel threads are just faster sessions." Each thread is a full cloud session on its own branch and its own copy of the repo. That is a different unit of work from a tab, and Anthropic's own note about usage limits is the tell.

"Code and memory both get merged." Anthropic describes one resolution mechanism explicitly, and it is for code: overlap "is resolved as a merge conflict just like any other PR." For the shared memory, the same page describes a different relationship — every thread "adds to and draws from" it. Those are two different designs, and it is worth reading them as two different designs rather than assuming one covers both. Another vendor arrived at a similar split, which we examined in what reaches the next agent in Cursor Projects.

"My project will just become the new thing." It will be upgraded, on Anthropic's timeline, as the rollout expands to chat and Cowork. Between now and then it keeps working as it does today. Anthropic also set expectations for organizations in the Cowork post: "Enterprise admins will hear from us at least 30 days before anything changes for their organizations."

"This is the same as branching a session." It isn't. A branch copies one session so you can take a different path; a project runs many sessions against one goal. We worked through the branch case separately in forking a remote Claude Code session.

The goal is not to avoid the shared memory. It is to know which half of your context is allowed to live inside a container that is mid-redesign.

Step 1: Write down the decisions before the threads start

Before you set a goal and let a project fan work out, write the three or four things that would be expensive for any thread to guess: the constraint you already ruled out, the convention the team agreed on, the service nobody touches without asking a specific person. Anthropic's own examples of project memory are exactly this kind of fact, which tells you they matter; write them where you can read them back without opening the product that stores them.

Step 2: Read the thread, not just the summary

Use both levels Anthropic describes. The project chat tells you where the work is; the individual thread tells you what it concluded and on what basis. When a thread's conclusion becomes a decision the team will live with, copy it out in a sentence of your own. A conclusion that exists only inside a thread is a conclusion you will be re-deriving.

Step 3: Keep a copy that survives the upgrade

Your existing project keeps working today and will be upgraded later. Anything you would hate to re-explain after that conversion should already exist outside it. This is the same discipline that makes a tool switch survivable, and it is the one covered in carrying context between Claude Code sessions.

The durable half of that split needs somewhere to live that isn't a project, a thread, or a vendor's container. MemoryLake is a store you write those decisions into on purpose, separate from any one product's structure and readable from every assistant you connect. You write the entries yourself, in your own words. Nothing is read out of, written to, or deleted from Anthropic's systems or any other vendor's store — your projects, threads, and libraries stay entirely under their own controls.

Step 1: Create an API key

Generate a key from the dashboard. It is what lets a coordinator chat, a terminal session, and a different assistant entirely reach the same set of facts without each one keeping its own copy.

Step 2: Upload your first memories

Start with the four categories Anthropic's own examples point at: dates that moved, things you decided against, ownership of specific services, and conventions you expect to be followed. Add the reason next to each one. The reason is what stops a future thread from proposing the thing you already rejected.

Step 3: Connect your AI & agents

Point your tools at the layer so those facts load at the start of work rather than being reconstructed from a transcript. Then run the only test that proves anything: ask a different assistant to tell you one of the decisions back. If it answers, your reasoning is no longer tied to one product's shape.

The first change is that "which surface does this belong in" stops being a question you answer twice. Anthropic just removed that question from its own products, and said out loud that the answer used to cost people context. The same logic applies one level up: if a fact matters across tools, it should not live in whichever tool you happened to open.

The second is that project memory becomes something you review rather than something you trust. Many threads write into it. Reading a thread's conclusions is now part of the work, not an audit you do when something goes wrong.

The third is that the difference between a decision and a record becomes operational. A project is excellent at holding a live effort together. A record of why you chose something is a different artifact with a different lifespan, and the redesign is a good moment to notice you were storing both in the same place.

The fourth is that upgrades stop being alarming. Your existing project keeps working today and changes later. If everything load-bearing has a copy outside it, that conversion is a notification rather than an afternoon.

Set the goal narrowly the first time. Anthropic's framing — "Brief Claude in the project the way you'd brief a chief of staff and it routes work to new or pre-existing threads" — works best when the brief is specific enough that routing is obvious.

Check project-specific usage early. Several full cloud sessions at once is a different consumption pattern, and Anthropic documents controls for the coordinator and the worker threads separately.

Treat the library as an inbox, not an archive. It collects the files you add and the artifacts Claude produces. Useful for finding things during the work; not the same as a curated record of what you concluded.

Write the reason, not just the rule. "Don't touch billing without asking" ages badly. "Don't touch billing without asking, because the reconciliation job runs at a fixed hour and a schema change broke it in June" survives a handover.

Keep one copy outside the container. Anthropic has now moved two containers in two days. That is a product getting better, and it is also a reason to hold your durable facts somewhere that isn't a container.

The redesign of Claude projects is a genuine change in what a project is: not a folder with a chat attached, but a conversation with a coordinator, parallel cloud sessions, a library, and a memory that every thread contributes to. Anthropic documented the whole shape, including the parts that are easy to miss — that code overlap resolves as a merge conflict, that threads are full sessions with a real cost, that threads run in the cloud for now.

The two sentences to keep are the ones about what you already have. Existing projects "keep working as they do today," and Anthropic will "upgrade them as the rollout expands to chat and Cowork." Nothing about that is a problem. It is simply a scheduled change to the shape of the place your context is sitting.

The day before, Anthropic explained why containers matter at all: people kept having to decide where a task belonged, and "what they'd started in one also didn't carry into the other." That is the clearest statement of the problem anyone has published this month. The practical response is not to pick a better container. It is to keep the facts that outlive any container somewhere you control, and let the containers keep improving.