The argument in one line.
Running multiple Claude Code terminals only accelerates your work when tasks are truly independent, phased with clear dependencies, or sequential—but parallel sessions on entangled work waste money and produce brittle code.
Read if. Skip if.
READ IF YOU ARE…
- You're building with Claude Code and currently running multiple terminals without a decision framework, wondering if you're optimizing or just wasting API credits.
- A developer who understands task dependency chains but hasn't formalized when parallel execution actually saves time versus when it creates agent collisions.
- You're early enough in Claude Code adoption that you don't yet have ingrained habits around terminal management, and you want mental models before those habits calcify.
SKIP IF…
- You're building single-threaded applications or features where tasks have hard dependencies that must execute sequentially — this video assumes at least some parallelizable work.
- You've already built production systems with Claude Code and have your own tested patterns for terminal orchestration — this is introductory framework, not advanced optimization.
The full version, fast.
Running dozens of Claude Code terminals in parallel is mostly theater; the real skill is matching the parallelism pattern to the dependency structure of your work. The video teaches three decision models: True Parallel for fully independent non-coding tasks like research, copywriting, and outreach where sessions cannot collide; Phased Parallel where one terminal lays a foundation (database, auth) before independent features fan out in a second wave; and the Relay Race, where a single plan.md file with checkboxes batons context from one fresh-context session to the next, preventing auto-compaction drift. Before spinning up another terminal, ask whether the task is genuinely independent. Keep a virgin plan-watching session open to audit completion, and log architectural decisions so each new session inherits real context instead of guesses.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 00:48
01 · The parallel terminal fantasy
Opens with the LinkedIn/X flex of hundreds of terminals, then reveals the reality: agents colliding, brittle features, money on fire.
00:48 – 02:02
02 · Why more terminals does not mean more speed
Software dev analogy: doubling devs does not halve time. Introduces the One Question.
02:02 – 03:29
03 · Overview: The 3 Scenarios
Whiteboard slide shows all three scenarios side by side with the one-question decision rule.
03:29 – 05:00
04 · Scenario 1: True Parallel
Non-technical, fully independent tasks. All fire simultaneously. Time = longest task.
05:00 – 06:27
05 · True Parallel terminal demo
Live 4-terminal demo: competitors research, email sequence, influencer list, landing page copy all running at once.
06:27 – 09:15
06 · Scenario 2: Phased Parallel
Technical tasks with dependencies. Build DB schema + auth first (sequential), then parallelize Phase 2 features. ~2x faster.
09:15 – 10:40
07 · Phased Parallel dependency analysis
Whiteboard shows Claude verdict: tasks 1-2 must be sequential, tasks 3-7 can parallelize after 1-2 done.
10:40 – 12:00
08 · The execution flow diagram
Phase 1 (35 min sequential) then Phase 2 (30 min parallel) then Phase 3. Total 95 min vs 180 min all-sequential.
10:20 – 12:20
09 · Scenario 3: The Relay Race
Multiple terminals open but NOT parallel. Each handles one phase then closes. PLAN.md is the baton.
11:20 – 12:42
10 · Auto-compact danger
Each auto-compact = unknown context loss. One giant session compounds the debt.
12:01 – 14:19
11 · PLAN.md as the brain
Structure: overview, phased checklist, decision log. Terminals start by reading PLAN.md to bridge stateless sessions.
13:13 – 14:38
12 · The bonus session trick
One extra terminal kept open throughout all phases as virgin-eyes plan auditor.
14:19 – 16:16
13 · Relay Race terminal demo
Full PLAN.md with overview, phases, checkboxes. Prompt shown: read plan.md, execute phase 1, check off tasks.
16:16 – 17:34
14 · Wrap-up and resources
Brief recap, Gumroad resource plug, Skool community CTA.
Lines worth screenshotting.
- Running parallel Claude Code terminals only makes you faster when the tasks are genuinely independent — otherwise you're burning money and calling it productivity.
- Every time Claude Code auto-compacts, you don't know what context it deprioritized, and the next session starts at a disadvantage.
- Three named scenarios cover almost every parallel case: True Parallel (independent tasks), Phased Parallel (foundation then branches), and Relay Race (sequential phases, fresh context each time).
- Design thinking — understanding prerequisites and system architecture — is a more valuable skill in the next twelve months than knowing how to code.
- Adding more developers doesn't halve development time, and adding more Claude terminals doesn't multiply your throughput — the same logic applies.
- A dedicated 'virgin eyes' session that only knows the plan can spot what phase three missed that the implementation sessions overlooked.
- Auto-compacting one bloated session repeatedly is worse than deliberately closing it and starting a fresh session with a targeted phase prompt.
- A decisions log markdown file — tracking choices that deviated from the original plan — gives each new session the context it needs without asking for it.
- Asking Claude Code itself which parts of a plan can run independently is a cheat code for non-technical builders who can't spot parallelism themselves.
- If a task's prompt requires knowing the output of another task before it can proceed, it is not eligible to run in parallel.
- The relay race phase structure solves context window bloat by treating each phase as its own complete session with a hard end point.
- Maintaining a plan.md with checked-off checkboxes is a multi-layer insurance policy against losing progress across compacted or closed sessions.
Steal the decision tree.
Claude Code parallel sessions playbook
The One Question — does Task B need Task A output? — is the entire framework in a single gate.
- Use True Parallel only for content or research sprints where every task is genuinely independent.
- For technical builds, lay the foundation (DB + auth) in one sequential terminal before parallelizing anything.
- Write PLAN.md first, update checkboxes throughout, reference it in every new terminal opening prompt.
- Keep one bonus terminal open as a plan guardian for virgin-eyes phase reviews.
- Never let one session run through multiple auto-compacts on the same feature area — treat each phase as its own context budget.
- Ask Claude Code itself what can be parallelized: look at the rest of our plan and tell me what can be built independently in a separate session.
Terms worth knowing.
- parallel terminals
- Running multiple simultaneous Claude Code sessions in separate terminal windows to tackle independent tasks concurrently, saving wall-clock time.
- True Parallel
- Mark Kashef's first scenario: tasks that are fully independent with no shared files or dependencies, making simultaneous execution safe and faster.
- Phased Parallel
- Mark Kashef's second scenario: tasks that are independent within a phase but must synchronize before the next phase begins, like a parallel build step before integration.
- Relay Race
- Mark Kashef's third scenario: sequential tasks where each agent's output becomes the next agent's input, running one at a time in a deliberate handoff chain.
- agent collision
- The problem that occurs when multiple AI coding agents modify the same files simultaneously, causing conflicts, overwrites, or contradictory implementations.
- brittle code
- Code that works under the exact conditions it was written for but breaks easily when requirements change, other parts of the codebase are modified, or edge cases arise.
- dependency graph
- A map of which tasks or code modules depend on which others, used to determine whether tasks can safely run in parallel or must be sequenced.
- context isolation
- Ensuring each parallel Claude Code session only has access to the files and context relevant to its specific task, preventing agents from interfering with each other.
Things they pointed at.
Lines you could clip.
00:48
“You are gonna be lighting money on fire and just calling it productivity.”
10:49
“Every single time you auto compact, you do not really know what Claude Code has prioritized or not prioritized to include in that next session.”
13:18
“Terminal B does not know what Terminal A did. But Terminal B reads the codebase and the PLAN.md — it has everything.”
08:26
“Design thinking is the most important skill in the next twelve months. It is not gonna be coding.”
14:18
“I am always hiding behind a plan.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphoranalogy
00:00If you've been building with Cloud Code, then at some point, you must have seen screenshots or videos just like these on LinkedIn or x. Someone flexing that they have five, ten, 50, hundreds of Cloud Code terminal sessions running at the exact same time. But here's what they don't show you.
00:16When you zoom in on those terminals, you'll see that a bunch of them are asking very basic questions that can be answered in under thirty seconds. And what about the ones that are apparently doing the real work? Well, many of those sessions have agents colliding with each other, stepping on each other's toes, and most importantly, building features that are so brittle that they'll break the moment that they're touched.
00:37Now the fantasy of running hundreds of terminals is beautiful, but if you don't understand when it makes sense to run something in parallel versus when it creates chaos, then you're gonna be . So in this video, I'm gonna walk you through three different scenarios where running tasks in parallel in Cloud Code makes sense.
00:54And the one question that you need to ask before you start up your next extra session. So I won't just walk through theory. I'll actually show you the terminals that I've set up before this video to give you a good mental model and a visual model of when it makes sense to use the three different scenarios that I'll show you.
01:09And one thing I want to emphasize is just because I'm showing you these three doesn't mean that it's only these three methods that you can employ. There are many ways that you can make this your own, but these are three mental models that to me, especially if I was just starting out, would make things a lot less noisy, a lot less hype based, and a lot more focused on the task at hand.
01:27So once again, the fantasy we wanted to spell is that adding eight terminals, 800 terminals will make you eight to 800 times faster. Because even in the world of development, just because you add double the developers doesn't mean that you half the time of development itself. Every single build or every single set of tasks has some nuance as to one, whether or not it's even eligible to run-in parallel, let alone when what order it should execute if it is eligible.
01:53So the three scenarios are the following, and we'll go through each one in-depth and, again, show you an example hands on in the terminal. So scenario one is a true parallel, and this really applies to nontechnical tasks.
02:05Meaning, you're not vibe coding some front end. You have a series of tasks that all are independent, that don't need to depend on another, that you can truly run-in parallel. So you can realize that fantasy of having five, ten, even 15 terminals and nothing bad will happen.
02:20You will be more productive assuming one, you know what you're trying to do. Two, you know exactly what intermediary steps you need to accomplish to get there. And three, you have the proper prompts in place for all of those tasks where you don't need to babysit them.
02:33Now scenario two is usually where I work, where things are phased, where you have some form of foundation, where once that foundation is laid, you have auxiliary tasks that you can execute, some of which can be actually independent. Meaning, you can focus one terminal on tasks that need some more dependencies and others that can run independently and mutually exclusive from the rest of the build.
02:54And when it comes to scenario three, this is also pretty practical where maybe you have a plan file. We call it a plan MD file where you have things that are in phases, and they are in phases because each phase depends on the existence of whatever the output is of the phase prior. And this is where it makes sense to execute one terminal after the other, and you're taking advantage of the fact that you're not clogging one terminal or two terminals with tons of context with different libraries and structures that overlap.
03:22So So let's take scenario one, which is the easiest to wrap your head around and again realizes this fantasy of using multiple terminals. So this is called true parallel. In this case, let's say you have a overall task of I need to launch my AI course.
03:36Let's assume you are not a YouTuber yourself, meaning you need some form of distribution. So you might create all of these tasks. One of these tasks could be research competitors.
03:45Another one could be draft emails, find influencers, create lead magnets, find podcasts, draft tweets or posts on x, research PR angles, and create a landing page copy.
03:57Now outside of the landing page copy itself, which could be could be dependent on the outputs of some of the others, most of these can be run-in parallel to accomplish the overall goal. So you could theoretically execute task number one here, which is find 10 competitors, which wouldn't step on the toes of task number two, which is email copy email copywriting, and task number three, finding 20 influencers to help distribute an AI course could be all independent.
04:24Now could there be nuances where it might be helpful for task three to be aware of task one? It could be. It depends on the situation, which is why I want you to be a lot more critical when you think about running things in parallel because you lose nuance.
04:36You can lose context, especially if you're more of a beginner and you don't know how to do things like create GitHub issues or create very sophisticated plans or run agents and sub agents that help pass context between different parallel sessions where you have the important part that you need to keep advancing everything forward with the full context that each of these sessions also require.
04:56So again, instead of yapping about it, here's one example of a terminal, not with a 100 sessions, not with six, but four. It's easier on the eyes and easier on my soul as it show it to you. You can have the first one say research the top 10 AI course competitors, list their pricing, unique angles, and target audience, and then output to, let's say, research and call it competitors dot markdown file.
05:18And then number two could be draft a five email welcome sequence for new subscribers to my AI newsletter. Maybe that's one way you wanna get distribution. Save to welcomes.md.
05:28And then same idea here. Find 20 tech influencers on YouTube with a 100 to a 100 k subscribers who review online courses. And the last one could be write landing page copy with the headline, sub headline, three bullet points, SEO optimized, whatever you want, and then go from there.
05:44So you can see this is practical, to the point, and bite sized. So to me, is not a red flag. This is totally doable and especially if you're trying to really realize the benefits of using a Claude code versus a chat GBT or Claudia on the front end, this is an amazing gateway drug to allow you to do that.
06:01Once you complete phase one and you have the foundation of the application or the task that you're building, then you're eligible to go to phase two where you can then spin up all of these parallel sessions. And this part makes a lot more sense if you have an idea of what features are the most likely to be truly independent.
06:18Now let's say that you're looking at this and you're nontechnical and you have no clue or instinct of whether or not feature a b c or d are actually independent. One cheat code that you could do is once you build the foundation, you can physically ask Claude code, look at the rest of our plan here and tell me what you think can be built independently in a way where if it had no context of the other tasks that I could run it in a separate session and it could have no understanding of what's happening in parallel throughout.
06:46This is not foolproof, especially if you wanna keep developing an idea that's not fully developed in your head yet. But if you have a full understanding end to end of what you're trying to build, Claude code could give you not only the tools and the hint of what could run-in parallel, but you could ask it to run a meta prompt for you to tell you what to tell this new session to build in parallel in a way that will not step on the toes of the other agents.
07:09So this is admittedly a bit more convoluted, but it's an instinct that you can build over time with the help of Cloud Code. And in the phase parallel approach, you might get to phase three, phase four, phase five, where there could be intermingling, some dependencies, But maybe for phase two, you can run everything in parallel.
07:25So if you were putting this on a whiteboard, here's a sample mental model, and then I'll show you an actual sample. So let's say you have a database schema, and everything revolves around that database existing.
07:36So the ability to create a profile, the ability to pay, all of that revolves around being able to log that somewhere. So this has to be first.
07:45So if you want to create an authentication system, well, you need the database. If you need a user dashboard, well, you would have had to find a way to log them in, right, and then store it in the database itself. If you want an admin panel, then you need one and two, both of these together because you need authentication and the database.
08:04So mapping this out, and again, you don't have to act like you're some coder that you're not if you're nontechnical. You can ask AI to help you better understand the order of operations. And once you do that, one, you'll have a much richer plan.
08:17Two, you will grow yourself over time to think in design thinking, which in my opinion is the most important skill in the next twelve months. It's not gonna be coding. Understanding architecture and coding gives you an unfair advantage if you supercharge it.
08:31But if you can understand design principles, system architecture, understanding the prerequisites to going from a to b, you'll go pretty far. So if we take these exact dependencies, you can go and map them like this, where maybe the database schema and auth system take the majority of the phase one.
08:47And then phase two is where you do things like the user dashboard, the admin panel, the file upload, payment notifications. Although there could be some intermingling where you need the user dashboard to be set up for payment to be executed. Really depends on the scope of the app, the customer journey, etcetera.
09:03But then you get to phase three, which is analytics. And how can you have the analytics about what's happening without all the building blocks in between? So that's the way I'd push you to think when you are building things and you take this phased approach.
09:15And just to finish that thought, this is what the multiple terminals might look like for this project. So number one would be set up database schema for client portal, create table for users, projects, files, and invoices. Ideally, you'd wanna tell it where you wanna host this database.
09:29Do you want it to be SQL lite on your actual computer? Do you want it to be super based? Do you want it to be convex?
09:34Do you want it to be on AWS? You have to specify that as well. This would be more so of a starter prompt, and it's your job to fill in the blanks.
09:42So if you are adamant on running things in parallel, you know that each one has enough granularity that it can go and fully complete that subtask, not half baked. The second one, like I said, is build the authentication system with login, sign up, and password reset.
09:58Use database schema from here. So you can see dependency right there. Build the user dashboard showing the project list and status, auth and database already set up.
10:07So in this case, can tell this session that both of these have completed and it's ready to build on top of the foundation that's already been put together. And last but not least, you could say build the admin panel for client management, auth, and database already set up.
10:20Now phase three, I call the really race where it's literally a baton that's being passed from one session to the next. And the real value add here is you're self aware that there are different phases. And as each phase completes, you kind of mark the end of that session.
10:35So even if you compact the conversation, it's on the same context that it was throughout the entire conversation. One mistake that I see quite a bit is people will dedicate one session towards building two or three quarters of the whole app, and they auto compact multiple times not realizing that every single time you auto compact, you don't really know what Claude code has prioritized or not prioritized to include in that next session.
11:01So you keep running the next session with a disadvantage, and in a way you're confusing it because maybe there's bits and parts of the nuance that it needs to do what it needs to do. So this helps you have this phased approach where as each session completes, that is the end of that session. So each session is mutually exclusive at least in context.
11:20So even if the auto compact is not relaying all the information, overall, it has the eighty twenty it needs to keep going. Now this also naturally solves the issue of the context window where, hopefully, we'll get to a point where we have half a million, a 5,000,000 context window.
11:37But for now, if you have a very large and bloated CloudMD file, if you have this tendency to lazily prompt at some point and then lead Cloud code down a wild goose chase to read and reread the same files that might not even be relevant to your request, this will fill up really quickly. So this is one more technique that might help alleviate this burden.
11:57And the core idea here is you have some form of PlanMD, and I love doing PlanMDs for all kinds of projects where TLDR, you have Claude not just go into plan mode, but document its entire plan, number one.
12:10And then number two, create check boxes across every task for that phase of that plan, and then you tell it, especially to tell it to remember in Claude MD, which is the brain command center of Claude. As we go through different phases, check off everything you've completed because this gives you multiple layers of insurance.
12:29Let's say you dedicated six terminals to six phases, and what happened is you underestimated how big phase one was gonna be compared to phase two, and you kind of actually need two terminal sessions full end to end to execute phase two. Having the plan m d would allow Cloudco to document the 80% that finished, and then you can resume and baton pass the rest of the plan to the next session.
12:54So then you can get into a groove, especially if you have your vibe coding playlist on where you go through terminal a, you run local host to see what the app looks like or whatever the service is on your computer, then you close it or you keep it open, then you have terminal b and so on. And one key extra tip here is I add one extra session, so one bonus session.
13:15This bonus session is actually where I completed the plan and created the plan m d, and I'll keep that one open despite executing the different phases in other windows. And I'll tell you the reason why. Because as you think you're completing phase one, two, three, and four, you can always check-in with this virgin eyes context window in session that's only obsessed with the plan and say, can you take a peek at phase three?
13:39We just completed it elsewhere. Can you just check the code base and tell me, have we finished everything that we need to do? And sometimes it might be able to take a look at that code from terminal number four or five and say we actually didn't complete this and this.
13:53It missed that. So now you can start to be proactive and on the offense instead of on the defense. I'm always hiding behind a plan.
14:01So the core benefits is that you don't lose momentum, you keep each phase with a 100% fresh context, you don't have Claude forgetting every couple times what you said a few hours ago, especially if you're addicted to doing compacting of conversations, and then you're one step closer to finishing things a lot faster and a lot more elegantly.
14:19So in practice, this could look like this where you have a plan and everything here revolves around said plan. So if we take a look at the file, it's just meant to be an example. Typically, in all of my plan MDs, I'll have some form of overview.
14:31This overview should explain the inspiration behind the app, where you're trying to go, what problem you're trying to solve, big picture. And it's actually very helpful to feed that big picture because when you go into blank stateless sessions, what the word stateless means is as you go to each session, outside of the artifacts that you create and the CloudMD that you maintain for memory and any other memory stuff that you have that's auxiliary, it's hard to almost contextualize the Cloud code what the big picture is.
15:00If you can keep some reference of the big picture in this plan MD, it'll be that much more helpful. And this is where you have all the different phases with the associated tasks, and you can see we have the check boxes right here. So the instruction you'd give to store in CloudMD every single time you accomplish something is you would check this off, and this will allow you to always resume where you left off and not have to worry about documenting the journey.
15:23And when it comes to the prompts themselves, you could have something that says read plan dot m d, execute phase one, database and auth, check off tasks when done, and add any architecture decisions to the decision log. So one more thing you could do is create another markdown file that walks through decisions that happen as a result of you doing x y z in phase one.
15:46So there's this quote around everyone has a plan until they get punched in the face. Well, if you're nontechnical, especially, you can easily get punched in the face if you don't actually fully bake through what you're trying to build and what you need to build it.
15:58So the decisions log could act as one more artifact that can inform the next subsequent sessions on what decisions you made that kind of strayed away from the original plan. And again, this just keeps injecting helpful context into the next session in a way that keeps things flowing and adds more nuance to Claude Coates thinking so it doesn't go down these cookie cutter ADHD narrow tunneled routes.
16:22And that's pretty much it. So hopefully this gives more color and a reference point as to when it might make sense to use and not to use parallel sessions and some of the best ways to use them. And again, what I showed you here is not comprehensive of every single permutation.
16:36There are thousands of ways to solve the same problem especially when you use Cloud Code. And whether or not you use agents or sub agents or hooks or all kinds of things that you could do in Cloud Code, this is just meant to give you the foundation to execute your vision in whatever phases you choose. And if you want all the artifacts and the prompts that I showed you in this video along with a mini guide that I put together to help you wrap your head around a few different scenarios, I'll make that available to you in the second link in the description below.
17:03If you enjoy the way I break things down and try to build minus the hype, then check out the first link in the description below for my early AI adopters community. We're continually releasing exclusive builds where I walk through a to zed, how I design the project, how I think through the project, and most importantly, all the principles in between, and we're coming out with some brand new foundational content as well since many things have changed.
17:26And for the rest of you watching, if you could leave a like and a comment on the video, I'd super appreciate it. Helps the video, helps the channel, and I'll see you in the next one.
The Hook
The bait, then the rug-pull.
Everyone has seen the screenshot: 50 Claude Code terminals running at once, the poster implying they are 50x more productive. Mark Kashef opens by naming the flex directly then spending 17 minutes proving why it usually just means 50x more chaos.
Named ideas worth stealing.
01:50concept
The One Question
Before any extra terminal: Does Task B need Task A output? NO = True Parallel. DEPENDS = Phased Parallel. LONG SESSION = Relay Race.
Steal fordecision gate before every Claude Code multi-agent session
03:29model
Scenario 1: True Parallel
- All tasks independent
- Non-technical tasks preferred
- Time equals longest task
- No babysitting required
Fire all terminals simultaneously when zero cross-dependencies exist.
Steal forcontent launch tasks, research sprints, any batch of independent deliverables
06:27model
Scenario 2: Phased Parallel
- Phase 1: sequential foundation (DB schema, auth)
- Phase 2: parallel features once foundation exists
- Phase 3: final assembly
Sequential foundation unlocks parallel feature work. ~2x faster than all-sequential.
Steal forany technical build with a shared data layer
10:20model
Scenario 3: The Relay Race
- Phase 1 terminal closes when done
- PLAN.md is the baton
- Terminal B reads codebase + PLAN.md
- Fresh 100% context per phase
Multiple terminals used sequentially not in parallel. PLAN.md carries state. Solves auto-compact context loss.
Steal forlong multi-day builds where context debt is the main risk
12:01list
PLAN.md Structure
- Overview (inspiration, problem, big picture)
- Phases with checkboxes per task
- Decision log (architecture choices that strayed from plan)
Document that bridges stateless Claude Code sessions. Every terminal starts by reading it.
Steal forevery project over 2 hours of build time
13:13concept
The Bonus Session
One extra terminal kept open across all phases, dedicated to the plan only. Used as virgin-eyes QA to catch missed tasks before the next phase starts.
Steal forcatching missed tasks before starting the next phase
How they asked for the click.
VERBAL ASK
16:16product
“If you want all the artifacts and the prompts that I showed you in this video along with a mini guide I will make that available to you in the second link in the description below.”
Soft dual-CTA: paid Gumroad resource first, then community. No urgency, no pop-ups, framed as bonus depth.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
