O que é o Projects do Claude Code: como o Claude distribui as threads, quem pode usar, a exigência do GitHub e o custo em tokens

Em 17 de setembro de 2026, a Anthropic anunciou que havia reconstruído o Projects no Claude Code. O nome em si não é novo. É a mesma palavra que o chat do claude.ai usa para a caixa que guarda conversas e arquivos de referência no mesmo lugar. O novo Projects mantém esse nome e troca tudo o que está por trás dele. O subtítulo do post oficial no blog já é a resposta inteira: "da pasta para a conversa".

Em uma frase, o que mudou é que a tarefa de distribuir o trabalho saiu das suas mãos e passou para as do Claude. Você joga um pedido na conversa, o Claude o divide em "threads", as threads rodam em paralelo na nuvem e cada uma abre um pull request e volta com um relato quando termina. Fechar o notebook não as interrompe.

Antes de mergulhar, porém, vale conferir três coisas: as contas que podem usar ainda são poucas, o GitHub é uma exigência na prática e a velocidade com que isso devora o seu limite de uso não tem nada a ver com a de uma sessão única. Este artigo volta às fontes primárias, a documentação do Claude Code e o blog oficial, para entender se você pode usar e o que acontece quando usa.

1. Já não é uma pasta, e sim uma única conversa

O novo Projects é feito de duas partes: a conversa do projeto, em que o Claude faz o papel de coordenador, e as threads que essa conversa inicia.

A conversa é uma sessão longa, que não termina. Ela lê o que você envia, responde na hora quando basta uma resposta e recorta em uma thread tudo o que é trabalho de verdade. Ela não fica observando o que acontece dentro dessas threads. Ela só enxerga o que elas relatam de volta.

As threads são onde o trabalho acontece. Cada uma é uma sessão na nuvem independente, com a sua própria janela de contexto. Ela trabalha no seu próprio branch, abre um pull request quando é o caso e relata à conversa quando termina. A documentação descreve os estados das threads enfileirados em uma lista chamada Overview, assim.

O ponto que vale guardar aqui é que trabalhar em paralelo não é a novidade. O Claude Code já tinha subagents, agent view, Agent Teams e dynamic workflows. O que o Projects acrescenta não é paralelismo, e sim duas outras coisas: você deixa de fazer a distribuição e o acompanhamento por conta própria, e o trabalho não evapora quando você desliga a máquina. A documentação diz exatamente isso, afirmando sem rodeios que poder rodar coisas em paralelo não é a finalidade do Projects.

2. Mesmo nome, mas não é o Projects antigo

O que confunde é que o chat do claude.ai também tem "Projects". Aquele é um contêiner de conversas e arquivos, sem threads e sem coordenador. O nome idêntico convida à confusão, mas a documentação trata os dois como recursos separados.

3. Quem recebe — como saber se já chegou até você

Em 19 de setembro de 2026, trata-se de um beta público liberado por etapas. As condições estão descritas com algum detalhe, então seguem aqui quase na íntegra.

A segunda condição é a mais fácil de deixar passar. Quanto mais projetos antigos você acumulou do lado do chat, mais tarde o novo Projects chega até você. O blog oficial diz que os projetos existentes continuam funcionando por enquanto e são atualizados conforme a liberação avança. Em outras palavras, não são os usuários intensivos que vão na frente: são as contas que começam do zero.

Se ele não está na sua barra lateral, a sua vez ainda não chegou. Nesse caso, você pode colocar o seu nome na lista de espera. Procurar no lugar certo também importa mais do que parece: ele aparece do lado do Code, na barra lateral de claude.ai/code ou na aba Code do aplicativo de desktop. Por mais que você vasculhe a barra lateral do chat, o que existe ali é o Projects antigo.

4. Ele exige GitHub, e é aqui que muita gente fica de fora

Esta é a restrição que mais dói na prática. O único código que uma thread consegue tocar é código que está no github.com, e o Claude GitHub App precisa estar instalado naquele repositório. A documentação lista as condições assim.

• O código fica no github.com. GitHub Enterprise Server, GitLab e Bitbucket estão fora
• A conta do GitHub conectada tem permissão de push naquele repositório
• O Claude GitHub App está instalado naquele repositório. Um token que você adicionou com /web-setup serve para outras sessões na nuvem, mas não basta para as threads de um projeto
• Em repositórios de uma organização, só um proprietário da organização consegue concluir a instalação (qualquer outra pessoa gera apenas um pedido de aprovação)

Ou seja, o desenvolvedor individual que trabalha a partir de um repositório bare no próprio servidor git ou em uma hospedagem compartilhada está fora do escopo como as coisas estão hoje. O mesmo vale para uma API atrás da VPN da empresa, um banco de dados no seu notebook, um emulador de dispositivo ou um servidor de produção que você alcança por SSH: as threads vivem fora da sua máquina, então não conseguem tocar em nada disso.

Isso quer dizer que não sobra nada para quem não usa GitHub? Não exatamente. Dá para criar um projeto sem nenhum repositório. Subir uma pasta de contratos ou uma exportação de tíquetes de suporte, dar a uma thread uma tarefa como "liste os dez erros de integração que mais aparecem aqui dentro" e pegar o resultado na aba Library é um uso que a documentação prevê explicitamente. Os arquivos que você sobe ficam legíveis a partir de uma thread em /mnt/project-files.

Se o trabalho é código e precisa do seu próprio ambiente, o caminho é rodar sessões locais lado a lado no agent view. Isso roda na sua própria máquina, então a sua VPN, o seu banco local e o seu SSH continuam funcionando.

5. Com o que uma thread começa

Uma thread não parte do zero toda vez. Ela sobe com o contexto que o projeto lhe dá, e são quatro as coisas que ela carrega.

• Os repositórios e arquivos do projeto — todo repositório registrado é clonado a cada vez, encoste a tarefa nele ou não
• Instruções do projeto — um briefing compartilhado que chega a todas as threads. O limite é de 16.000 caracteres
• Memória do projeto — anotações que o Claude escreve para si mesmo. Ele lê o índice MEMORY.md na inicialização e abre os arquivos individuais quando precisa deles
• O ambiente de nuvem — quais destinos de rede são permitidos, variáveis de ambiente, credenciais de API e as ferramentas instaladas de antemão

A parte dessa bagagem com maior chance de causar um acidente é esta: os arquivos de configuração dos repositórios recebem tratamento diferente conforme o projeto tenha um repositório ou vários. Organizando a tabela da documentação, fica assim.

O motivo é simples: permissões, hooks e variáveis de ambiente são lidos exclusivamente do .claude/settings.json que está no diretório em que a thread começou. Com mais de um repositório, a thread começa um nível acima dos clones, então a configuração de nenhum repositório fica em um lugar que seja lido. Acrescentar um único repositório a mais desliga os seus hooks em silêncio, e nada avisa. Para projetos com vários repositórios, a recomendação documentada é colocar as regras compartilhadas nas instruções do projeto e as variáveis de ambiente no ambiente de nuvem.

Sobre MCP, já que estamos aqui: os servidores MCP que uma thread consegue usar são os conectores da sua conta claude.ai. Um servidor MCP instalado só na sua máquina nunca chega até ela. E a conversa do projeto em si não tem conector nenhum, então um trabalho que dependa de um conector precisa ir para uma thread, em vez de ser pedido na conversa.

6. Quanto ele consome a mais em tokens

Esta é a dúvida que a maioria tem antes de ligar o recurso. A documentação é direta: um projeto puxa dos seus limites mais rápido do que uma sessão única, e no Pro em especial você deve esperar bater no limite mais cedo nos dias em que rodar um. O aumento vem de várias coisas que se somam.

O ④ merece atenção especial. Quando a thread de um projeto abre um pull request, ela vigia esse PR com o auto-fix ligado por padrão. Mesmo que você tenha desligado o auto-fix para as suas outras sessões na nuvem, as threads de projeto são tratadas à parte. Ela vai corrigir o CI que falha, responder a comentários de revisão e relatar quando tudo passar e, em troca, continua comendo o seu limite de uso pelo tempo que você a deixar ali. Para interromper isso, peça àquela thread que pare de monitorar o PR.

Então, quanto a mais é? Nenhum multiplicador foi publicado para o Projects em si, mas para as Agent Teams, que partem da mesma ideia de dividir uma tarefa entre várias sessões, a documentação aponta cerca de sete vezes o consumo de uma sessão comum quando os teammates rodam em plan mode. Rodar coisas em paralelo é um jeito de comprar velocidade, não de economizar, e isso os dois têm em comum.

Também vale saber onde estão os freios e o quanto eles seguram.

• Não há teto para quantas threads rodam ao mesmo tempo. Você pode dizer "fique em duas", mas a documentação é explícita: isso é uma instrução que o Claude tenta seguir, não uma configuração que seja imposta. O único limite rígido são 200 threads por dia (somando todos os projetos)
• Uma thread que bate no seu limite de uso espera sozinha e retoma automaticamente quando o limite é reiniciado. Deixe-a em paz e ela começará a gastar a próxima janela sem pedir licença (para impedir isso, aperte Stop na thread ou pause o projeto). A exceção é uma thread iniciada por uma rotina, que dá erro em vez de esperar
• As máquinas virtuais na nuvem em si não custam nada a mais. Os tokens são a única coisa que sobe
• Um projeto parado — sem threads rodando, sem PRs sendo vigiados, sem mensagens novas — não consome nada da sua cota

7. Como escolher entre as cinco formas de trabalhar em paralelo

O Claude Code tem hoje cinco formas de fazer trabalho em paralelo. O Projects é uma delas, e o que o separa das demais é quem distribui o trabalho e onde ele roda. Reorganizando a comparação da documentação em torno de como você realmente escolheria, fica assim.

Traçar a linha para a sua própria situação se resume a mais ou menos duas perguntas. O trabalho precisa do seu próprio ambiente (um banco local, uma VPN, SSH)? Se precisa, o Projects não é opção. O trabalho vai terminar hoje? Se vai, levá-lo para a nuvem rende pouco e o agent view basta. Para a diferença entre subagents e Agent Teams, há um artigo separado que compara os dois em detalhe.

8. O que fazer antes de mandar o primeiro lote

A documentação lista quatro coisas a fazer "antes do seu primeiro lote", e cada uma delas sai caro se for corrigida depois.

1. Escreva as instruções do projeto — de qual branch partir, o que rodar antes de dar algo por concluído, o que precisa da sua aprovação antes. O exemplo oficial manda a thread dizer exatamente o que ela não consegue alcançar já na primeira mensagem e parar por ali, em vez de substituir, simular ou adivinhar.
2. Mande exatamente um trabalho de verdade e depois abra e leia — veja como ela relata e o que de fato deixou no branch
3. Revise o modelo e o nível de esforço — deixar o padrão Opus em high é a maneira mais rápida de torrar o seu limite
4. Diga "proponha antes de começar" e "fique em poucas threads de cada vez" — abandone isso quando algumas rodadas voltarem do jeito que você espera

Mais uma, menos glamourosa, mas que vale conhecer. O sandbox de uma thread pausa entre os turnos e retoma no seguinte. Se não conseguir retomar, o trabalho recomeça a partir de um clone novo, o que significa que alterações não commitadas podem se perder. Em trabalhos mais longos, a recomendação documentada é pedir à thread que faça commit e push conforme avança.

Resumo

O novo Projects não é "um recurso que deixa você rodar coisas em paralelo", e sim "um recurso que tira das suas mãos o trabalho de rodar coisas em paralelo". A distribuição, a cobrança e a reexplicação do mesmo contexto toda vez simplesmente desaparecem. Se você tem trabalho que se arrasta por dias, ele vive no github.com e você está no Pro ou no Max, as chances de ser uma boa combinação são altas.

Por outro lado, ele se encaixa mal em trabalho que precisa do seu próprio ambiente, no seu servidor git particular e em tarefas avulsas que terminam hoje. E o que vale em todos os casos é que o paralelismo compra velocidade gastando tokens. O padrão é Opus em high, não há teto imposto para quantas threads rodam ao mesmo tempo e as threads que vigiam um PR acordam sozinhas. Rode um projeto por um dia sem conhecer essas três coisas e a queda na sua cota vai surpreender. Baixe as configurações primeiro, mantenha o número de threads pequeno e sinta o gosto em uma ida e volta antes de abrir o leque. Esse é o caminho mais seguro para entrar.

Se quiser transformar a pesquisa de um projeto numa proposta ou num procedimento que possa consultar depois, veja nosso guia do Claude Docs. Use Projects para o trabalho contínuo e Docs para criar e editar documentos, conforme o que precisa realizar.

FAQ

P. O que acontece com os projetos que eu já tenho no chat?

R. Eles continuam funcionando como estão, por enquanto. O blog oficial diz que os projetos existentes de Pro e Max seguem utilizáveis e que serão atualizados conforme a liberação avançar para o chat e o Cowork. Note, porém, que o novo Projects está chegando primeiro às contas sem projetos existentes, então quanto mais você acumulou, mais tarde vem a sua vez.

P. Dá para usar pelo Claude Code no terminal?

R. Não. Os três lugares em que ele funciona são claude.ai/code, a aba Code do aplicativo de desktop e o aplicativo de celular. O acesso pelo Amazon Bedrock, pela Agent Platform do Google Cloud ou pelo Microsoft Foundry também está fora do escopo. O comando claude project da CLI, a propósito, é outro recurso que por acaso divide o nome.

P. Eu não uso GitHub. Quais são as minhas opções?

R. Para efetivamente executar código, há duas por ora. Colocar o repositório no github.com e instalar o Claude GitHub App, ou usar o agent view, que roda na sua própria máquina. Dito isso, um projeto sem repositório pode ser criado sem GitHub nenhum: suba o seu material, peça às threads que pesquisem ou redijam a partir dele e recolha os resultados na aba Library.

P. É realista no plano Pro?

R. Sim, mas baixe as configurações antes de começar. A própria documentação avisa que no Pro em especial você deve esperar bater no limite mais cedo nos dias em que rodar um projeto. Um projeto novo vem com as threads no Opus em high, então baixe isso primeiro, mantenha pequeno o número de threads rodando ao mesmo tempo e abra o leque acompanhando o que você realmente gasta nas configurações de Usage do projeto.