Projetos do Claude Code explicados: fechei o notebook e ele continuou trabalhando

Autoria: Hyperautomation Labs · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Claude Code Projects Explained: I Closed My Laptop and It Kept Working · Canal: Hyperautomation Labs · 14:37 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Cibersegurança e segurança de software, Claude Code

Resumo

O vídeo explica como Projects permite coordenar várias tarefas em paralelo, cada uma em seu próprio thread, branch e computador na nuvem. Em uma demonstração com uma loja virtual, o apresentador delega cinco problemas, fecha o notebook e depois revisa os resultados e os custos. Ele destaca regras de segurança para evitar merges prematuros, perda de trabalho e decisões inventadas. Também mostra opções de execução local, formas de migrar sessões existentes e quando vale a pena usar Projects.

Pontos-chave

Em Projects, um Claude coordenador divide pedidos em threads independentes, cada um com seu próprio ambiente de trabalho.
Os threads podem rodar na nuvem mesmo com o notebook fechado, e entregam as mudanças em pull requests para revisão.
Projects é voltado a várias tarefas separadas; subagents ajudam a pesquisar em paralelo dentro de um único trabalho.
Instruções explícitas podem impedir merges automáticos, exigir resultados de testes e mandar o Claude parar quando faltar informação.
Na demonstração, cinco threads consumiram quase 10 milhões de tokens, mas 96% do uso foi de leituras em cache.
O apresentador recomenda revisar configurações de uso, como Opus padrão e continuação automática após o limite.
Threads também podem rodar localmente, mas só enquanto o computador estiver ligado e não recebem o arquivo de memória do projeto.
Projects pode ser útil para três ou mais tarefas separadas com código no GitHub; uma correção rápida pode ser mais adequada a uma sessão na nuvem.

Capítulos

Início	Capítulo	Resumo
00:00	O problema de coordenar várias tarefas	O apresentador compara chats separados a mesas de trabalho que exigem coordenação manual e explica a ideia de Projects.
03:07	Projects, subagents e configuração	Ele diferencia Projects de subagents e mostra como criar um projeto, conectar o código e definir instruções e configurações.
05:48	Demonstração com cinco tarefas	O coordenador distribui cinco problemas da loja virtual, os threads trabalham em paralelo e o apresentador revisa os resultados.
08:55	Custos e limites de uso	O vídeo detalha o consumo de tokens, os fatores que aumentam os custos e as opções para limitar a execução.
11:00	Riscos e regras de segurança	O apresentador descreve problemas com merges e perda de trabalho e recomenda instruções para manter a revisão sob controle.
13:03	Migração e quando usar Projects	Ele aborda mudanças de nome, migração de sessões, critérios para escolher Projects e materiais complementares.

Citações

Você virou o gerente, e só consegue ficar em uma mesa por vez. — 01:34

O gerente só lê o que cada trabalhador relata, não cada etapa que ele executou. — 02:36

Ele não inventou uma resposta. — 07:51

A solução não é evitar isso. É dar regras antes de você se afastar. — 11:32

Conceitos e entidades

Projects (ferramenta): Recurso apresentado para coordenar várias tarefas de programação em threads separados e acompanhar seu andamento.
Claude Code (ferramenta): Ferramenta de programação da Anthropic mencionada no contexto de Projects e de execução de tarefas.
Anthropic (empresa): Empresa responsável pelo recurso Projects apresentado no vídeo.
Opus (modelo): Modelo usado nos threads, segundo as configurações mostradas pelo apresentador.
subagents (conceito): Ajudantes que pesquisam em paralelo dentro de uma sessão e devolvem resultados ao trabalho principal.
pull request (conceito): Pacote de mudanças que o thread entrega para que uma pessoa revise e aceite.
GitHub (ferramenta): Plataforma na qual o código e as mudanças do projeto são hospedados.

Tradução completa (pt-BR)

00:00 Você tem cinco coisas para corrigir no seu app. Então, abre o Claude e depois um segundo chat porque o primeiro está cheio. Depois, um terceiro. Agora, você fica copiando notas entre abas e não pode fechar o laptop porque, no instante em que fizer isso, tudo para. A Anthropic acabou de lançar a solução. Você digita os cinco trabalhos em uma única mensagem bagunçada. Claude os divide e executa todos ao mesmo tempo nos próprios computadores, mesmo depois que você fecha o laptop. O vídeo deles

00:31 sobre isso foi assistido mais de 170 mil vezes. O comentário mais curtido diz: “Não entendi uma única coisa.” Então, vou explicar em linguagem simples. Depois, vou dar a ele um app de verdade, com bugs de verdade. Vou fechar o laptop, sair por 30 minutos e mostrar tudo o que estava esperando quando eu voltar. E quanto custou. Veja por que o jeito antigo não funciona. Um chat com Claude é como uma mesa.

01:02 Cada trabalho que você passa para ele empilha mais papéis nessa mesa. Arquivos que ele leu, erros que encontrou, coisas que tentou. A mesa tem um limite de tamanho. Quando fica cheia, Claude organiza tudo fazendo um resumo, e os detalhes acabam caindo pela borda. É por isso que, depois de um tempo, um chat longo começa a esquecer o que você contou uma hora atrás. Então, você faz o que parece sensato e abre mais chats, um para cada trabalho. Agora, todas as mesas estão limpas, mas alguém precisa circular entre elas,

01:34 levar notas de uma para outra, lembrar qual estava esperando uma resposta e manter o laptop aberto para que nenhuma pare. Esse alguém é você. Você virou o gerente e só consegue ficar em uma mesa por vez. Projects não dá uma mesa maior para Claude. Dá a Claude um gerente. Um projeto é uma conversa longa. Você conversa com um único Claude, o coordenador. Pense nele como o gerente.

02:05 Você diz o que precisa ser feito com suas próprias palavras, do jeito bagunçado que quiser. Para cada trabalho de verdade, o gerente inicia uma thread. Uma thread é um trabalhador com a própria mesa. Assim, os papéis dele nunca se misturam com os de ninguém. Ele recebe a própria cópia do seu código, em sua própria branch. E, na nuvem, recebe o próprio computador. Quando termina, entrega um pull request. Um pacote organizado de alterações que você pode ler e aceitar. Aqui está a parte inteligente.

02:36 O gerente só lê o que cada trabalhador relata, não cada etapa que ele executou. Assim, a mesa do gerente nunca fica cheia. Você pode manter essa conversa por semanas. Todos também compartilham uma prateleira. Suas instruções, que cada nova thread recebe; um arquivo de memória em que Claude anota coisas; e uma biblioteca de arquivos que você envia. E você não fica mais lendo chats: lê um quadro. As threads passam por essas colunas por conta própria.

03:07 A única coluna que precisa de você é “aguardando você”. As threads são executadas em computadores da Anthropic, então você pode fechar o laptop e conferir o quadro pelo celular. Essa é a ideia toda. Mas existe um jeito de isso dar muito errado. E vou mostrar exatamente como isso aconteceu com alguém e as cinco linhas que evitam o problema. A pergunta mais feita nos comentários do vídeo da Anthropic é: “Qual é a diferença entre isso e subagents?” Aqui está tudo em forma de escada. Uma pergunta rápida. Um chat normal.

03:39 Um trabalho, como corrigir um bug. Uma sessão na nuvem. Um trabalhador, uma branch, um pull request. Um trabalho que exige fazer pesquisa em paralelo. Isso são subagents. Pequenos ajudantes dentro de uma sessão que pesquisam coisas, relatam o que encontraram e desaparecem. Vários trabalhos separados, executados ao longo de dias, cada um merecendo seu próprio pull request. Isso é um projeto. Eles também se combinam. Uma thread dentro de um projeto pode usar seus

04:11 próprios subagents. E, se você se lembra dos antigos projetos do Claude, uma pasta de arquivos mais alguns chats, isto é diferente. O antigo armazenava coisas. O novo executa coisas. Faça uma captura de tela dessa escada ou envie para quem perguntou o que são projects. Veja como configurar na minha conta. Primeiro, procure projects na barra lateral do Claude code na web. Está em beta para os planos Pro e Max, mas ainda não para Team ou Enterprise.

04:43 A Anthropic liberou o acesso para todo mundo da lista de espera em 9 de outubro. Então, se você entrar antes disso, confira agora. Segundo, crie um projeto. Dê um nome e um objetivo. O meu é deixar a loja rápida e o checkout confiável. Depois, adicione o código. Estou usando uma pequena loja de demonstração que configurei com problemas de propósito, para que você veja números reais de antes e depois. Terceiro, projects precisa que o app do Claude para GitHub esteja instalado nesse código. Uma sessão normal do Claude não precisa, então essa etapa pega as pessoas de surpresa. Quarto: instruções.

05:16 Esta é a parte que ninguém mostra, e é a mais importante. Dei a ele cinco linhas. Vou explicar por que cada uma está ali mais adiante, na parte em que isso dá errado. Quinto, confira as configurações antes da primeira mensagem. Cada thread executa Opus, o maior modelo do Claude, com esforço médio, e o gerente executa Opus com esforço baixo. E veja esta opção: continuar automaticamente quando os limites de uso forem redefinidos. Ela vem ativada por padrão.

05:48 Então, uma thread que fica sem uso retoma na sua próxima janela. Vou voltar a isso quando analisarmos a conta. São dez para as onze da noite. Estou digitando como uma pessoa cansada, não escrevendo uma especificação. Ninguém clica no botão “comprar pro”. O carregamento da primeira página leva 3 segundos. Um cliente foi cobrado duas vezes. Precisamos de uma página de devoluções, e o checkout mal tem testes. Primeiro, proponha as threads e espere minha autorização. Em cerca de 10 segundos, o coordenador volta

06:19 com cinco threads, cada uma com um pull request em rascunho, exatamente como minhas instruções diziam. Então, ele percebeu algo que eu não tinha percebido. Tanto a correção da cobrança duplicada quanto os testes do checkout mexem no mesmo código. Então, ele começa pela correção e faz os testes serem construídos em cima dela. Isso é atitude de gerente. Eu digito “pode”. Os cartões das threads aparecem direto na conversa. Cada uma é um trabalhador separado, no próprio computador. Quatro threads começam a trabalhar ao mesmo tempo, e

06:51 a quinta espera sua vez. Agora, a parte que antes era impossível. Fecho o laptop e vou embora. Enquanto isso está sendo executado, se esta é a primeira vez que projects fez sentido de verdade para você, é isso que este canal faz. Inscreva-se, e vamos ver o que está esperando. Trinta minutos depois, abro o quadro. Três estão prontas para revisão. Duas estão esperando por mim, e ambas dizem que estão bloqueadas. Ótimo. Vou explicar por que isso é bom em um

07:21 segundo. A primeira página lenta. Ele encontrou um loop que executava 28 milhões de etapas toda vez que a loja iniciava, construindo um índice de busca que ninguém jamais consulta. Ele o apagou. A primeira página passou de 3 segundos para seis milésimos de segundo. Ele mesmo mediu isso. E adicionou um teste que falha se a página voltar a ficar lenta. E então aconteceu isto: o código só tem um ponto seguro. Então, ele disse que não conseguia me dizer qual alteração causou a lentidão. Não inventou

07:51 nada. Como no caso da cobrança duplicada. Primeiro, ele escreveu um teste que reproduz o bug. Um cliente, duas cobranças. Depois, corrigiu o problema com uma chave de uso único. Assim, uma nova tentativa não pode cobrar duas vezes. O teste passa. Agora, as duas que estavam bloqueadas. A página de devoluções. Ele procurou em todos os lugares pela nossa política de reembolso. Não encontrou nenhuma e parou. Ainda não alterei nenhum código. Ele se recusou a inventar uma política de reembolso para uma loja de verdade.

08:23 Essa é a quarta linha das minhas instruções em ação. Dei a política a ele e, dois minutos depois, a página estava pronta. O botão “comprar pro” tinha dois problemas. Parecia uma nota de rodapé, então ele corrigiu isso. E não levava a lugar nenhum porque não existe uma página de checkout. Ele me perguntou o que fazer e avisou que ligá-lo diretamente ao checkout cobraria das pessoas na hora, enquanto o bug da cobrança duplicada ainda está ativo. Eu disse para deixar o link como está por enquanto. Cinco pull requests, nada esperando por

08:55 mim. Para aceitar um, você diz àquela thread: “faça o merge”, e observa o que ela responde. Ela fez o merge porque pedi pessoalmente. Mas a regra de nunca fazer merge continua valendo para todas as outras threads. Agora, a pergunta que aparece em todo comentário: quanto isso custou? As configurações do projeto têm uma página de uso. Cinco threads, quase 10 milhões de tokens. Isso parece assustador.

09:26 Mas veja o detalhamento. 96% são leituras de cache. Claude relendo arquivos que já tinha, que é o tipo mais barato. O conteúdo novo escrito foi de cerca de 33 mil tokens. O gerente ficou com 16%. E a maior thread foi a do primeiro carregamento lento, porque voltei e também pedi para fazer o merge. A segunda foi a página de devoluções. Aquela que parou e ficou esperando por mim.

09:57 Quatro coisas fazem isso ficar caro. Cada thread usa Opus, o maior modelo, por padrão. Uma thread que está acompanhando um pull request acorda e volta a trabalhar quando um teste falha ou alguém comenta. Se você atingir seu limite, a opção de continuar automaticamente faz as threads retomarem na sua próxima janela. Então, desative-a se quiser uma parada definitiva. E, se voltar a uma thread que ficou inativa por mais de uma hora, Claude relê a conversa inteira.

10:30 Comece uma thread nova. Além disso, se você resgatar o crédito gratuito de cloud da Anthropic em setembro, ele não cobre projetos. Ele serve apenas para sessões comuns na cloud. E expira em 4 de novembro. Aqui está a receita mais barata para trabalhos maiores. Veja como isso pode dar muito errado. Um desenvolvedor executou um projeto para criar um servidor e publicou isto no GitHub.

11:00 As threads mesclaram pull requests enquanto os testes ainda estavam falhando. Uma foi mesclada cerca de 4 segundos depois de deixar de ser um rascunho. Foi preciso desfazer quatro alterações mescladas. E eles reiniciaram o plano inteiro. Mais duas armadilhas. O computador na cloud pausa entre as etapas. E, se não conseguir retomar, o trabalho que não foi salvo no GitHub pode se perder. E dizer a ele para executar no máximo duas threads é uma preferência que ele memoriza, não um limite rígido. É por isso que existem minhas cinco linhas.

11:32 Nunca faça o merge, para que seja você quem aceita as alterações. Cole os resultados dos testes, para que as falhas fiquem visíveis. Envie o trabalho conforme avança, para que o computador pausado não perca nada. Pare e diga o que está faltando em vez de fingir que fez, e deixe as verificações de segurança ativadas. A mesma pessoa disse: “Funciona muito bem para tarefas isoladas de investigação e correção.” A solução não é evitar isso. É definir regras antes de se afastar. Muita gente acha que isso é só na cloud

12:02 Não é. Desde 23 de setembro, uma thread pode ser executada no seu próprio computador. No menu de adição, escolha trabalhar localmente e depois permita o acesso à pasta. Você precisa do Cloud Code versão 2.1.280 ou mais recente. E, nos aplicativos para desktop, ative a opção de usar este computador pelo celular. Ative o worktree, para que duas threads locais não sobrescrevam os arquivos uma da outra. As desvantagens: as threads locais só funcionam enquanto o computador está ligado,

12:33 e recebem suas instruções, mas não o arquivo de memória do projeto. Use-as para arquivos privados ou sistemas da empresa. Use a cloud para tudo que você quiser que seja feito enquanto estiver fora. O segundo comentário com mais curtidas pergunta como transformar conversas existentes em um projeto. Em uma sessão na cloud, abra o menu e escolha continuar como projeto, o que mantém essa sessão em andamento, ou mover para o projeto, para adicioná-la a um projeto que você já tem.

13:03 Alguns usuários estão tendo os projetos antigos do Cloud movidos para a nova versão. Você recebe um e-mail primeiro, e nada é apagado. E, novidade desta semana, as rotinas agora se chamam tarefas agendadas. É o mesmo recurso, com um novo nome, então não procure a aba antiga. Use um projeto quando tiver três ou mais tarefas separadas. Seu código está no GitHub e você quer se afastar. Para uma correção rápida, não precisa. Uma sessão na cloud é mais barata. Tenha cuidado no plano Pro, porque a documentação diz que você atingirá seu limite mais cedo.

13:35 E, por enquanto, cada projeto é para uma pessoa, então ainda não é para equipes. Falando sério: 90% de vocês que estão assistindo não se inscreveram. No YouTube, clique em “Seja membro” e torne-se membro. No Facebook, clique em “Assinar”, o botão de apoiador. É isso que mantém as luzes acesas por aqui. E, se uma assinatura paga não for para você, inscrever-se gratuitamente no YouTube ainda informa ao algoritmo que deve mostrar mais conteúdo nosso. Inscreva-se para nos apoiar. Coloquei tudo em um kit inicial de projeto gratuito

14:06 As instruções de cinco linhas, a receita de configurações econômicas, a escada, minhas cinco mensagens confusas e como transferir trabalhos existentes. Comente “conductor” e meu bot enviará o material para você. E me conte nos comentários: qual seria a primeira tarefa que você confiaria a um projeto antes de se afastar? Se quiser o guia completo, o meu guia completo do Cloud Code está no link abaixo. Acompanhe no Instagram e no Facebook para ver dicas rápidas de IA e as análises aprofundadas ao vivo

14:37 aqui no YouTube. Vejo você no próximo.

Transcrição original

[00:00] You have five things to fix in your app. So, you open Claude, then a second chat because the first one is full. Then a third. Now, you’re copying notes between tabs, and you can’t close your laptop because the minute you do, everything stops. Anthropic just shipped the fix. You type all five jobs into one messy message. Claude splits them up and runs them at the same time on its own computers even after your laptop is shut. Their

[00:31] video about it has been watched over 170,000 times. The top comment says, “I didn’t understand a single thing.” So, I’ll explain it in plain English. Then, I’ll give it a real app with real bugs. Close my laptop, walk away for 30 minutes, and show you everything that was waiting when I came back. And what it cost. Here’s why the old way breaks. A Claude chat is like one desk.

[01:02] Every job you hand it piles more paper on that desk. Files it read, errors it hit, things it tried. The desk has a size limit. When it fills up, Claude tidies it by summarizing, and details fall off the edge. That’s why a long chat starts forgetting what you told it an hour ago. So, you do the sensible thing and open more chats, one per job. Now, every desk is clean, but someone has to walk between them,

[01:34] carry notes from one to the next, remember which one was waiting for an answer, and keep the laptop open so none of them stop. That someone is you. You’ve become the manager, and you can only stand at one desk at a time. Projects doesn’t give Claude a bigger desk. It gives Claude a manager. A project is one long conversation. You talk to one Claude, the coordinator. Think of it as the manager.

[02:05] You tell it what needs doing in your own words, as messy as you like. For each real job, the manager starts a thread. A thread is a worker with its own desk. So, its paper never mixes with anyone else’s. It gets its own copy of your code on its own branch. And in the cloud, it gets its own computer. When it’s done, it hands back a pull request. A neat package of changes you can read and accept. Here’s the clever part.

[02:36] The manager only reads what each worker reports back, not every step it took. So, the manager’s desk never fills up. You can keep this one conversation going for weeks. Everyone also shares one shelf. Your instructions, which every new thread receives, a memory file Claude keeps notes in, and a library of files you upload. And you don’t read chats anymore, you read a board. Threads move through these columns on their own.

[03:07] The only column that needs you is waiting on you. The threads run on computers at Anthropic, so you can close the laptop and check the board from your phone. That’s the whole idea. But, there’s one way this goes badly wrong. And I’ll show you exactly how it happened to someone, and the five lines that prevent it. The most asked question under Anthropic’s video is, “How is this different from subagents?” Here’s the whole thing as a ladder. A quick question. A normal chat.

[03:39] One job, like fixing one bug. A cloud session. One worker, one branch, one pull request. One job that needs some research done in parallel. That’s sub agents. Little helpers inside one session that look things up, report back, and disappear. Several separate jobs that run over days, each worth its own pull request. That’s a project. They stack, too. A thread inside a project can use its

[04:11] own sub agents. And if you remember the old Claude projects, a folder of files plus some chats, this is different. The old one stored things. The new one runs things. Screenshot this ladder or send it to whoever asked you what projects is. Here’s the setup on my account. One, look for projects in the sidebar of Claude code on the web. It’s a beta for pro and max plans, not team or enterprise yet.

[04:43] Anthropic let everyone from the waitlist in on October the 9th. So, if you join before that, check now. Two, new project. Give it a name and a goal. Mine is make the shop fast and check out reliable. Then, add the code. I’m using a small demo shop I set up with problems planted in it, so you can see real before and after numbers. Three, projects needs the Claude GitHub app installed on that code. A plain Claude session doesn’t, so this step trips people up. Four instructions,

[05:16] this is the part nobody shows, and it’s the most important. I gave it five lines. I’ll explain why each one is there later in the part where this goes wrong. Five, check the settings before your first message. Every thread runs Opus, Claude’s biggest model at medium effort, and the manager runs Opus on low. And look at this switch, auto continue when usage limits reset. It’s on by default.

[05:48] So, a thread that runs out of usage picks up again in your next window. I’ll come back to that when we look at the bill. It’s 20 to 11 at night. I’m typing like a tired human, not writing a spec. Nobody clicks the buy pro button. The first page load takes 3 seconds. A customer got charged twice. We need a returns page, and checkout barely has tests. Proposed threads first, and wait for my go ahead. In about 10 seconds, the coordinator comes

[06:19] back with five threads, one draft pull request each, exactly like my instructions said. Then, it noticed something I didn’t. The double charge fix and the checkout tests both touch the same code. So, it starts the fix first and has the tests build on top of it. That’s a manager move. I type go. Thread cards appear right in the conversation. Each one is a separate worker on its own computer. Four threads start working at once, and

[06:51] the fifth waits its turn. Now, the part that used to be impossible. I close the laptop and walk away. While that runs, if this is the first time projects actually made sense, that’s what this channel does. Subscribe, and let’s see what’s waiting. 30 minutes later, I open the board. Three are ready for review. Two are waiting on me, and both say blocked. Good. I’ll explain why that’s good in a

[07:21] second. The slow first page. It found a loop doing 28 million steps every time the shop started, building a search index that nothing ever reads. It deleted it. The first page went from 3 seconds to six thousandths of a second. It timed that itself. And it added a test that fails if it ever gets slow again. And then this, the code only has one safe point. So, it said it couldn’t tell me which change caused the slow down. It didn’t make one

[07:51] up. Like the double charge. It first wrote a test that reproduces the bug. One customer, two charges. Then it fixed it with a one-time key. So, a retry can’t charge twice. Test passes. Now, the two blocked ones. The returns page. It looked everywhere for our refund policy. Didn’t find one and stopped. I haven’t changed any code yet. It refused to invent a refund policy for a real shop.

[08:23] That is line four of my instructions working. I gave it a policy and 2 minutes later, the page was done. The buy pro button had two problems. It looked like a footnote, so it fixed that. And it linked nowhere because there’s no checkout page. It asked me what to do and it warned me that wiring it straight to checkout would charge people instantly while the double charge bug is still live. I told it to leave the link for now. Five pull requests, nothing waiting on

[08:55] me. To accept one, you tell that thread merge it and watch what it says. It merged because I asked in person. But the never merge rule still holds for every other thread. Now, the question every comment section asks, what did this cost? Project settings has a usage page. Five threads, almost 10 million tokens. That sounds terrifying.

[09:26] But look at the breakdown. 96% of it is cache reads. Claude rereading files it already had, which is the cheap kind. The brand-new writing was about 33,000 tokens. The manager took 16%. And the biggest thread was the slow first load because I came back and had it merged, too. Second was the returns page. The one that stopped and waited for me.

[09:57] Four things make it expensive. Every thread defaults to Opus, the biggest model. A thread that’s watching a pull request wakes up and works again when a test fails or someone comments. If you hit your limit, that auto-continue switch makes threads pick up again in your next window. So, turn it off if you want a hard stop. And if you go back to a thread that’s been idle for more than an hour, Claude rereads the whole conversation.

[10:30] Start a fresh thread instead. Also, if you claim the free cloud credit from Anthropic in September, it doesn’t cover projects. It’s for plain cloud sessions only. And it expires November the 4th. Here’s the cheaper recipe for bigger jobs. Here’s the way this goes badly wrong. A developer ran a project to build a server and filed this on GitHub.

[11:00] Threads merged pull requests while the tests were still failing. One was merged about 4 seconds after it stopped being a draft. Four merged changes had to be undone. And they restarted the whole plan. Two more traps. The cloud computer pauses between turns. And if it can’t resume work that wasn’t saved to GitHub can be lost. And telling it run at most two threads is a preference it remembers, not a hard limit. That’s why my five lines exist.

[11:32] Never merge, so you’re the one who accepts changes. Paste in the test results, so failures are visible. Push work as you go, so paused computer loses nothing. Stop and say what’s missing instead of faking it, and hands-off the safety checks. The same person said, “It works really well for single investigate and fix jobs.” The fix isn’t to avoid it. It’s to give it rules before you walk away. A lot of people think this is cloud

[12:02] only. It isn’t. Since September 23rd, a thread can run on your own computer. In the plus menu, pick work locally, then allow the folder. You need Cloud Code version 2.1.280 or newer. And the desktop apps use this computer from your phone setting on. Turn on work tree, so two local threads don’t overwrite each other’s files. The trade-offs. Local threads only run while your computer is awake,

[12:33] and they get your instructions, but not the project’s memory file. Use them for private files or company systems. Use the cloud for everything you want done while you’re out. The second most liked comment asks how to turn existing chats into a project. For a cloud session, open its menu and pick continue as project, which keeps that session running, or move to project to add it to one you already have.

[13:03] Older Cloud projects are being moved to the new version for some users. You get an email first, and nothing is deleted. And fresh this week, routines are now called scheduled tasks. Same feature, new name, so don’t go looking for the old tab. Use a project when you have three or more separate jobs. Your code is on GitHub, and you want to walk away. Skip for one quick fix. A cloud session is cheaper. Be careful on the pro plan because the docs say you’ll hit your limit sooner.

[13:35] And it’s one person per project for now, so it’s not for teams yet. Real talk. 90% of you watching haven’t subscribed. On YouTube, hit join and become a member. On Facebook, hit subscribe, the supporter button. That is what keeps the lights on here. And if a paid membership isn’t for you, a free YouTube subscribe still tells the algorithm to send you more. Subscribe to support us. I put everything into a free project

[14:06] starter kit. The five-line instructions, the cheap settings recipe, the ladder, my five messy messages, and how to move existing work in. Comment conductor and my bot will send it to you. And tell me in the comments, what’s the first job you’d hand a project before you walk away. If you want the full playbook, my complete cloud code guide is linked below. Follow along on Instagram and Facebook for bite-size AI and the deep dives live

[14:37] here on YouTube. I’ll see you in the next one.