Claude Code Projects Explained: I Closed My Laptop and It Kept Working

Author: Hyperautomation Labs · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Claude Code Projects Explained: I Closed My Laptop and It Kept Working · Channel: Hyperautomation Labs · 14:37 · Watch on YouTube

Topics: AI agents, Task and workflow automation, Cybersecurity and software security, Claude Code

Summary

The video explains Claude Code Projects as a coordinator that divides a user’s request into independent cloud threads, each with its own computer, code branch, and pull request. The presenter demonstrates the workflow on a demo shop, showing how threads fix bugs, flag missing information, and pause for human input while the laptop is closed. The video also covers setup, usage costs, safety instructions, local threads, and how Projects differ from chats and subagents. Its central advice is to set clear rules, review changes yourself, and use Projects for several separate jobs you want running while you are away.

Key points

A Project has one long-running coordinator conversation that starts separate worker threads for individual jobs.
Each thread has its own workspace, code branch, and cloud computer, and returns a pull request for review.
Threads can run concurrently while the user’s laptop is closed; a board shows their status and requests for input.
Projects are suited to several separate jobs, while subagents handle parallel research within one job.
The demo shop’s slow page load, double-charge bug, and missing refund policy illustrate fixes, tests, and appropriate pauses for clarification.
The presenter recommends instructions such as never merging changes automatically, sharing test results, pushing work to GitHub, and stopping when information is missing.
Costs can be affected by the default Opus model, threads that resume after activity or usage resets, and rereading long idle conversations.
Threads can also run locally, but only while the computer is awake and without access to the Project’s memory file.
Projects are presented as a fit for three or more separate jobs when code is on GitHub and the user wants to step away; they are not for teams yet.

Chapters

Start	Chapter	Summary
00:00	The problem Projects are meant to solve	The presenter compares crowded chats and manual coordination with Projects’ coordinator-and-worker approach.
03:07	Projects, subagents, and setup	The video distinguishes Projects from subagents and explains how to create a Project, connect code, and configure instructions and settings.
05:48	A hands-off demo with real bugs	The coordinator divides a messy request into threads, which work on the demo shop while the presenter closes the laptop.
07:21	Results, review, and costs	The presenter reviews bug fixes and blocked work, then explains usage, cost factors, and settings that can affect spending.
10:30	Safety rules and local threads	The video describes risks from premature merges and paused computers, gives protective instructions, and explains local-thread trade-offs.
13:03	When to use a Project	The presenter covers migration and scheduled-task naming changes, recommends when Projects are appropriate, and points viewers to a starter kit.

Quotes

Projects doesn’t give Claude a bigger desk. It gives Claude a manager. — 01:34

A thread is a worker with its own desk. — 02:05

It refused to invent a refund policy for a real shop. — 07:51

The fix isn’t to avoid it. It’s to give it rules before you walk away. — 11:32

Use a project when you have three or more separate jobs. — 13:03

Concepts and entities

Projects, Claude Code, Anthropic, Opus, subagents, pull request, GitHub

Full transcript (original language)

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.