Testei o Projects do Claude Code: pontos fortes e armadilhas das threads em paralelo ao mandá-lo construir um site inteiro

O Projects do Claude Code é um recurso em que, dentro de uma única conversa, o Claude divide o trabalho em threads e as executa em paralelo na nuvem. Como ele funciona e quem pode usá-lo eu organizei em O que é o Projects do Claude Code. Este artigo é a continuação: o registro de quando mandei ele construir um site inteiro de verdade.

Testei de 26 a 28 de setembro de 2026, quando o Projects ainda estava em beta público (sendo liberado aos poucos para Pro e Max; veja a documentação oficial). As telas e o comportamento podem mudar. O que está aqui é o que realmente aconteceu naquele momento, com números que conferi nas telas, no relatório de uso e no histórico do repositório.

Resumindo em uma frase: o desenvolvimento avança surpreendentemente bem mesmo sem supervisão, mas o que sai é um rascunho, não um produto acabado, e a publicação num servidor que só aceita SSH trava. A seguir conto o que foi bom e o que foi ruim, na ordem em que aconteceu.

1. O que mandei construir: as condições e uma confissão logo de cara

O tema foi um site de banco de dados para consultar quanta memória os LLMs locais exigem. Para responder "este modelo roda no meu PC?", ele coleta do Hugging Face o tamanho dos arquivos quantizados, calcula a memória necessária para cada tamanho de contexto e permite a busca inversa a partir da memória da sua GPU ou do seu Mac. Não é pequeno demais e se divide naturalmente em partes que podem andar em paralelo (coleta de dados, cálculo, páginas, busca inversa, SEO), por isso servia bem como banco de testes para o Projects.

2. Como começar e os cinco pontos em que tropecei

Os passos em si são curtos: na aba Code do app para desktop, escolha Projects → New, preencha nome, objetivo e repositório e crie. Em volta desses passos, porém, tropecei nestes cinco pontos.

Sobre o ②: logo depois da criação, a conversa mostrou o aviso "Up to $100 of initial usage, including the automatic setup, won't count towards your usage limits". Ou seja, os primeiros US$ 100 de uso não contam para a sua cota normal, e a tela de uso também mostrou isso como um "crédito de configuração do projeto" (cerca de 24 horas até expirar). Em 28 de setembro, esse benefício não aparecia na página do Projects na documentação oficial. Na seção 6 mostro como ele foi sendo consumido na prática.

Onde me perdi nas configurações de ambiente foi ao editar um ambiente que já existia. Entrando por "Add cloud environment" (adicionar ambiente), abre-se a tela de um ambiente novo, e no começo eu digitei os domínios permitidos no campo do script de configuração. Para editar um ambiente existente, passe o mouse sobre ele na lista e clique na engrenagem que aparece (é exatamente o que a documentação oficial diz, mas é difícil descobrir só olhando a tela).

3. Cerca de 20 horas registradas: o que aconteceu enquanto eu dormia

Este é o fluxo desde a criação (por volta das 22h de 26 de setembro) até o merge do último PR (por volta das 17h30 do dia seguinte, 27). Todos os horários estão no horário do Japão (JST).

Vale registrar também algo que não foi bom. Ao montar a base da coleta de dados, uma thread acessou a API do Hugging Face 520 vezes seguidas para entender como funcionava o limite de requisições do serviço externo. A thread de revisão julgou isso "não razoável" e escreveu regras para o uso de APIs externas, e a thread de coleta de dados que veio depois fez só 8 acessos no trabalho inteiro. Sozinho, ele não se preocupa com a carga que coloca em serviços externos, então vale deixar isso escrito nas instruções.

4. Aprovar cada passo ou deixar por conta dele

Como contei na seção 1, a primeira metade rodou com instruções que colocavam a aprovação humana em cada passo, e às 17h do dia 27 eu as reescrevi para deixar por conta dele. O comportamento mudou claramente.

Houve duas coisas a observar ao deixar por conta dele. A primeira: instruções reescritas não chegam às threads que já estão rodando. O próprio coordenador explicou: "Esta thread começou antes de as instruções serem reescritas, então ela não enxerga as novas instruções". A segunda: as threads não conseguiram apagar regras antigas que tinham ficado na memória do projeto. Uma tarefa que tentou reescrever uma nota antiga dizendo "só um humano faz merge" foi barrada por uma verificação de segurança. Notas antigas precisam ser apagadas por um humano em Settings → Memory (memória).

O esqueleto das instruções em que acabei chegando foi este.

Este projeto constrói e mantém [o seu site].
O modo de trabalhar fica a seu critério: o coordenador pode decidir quais threads abrir, quantas, com quais modelos e em que ordem.
Você pode fazer merge de PRs quando o CI passar. Resolva os conflitos sozinho.

Pergunte a um humano apenas sobre:
- Qualquer coisa que custe dinheiro (APIs pagas, serviços pagos)
- Quando precisar de segredos (chaves de API, senhas)
- Deploy em produção ou alteração de dados de produção
- Decisões em que os caminhos divergem e qualquer um deles faria sentido
- Quando não conseguir alcançar algo de que precisa (não preencha com palpites nem dados fictícios)

Respeite os limites de requisições das APIs externas e não as acesse em massa para investigar.

Dito isso, considerando o que descobri depois, recomendo acrescentar "mudanças na configuração do CI e nos scripts de deploy precisam de aprovação humana". Threads com carta branca também conseguem mudar a configuração do CI, e, combinado com um mecanismo de deploy, isso abre um caminho para que mudanças cheguem à produção sem que ninguém confira (seção 7).

5. A qualidade que descobri depois de publicar: todos os testes tinham passado

Peguei o que o projeto construiu, passei para o meu Claude Code local de sempre e publiquei em produção. A primeira impressão logo depois de publicar foi "é meio... comum". Não havia uma única página de modelo. Investigando a causa, apareceu um buraco típico do desenvolvimento em paralelo.

Dez threads, mais de cem testes, revisões com Opus e o CI: nada disso pegou essa falha, porque cada thread estava correta dentro da sua própria responsabilidade. Sem um papel que olhe o conjunto de ponta a ponta, abrem-se buracos nas fronteiras da divisão de tarefas.

Ao colocar dados reais, apareceram mais dois problemas.

• A tabela de quantizações misturava arquivos que não eram o modelo principal. Modelos auxiliares para decodificação especulativa (MTP, EAGLE etc.) e arquivos de LoRA estavam sendo contados como quantizações do modelo principal, e a tabela de um modelo de 12B começava com uma linha "Q8_0 0.47GB" (o Q8_0 de verdade tem 12,7 GB). Depois da correção, 195 arquivos em 56 repositórios passaram a ser tratados como auxiliares.
• Nos modelos mais novos e mais procurados, a memória necessária aparecia como "não calculável". A fórmula da época não suportava arquiteturas de nova geração (como aquelas em que cada camada guarda a memória de um jeito diferente). O principal atrativo do site não aparecia justamente nas páginas mais visitadas.

Os dois só vieram à tona quando dados reais entraram em produção, porque os testes tinham sido montados apenas com dados de exemplo. Veja o que corrigi com o Claude Code local e quanto tempo levou (de 17h21 a 22h54 de 28 de setembro, 13 commits).

Por outro lado, também houve pontos claramente bons. As páginas eram rápidas (cerca de 0,1 segundo nas principais), os tamanhos de arquivo eram os valores reais do Hugging Face, e a memória necessária dos modelos suportados batia com a fórmula. O trabalho de SEO, como títulos, dados estruturados, sitemap e llms.txt, já vinha incluído desde o início. Meu veredito geral: o esqueleto e os detalhes eram bem feitos; o que faltava eram as "juntas" entre as partes e os dados reais.

6. Uso e custo: para onde foram 191,8 milhões de tokens

A tela Usage (uso), nas configurações do projeto, mostra os tokens por thread e por modelo. Um botão no canto superior direito copia tudo como texto. O relatório das 11h47 de 27 de setembro estava assim.

190 milhões parece muito, mas 97,7% disso foram leituras de cache. A cada ação, a thread relê a conversa até ali, então, quando uma thread executa centenas de ações, o resultado tem esse formato. O acréscimo do coordenador foi de só 2%, ou seja, o custo de gerenciamento foi pequeno.

Para comparar, calculei "tokens lidos ÷ tokens gerados" e pus lado a lado com o Claude Code local (os últimos três dias no meu PC): cerca de 330 no projeto e cerca de 340 no local. O consumo por volume de trabalho foi praticamente o mesmo de uma sessão local. O Projects parece mais pesado provavelmente porque tudo roda em paralelo de uma vez, e a cota cai concentrada num curto espaço de tempo (o trabalho em si era diferente, então trate isto como uma comparação aproximada).

Do lado do custo, consegui acompanhar como o crédito de configuração (US$ 100) foi sendo consumido.

Esse crédito se comportou de forma parecida com um valor em dólares contado pelos preços da API. Calculando o relatório das 11h47 pelos preços oficiais da Anthropic (Pricing: Sonnet 5 a US$ 2 de entrada, US$ 10 de saída e US$ 0,20 de leitura de cache; Opus 5.5 a US$ 4 de entrada, US$ 20 de saída e US$ 0,20 de leitura de cache, todos por milhão de tokens), dá cerca de US$ 58 a 65, o que bate razoavelmente com o que a tela mostrava naquele momento (78% = US$ 78). Ou seja, "US$ 100" significa o volume que custaria US$ 100 se você pagasse pela API, o que não é tanto assim dentro de um plano Max de preço fixo. Aliás, um outro crédito distribuído para sessões na nuvem (US$ 250 no Max) dizia na tela de resgate que "Projects não são elegíveis", e de fato não foi consumido nem um dólar dele.

7. Por que a publicação em produção travou

A parte mais difícil foi colocar o que tinha sido construído em produção, porque o destino era uma hospedagem compartilhada acessível só por SSH.

• As threads da nuvem não alcançam o servidor de produção (a chave SSH só existe no meu PC).
• Para rodar no PC local, usa-se a opção "Work locally" (trabalhar localmente) do projeto. Por baixo, é o Remote Control, e é preciso ativar "Use this computer from your phone and claude.ai" (usar este computador pelo celular e pelo claude.ai) no app para desktop.
• Só que essa configuração vale para a lista de todas as pastas que você já abriu no Claude Code, reunida automaticamente. No meu ambiente eram 22, e uma delas era uma pasta-mãe com dezenas de projetos dentro. Enquanto ela estiver ativada, todas passam a ser lugares onde dá para iniciar trabalho remotamente, e os nomes das pastas, os caminhos e as URLs dos repositórios também são enviados à Anthropic. Para limitar a uma única pasta, é preciso usar outro caminho: abrir um terminal nessa pasta e rodar claude remote-control.

Por isso, avaliei algumas formas de publicar.

No fim, arquivei o projeto e levei o que ele construiu para o meu fluxo de sempre com o Claude Code local. Julguei mais seguro colocá-lo no mesmo esquema de publicação dos meus outros sites do que acrescentar um mecanismo novo.

Olhando para trás, parece melhor pensar no Projects como algo feito para combinar com uma hospedagem que publica automaticamente quando você faz merge no GitHub. Com a Vercel, por exemplo, basta conectá-la ao GitHub para que as mudanças cheguem até a produção, e o beco sem saída em que caí não aconteceria. Porém, o plano gratuito Hobby da Vercel é limitado a uso não comercial, e exibir anúncios como os do Google AdSense exige o Pro, que é pago (a partir de US$ 20 por mês) (Fair Use Guidelines). Ela também não combina bem com um site em PHP e MySQL como este. O importante é decidir a tecnologia e o destino da publicação juntos, logo no início.

Os riscos de deixar o seu próprio PC ser operado remotamente, e como isso difere do Claude Code do dia a dia, pretendo detalhar num artigo separado. O uso da sessão local pelo celular está no artigo sobre o Remote Control.

8. Para que tipo de trabalho serve e para qual não serve

Com base nesta experiência, reuni o que eu conferiria antes de começar.

• Destino da publicação: fazer merge no GitHub publica automaticamente? Se precisar de SSH, decida antes algo como o servidor ir buscar as mudanças.
• Permissões no GitHub: o alcance da instalação do Claude GitHub App. Use uma conta dedicada ou restrinja os repositórios.
• O quanto deixar por conta dele: nas instruções do projeto, escreva só o que deve ser perguntado a um humano. Faça mudanças nas configurações de CI e de deploy dependerem de aprovação.
• Rede: se for usar APIs ou sites externos, coloque na lista de permissões tanto o domínio principal quanto os subdomínios.
• Verificação com dados reais: não relaxe só porque os testes com dados de exemplo passaram. No final, abra uma thread cujo papel seja passar dados iguais aos de produção de ponta a ponta e olhar o resultado.
• Cota de uso: revise o modelo padrão das threads. Nas primeiras 24 horas, há um crédito de configuração de US$ 100.

Resumo

O Projects é um recurso que realmente tira do humano o trabalho de distribuir tarefas, acompanhá-las e explicar de novo o mesmo contexto. Durante a noite, três tarefas avançaram em paralelo, as threads se coordenaram entre si e, com carta branca, ele decidiu sozinho até os merges e o próximo trabalho. Os tokens por volume de trabalho também não foram diferentes dos do Claude Code local.

Por outro lado, o que sai é um rascunho. Ao dividir o trabalho em paralelo, abrem-se buracos nas fronteiras entre as responsabilidades. Todos os testes com dados de exemplo podem passar e, ainda assim, os dados reais revelam bugs. E ele não combina com servidores que só aceitam SSH. Se for usar, três cuidados devem evitar os desvios que eu fiz: escolher um destino de publicação integrado ao GitHub, escrever logo no início o quanto deixar por conta dele e, no final, abrir uma thread cujo papel seja conferir tudo de ponta a ponta com dados reais.

FAQ

P. Quanto custa o Projects?

R. Não há cobrança à parte; ele consome a cota normal do Pro ou do Max. Além disso, desta vez veio um "crédito de configuração" pelo qual até US$ 100 de uso nas primeiras 24 horas, mais ou menos, não contavam para a cota (mostrado na tela; em 28 de setembro, não constava na documentação oficial). O trabalho, com 10 threads e 11 PRs, usou cerca de 190 milhões de tokens e esgotou esse crédito. Pelos preços da API, isso equivale a cerca de US$ 100.

P. Ele continua mesmo se eu fechar o PC?

R. Sim. As threads que rodam na nuvem continuaram avançando com o PC fechado ou em suspensão. Neste teste, três tarefas terminaram durante cerca de 7 horas da noite. Já as threads abertas no seu próprio PC com o "Work locally" só rodam enquanto o PC estiver acordado.

P. Dá para usar com repositórios fora do GitHub?

R. As threads que mexem com código pressupõem um repositório do github.com com o Claude GitHub App instalado. Eu gerenciava este projeto no meu próprio servidor git, então criei uma conta do GitHub só para o Claude, comecei por lá e, no final, trouxe tudo de volta para o meu ambiente local.

P. O que acontece se eu mudar as instruções do projeto no meio do caminho?

R. O coordenador as recebe na hora, e o modo de trabalhar dele mudou sem que eu precisasse dizer nada. Elas não chegam às threads que já estão rodando, então, se necessário, mande continuar o trabalho numa thread nova. As regras antigas que ficaram na memória do projeto tiveram de ser apagadas por um humano nas configurações.

P. O "Work locally" é seguro?

R. A comunicação é só uma conexão criptografada que sai do seu PC; nenhuma porta de entrada é aberta. Porém, ao ativar a configuração no app para desktop, a lista de pastas reunida a partir do seu histórico de uso (22 no meu caso, incluindo dezenas de projetos dentro de uma pasta-mãe) passa a ser um conjunto de lugares onde dá para iniciar trabalho remotamente. É preciso adotar práticas como ativá-la só enquanto estiver usando e confirmar que a conta com que você faz login tem autenticação em duas etapas.

P. Dá para usar o que ele constrói do jeito que sai?

R. No meu caso, não. O esqueleto e o trabalho de SEO estavam bem feitos, mas a lógica nas fronteiras entre as responsabilidades faltava por completo, e havia bugs que só apareceram com dados reais. Antes de publicar, é preciso uma etapa que coloque dados reais e confira o conjunto de ponta a ponta.