AI Watch · Anthropic / Claude news
Claude Code Projects: from a folder to a coordinator
On September 17, Anthropic redesigned Projects in Claude Code. The old project was a folder with some files and one chat. The new one is a single ongoing conversation where Claude acts as a coordinator, splitting work into parallel cloud threads that keep running after you close your laptop. It's in public beta, and it changes how you'd structure a long piece of work.
1. The model: coordinator and threads
The architecture has two layers. The project conversation is the coordinator: it reads what you send, answers quick questions in place, and starts threads for real work. It sees what threads report back, not every step they take. The threads are the workers. Each is a full Claude Code cloud session with its own context window, running on its own branch and its own copy of the repository.
A thread opens a pull request when the work calls for one, then watches it with auto-fix: it pushes fixes when CI fails and replies when checks pass. Threads can also delegate further, using subagents, loops and workflows. If two threads touch the same code, the overlap shows up as an ordinary git merge conflict — there's no special merge magic.
Mental shift: before, you were the coordinator — opening several sessions, copying context between them and stitching results together. Now the coordination itself is a conversation you steer.
2. What every thread inherits
Standing context is set once and reaches each new thread:
- the project's repositories and uploaded files;
- project instructions, up to 16,000 characters;
- project memory, which Claude writes and reads through a
MEMORY.md index (e.g. "the release moved to Friday", or who to check with before touching billing);
- the connectors on your claude.ai account (the project conversation itself has no connectors, so connector work must go to a thread);
- a cloud environment: network access, environment variables, credentials, installed tools.
Each thread clones every repository in the project and loads CLAUDE.md, skills and plugins from all of them. One caveat: permission rules, hooks and env only apply from the directory the thread starts in, so a single-repo project honors them and a multi-repo project does not. A Library tab collects the files you uploaded and the files threads produced, and the Overview pane groups threads by state: Ready for review, Waiting on you, Working, Landing, Idle and Resolved.
3. What the work looks like
Anthropic's own examples are cross-cutting jobs with several independent parts:
- Performance: set a goal to reduce checkout p75 latency, then ask Claude to profile each endpoint, test optimizations and open pull requests in parallel threads.
- Migration: retire a deprecated v1 endpoint across API, web and mobile repositories, one thread each, with Claude reporting which pull requests merge first.
The common shape: work that outlasts one reply and has more than one part. The coordinator decides when to fan out. A quick question stays in the conversation; a new piece of work becomes a thread, or goes to an existing thread working in the same area.
Cloud threads work on GitHub repositories and on files or Google Drive folders uploaded to the project — not on things that exist only on your machine. When a task needs a local database, a device emulator or an API behind your VPN, you can ask Claude to run that thread on your computer through Remote Control (Claude Code v2.1.280 or later; unavailable while "Require trusted devices" is on). A session you started yourself still can't be added to a project.
4. The cost side: limits and caps
Parallel is not free. Every running thread is a full session, and the coordinator conversation spends tokens too, so a project burns plan limits faster than a single session. Idle threads also wake and spend again when CI fails or a review comment lands.
- The enforced ceiling is 200 new threads per day across your projects.
- A thread that hits a usage limit waits and resumes on its own (a thread started by a routine stops with a limit error instead).
- There's a per-project Usage tab, plus separate model and effort settings for the coordinator and for threads. A new project defaults to Opus everywhere, high effort for threads and low effort for the conversation.
Practical tip: the default of low effort for the coordinator and high effort for workers is a reasonable split — routing is cheap, real work is not. Tune it before you scale up.
5. Who can use it, and where
| Aspect | Status (as of late September 2026) |
|---|
| Plans | Public beta for Pro and Max; Team and Enterprise not yet |
| Rollout | Gradual, starting with accounts that already used cloud sessions and have no existing projects in Claude or Cowork; a waitlist exists |
| Where | claude.ai/code, the desktop app and the mobile app — not the terminal CLI, nor Bedrock, Google Cloud or Foundry |
| Ownership | One project belongs to one user; no organization-level controls during the beta |
Related: Anthropic's docs for plain cloud sessions dropped the "research preview" label in the same week — they're now listed as available on Pro, Max and Team, and for eligible Enterprise seats. That doesn't make Projects generally available; Projects keeps its own beta rollout.
6. When it fits, and when it doesn't
- Good fit: multi-repo migrations, a research stream with several deliverables, a build where implementation, tests and review can proceed in parallel.
- Poor fit: a small change in one file. A single session is cheaper and easier to follow.
- Watch out for: overlapping branches (you'll resolve merge conflicts the usual way), usage burn, and the single-user boundary for teams that need shared controls.
- Review is still yours. Threads open pull requests; deciding what merges, and in what order, remains a human job.
Takeaway: the promise isn't simply "more agents." It's a persistent work queue with shared memory, repository-aware threads and one place to see what's finished, what needs you and which pull requests are ready — in exchange for faster spend and a beta-stage rollout.
Sources
IA Watch · Novidades da Anthropic/Claude
Projects no Claude Code: de pasta a coordenador
Em 17 de setembro, a Anthropic redesenhou os Projects no Claude Code. O projeto antigo era uma pasta com alguns arquivos e um chat. O novo é uma única conversa contínua em que o Claude atua como coordenador, dividindo o trabalho em threads paralelas na nuvem que seguem rodando depois que você fecha o notebook. Está em beta público e muda como você estruturaria um trabalho longo.
1. O modelo: coordenador e threads
A arquitetura tem duas camadas. A conversa do projeto é o coordenador: lê o que você manda, responde perguntas rápidas ali mesmo e abre threads para o trabalho de verdade. Ela vê o que as threads reportam, não cada passo que elas dão. As threads são os trabalhadores. Cada uma é uma sessão completa do Claude Code na nuvem, com janela de contexto própria, rodando numa branch própria e numa cópia própria do repositório.
Uma thread abre um pull request quando o trabalho pede e depois o acompanha com auto-fix: envia correções quando o CI falha e responde quando os checks passam. Threads também podem delegar mais, usando subagentes, loops e workflows. Se duas threads mexem no mesmo código, a sobreposição aparece como um conflito de merge comum do git — não existe mágica especial de merge.
Mudança de mentalidade: antes, você era o coordenador — abrindo várias sessões, copiando contexto entre elas e juntando os resultados na mão. Agora a própria coordenação é uma conversa que você conduz.
2. O que toda thread herda
O contexto permanente é definido uma vez e chega a cada nova thread:
- os repositórios do projeto e os arquivos enviados;
- instruções do projeto, de até 16.000 caracteres;
- memória do projeto, que o Claude escreve e lê por um índice
MEMORY.md (ex.: "o release foi para sexta" ou com quem falar antes de mexer em billing);
- os conectores da sua conta claude.ai (a conversa do projeto em si não tem conectores, então trabalho que usa conector precisa ir para uma thread);
- um ambiente de nuvem: acesso à rede, variáveis de ambiente, credenciais, ferramentas instaladas.
Cada thread clona todos os repositórios do projeto e carrega CLAUDE.md, skills e plugins de todos eles. Uma ressalva: regras de permissão, hooks e env só valem a partir do diretório onde a thread começa — então um projeto de um único repositório as respeita e um projeto com vários repositórios não. Uma aba Library reúne os arquivos que você enviou e os que as threads produziram, e o painel Overview agrupa as threads por estado: Ready for review, Waiting on you, Working, Landing, Idle e Resolved.
3. Como é o trabalho na prática
Os exemplos da própria Anthropic são tarefas transversais com várias partes independentes:
- Performance: definir como meta reduzir a latência p75 do checkout e pedir ao Claude que perfile cada endpoint, teste otimizações e abra pull requests em threads paralelas.
- Migração: aposentar um endpoint v1 obsoleto nos repositórios de API, web e mobile, uma thread para cada, com o Claude informando quais pull requests devem ser mergeados primeiro.
O formato comum: trabalho que dura mais que uma resposta e tem mais de uma parte. O coordenador decide quando abrir em paralelo. Uma pergunta rápida fica na conversa; uma nova frente de trabalho vira uma thread, ou vai para uma thread existente que já atua na mesma área.
Threads na nuvem trabalham em repositórios do GitHub e em arquivos ou pastas do Google Drive enviados ao projeto — não em coisas que só existem na sua máquina. Quando a tarefa precisa de um banco local, um emulador de dispositivo ou uma API atrás da VPN, você pode pedir ao Claude para rodar aquela thread no seu computador por meio do Remote Control (Claude Code v2.1.280 ou superior; indisponível enquanto "Require trusted devices" estiver ligado). Uma sessão que você mesmo iniciou ainda não pode ser adicionada a um projeto.
4. O lado do custo: limites e tetos
Paralelo não é de graça. Cada thread em execução é uma sessão completa, e a conversa do coordenador também gasta tokens — então um projeto consome os limites do plano mais rápido que uma sessão única. Threads ociosas também acordam e gastam de novo quando o CI falha ou chega um comentário de revisão.
- O teto aplicado é de 200 novas threads por dia somando todos os seus projetos.
- Uma thread que bate no limite de uso espera e retoma sozinha (uma thread iniciada por uma routine para com erro de limite).
- Há uma aba Usage por projeto, além de configurações separadas de modelo e esforço para o coordenador e para as threads. Um projeto novo usa Opus em tudo, esforço alto nas threads e baixo na conversa.
Dica prática: o padrão de esforço baixo no coordenador e alto nos trabalhadores é uma divisão razoável — rotear é barato, trabalhar de verdade não é. Ajuste isso antes de escalar.
5. Quem pode usar, e onde
| Aspecto | Situação (até o fim de setembro de 2026) |
|---|
| Planos | Beta público para Pro e Max; Team e Enterprise ainda não |
| Liberação | Gradual, começando por contas que já usaram sessões na nuvem e não têm projetos no Claude ou no Cowork; existe lista de espera |
| Onde | claude.ai/code, app desktop e app mobile — não no CLI do terminal, nem em Bedrock, Google Cloud ou Foundry |
| Propriedade | Um projeto pertence a um único usuário; sem controles em nível de organização durante o beta |
Relacionado: a documentação das sessões na nuvem tirou o rótulo "research preview" na mesma semana — agora constam como disponíveis em Pro, Max e Team, e em assentos Enterprise elegíveis. Isso não torna os Projects disponíveis para todos; eles seguem com a liberação beta própria.
6. Quando faz sentido, e quando não
- Bom encaixe: migrações em vários repositórios, uma frente de pesquisa com vários entregáveis, um build em que implementação, testes e revisão andam em paralelo.
- Mau encaixe: uma mudança pequena num arquivo só. Uma sessão única é mais barata e mais fácil de acompanhar.
- Atenção a: branches que se sobrepõem (você resolve conflitos de merge do jeito de sempre), consumo de limite e a fronteira de usuário único para times que precisam de controles compartilhados.
- A revisão continua sendo sua. As threads abrem pull requests; decidir o que entra e em que ordem segue sendo trabalho humano.
Conclusão: a promessa não é simplesmente "mais agentes". É uma fila de trabalho persistente com memória compartilhada, threads que conhecem o repositório e um único lugar para ver o que terminou, o que precisa de você e quais pull requests estão prontos — em troca de gasto mais rápido e de uma liberação em beta.
Fontes