1:00:56David Ondrej · Essay
Stop coding, build Software Factories instead
A sixty one minute argument that launching agents one at a time is already obsolete, ending with a live build of an automation that runs itself.
October 11thThe argument in one line.
The ceiling on how many coding agents you can run productively is not model quality or harness quality, it is the single laptop they all share, and giving every agent its own isolated cloud sandbox removes that ceiling.
Read if. Skip if.
READ IF YOU ARE…
- You already run five or more coding agents at once and keep hitting worktree collisions, CPU contention, or a laptop you can't close.
- You pay for two or more frontier coding subscriptions and want to use those tokens from whichever harness and GUI you prefer.
- You're designing scheduled agent loops or automations and need them to keep running when your machine sleeps.
- You evaluate dev tooling on architecture and want a concrete argument for sandbox-per-agent over one shared VPS or Mac mini.
- You're curious how a solo founder positions an open-source product against closed tools from much larger labs.
SKIP IF…
- You run one agent at a time on one repo. Nothing here solves a problem you currently have.
- You're on Windows. Only macOS and Linux are supported, and the host is blunt about that.
- You want a neutral review. This is a founder demoing his own launch, so the comparisons are framed to favor it.
- You need the agent to touch GPU rendering, Xcode, or anything else that genuinely requires your own hardware.
The full version, fast.
Cloudroom is an open-source desktop app that runs every AI coding agent in its own isolated Linux sandbox in the cloud, with any harness and any model you already pay for. The core argument is that models and harnesses are already good enough, and what actually stops people from running hundreds of agents productively is everything around them: shared CPU, worktree collisions, a laptop that closes, flaky cafe wifi, prompt-injected agents loose on your main machine. Separate machines fix all of it at once. Practical takeaways: migrate one project at a time rather than all at once, expect roughly a 90/10 split between cloud and local work, build scheduled agent loops that launch and review themselves, and judge any cloud agent product on whether it can still reach back into your laptop when a task needs a local file.
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 – 03:44
01 · Five harnesses, twenty-five subagents
Launches five agents on five different harnesses as cloud threads, then has one model spawn 25 Haiku subagents to bug-hunt a codebase. Thirty-eight agents running, each in its own sandbox.
03:44 – 05:13
02 · Why this is different
The competitive frame: existing cloud agent products lock you to one harness, are all closed source, and none give a dedicated sandbox per thread.
05:13 – 07:51
03 · The case for isolated sandboxes
Three arguments for one VM per agent: unbounded scaling, blast-radius containment when an agent gets compromised, and no resource or checkout contention between agents.
07:51 – 11:00
04 · Normal usage and teleport
The unglamorous daily loop: pick local or cloud per thread, switch harness and reasoning effort by keyboard, then teleport a running thread from the MacBook into a cloud sandbox mid-conversation.
11:00 – 14:36
05 · Why nobody else did this
Two reasons. Big labs have incentives to stay closed and harness-exclusive, and the engineering is genuinely hard: data loss, launch speed, credential sync. All of them have to work or nobody migrates.
14:36 – 16:56
06 · Who it's for, and what it costs
Explicitly not a consumer product. The filter is whether you already pay for two or more premium coding subscriptions. Free, $50 Pro, $500 Ultra, with Ultra buying a direct Slack line to the founder.
16:56 – 20:54
07 · Why the future of agents is cloud
Usage patterns are shifting from one human unblocking one agent to hundreds of agents launched by webhooks, schedules and other agents. That requires an always-on environment, not a laptop.
20:54 – 29:33
08 · Building an agent loop live
Shows existing automations including an arXiv digest that runs every other morning, then creates a new 30-minute dependency security scan by speaking one paragraph, and upgrades it to spawn a second-lab reviewer agent that self-archives false positives.
29:33 – 31:39
09 · The laptop is the bottleneck
The office analogy: an agent is a remote employee, and you would not hire someone and make them share one computer with five colleagues. Computer use makes it worse by stealing focus and opening windows.
31:39 – 39:55
10 · Local versus cloud, and a 100-agent local test
Predicts a 90/10 cloud-to-local split, names the real local-only cases, then stress-tests the app by spawning 100 local subagents across two harnesses while arguing most 'I need local' claims are artifacts of weak cloud products.
39:55 – 41:15
11 · Free, open, self-hostable
Both repos are Apache 2.0, the free tier is framed as permanent, and access to cloud threads rolls out in waves while local threads work immediately.
41:15 – 47:24
12 · The architecture
Rust-first core for speed and memory safety, a modular split between core, GUI and web app, a deliberately lightweight GUI that holds 300-plus open threads, keybind-first navigation, and macOS plus Linux only.
47:24 – 52:46
13 · Cloud agents reaching back into the Mac
The feature the rest of the category lacks. A cloud thread lists files in the local downloads folder, inventories local repos, then finds a logo on the laptop and opens it in Preview, all under a configurable permission level.
52:46 – 59:02
14 · The bet, the hiring, the feedback loop
Bootstrapped, San Francisco and Poland, hiring, a possible raise to cover compute, the Supabase free-tier business model as the reference, and a feedback tool where your agent files a bug that spawns an investigation thread on his side within ten minutes.
59:02 – 1:00:22
15 · Who should actually buy this
Closing filter restated in dollars: four hundred a month or more on inference, or a business owner rolling AI across a team.
Lines worth screenshotting.
- Infinite scalability is only possible when every agent gets its own computer, because any single shared machine has a fixed ceiling you will hit.
- If one agent gets prompt-injected or installs a hostile package, an isolated sandbox limits the blast radius to that one agent.
- Worktrees stop being enough around five to fifteen concurrent agents, because one agent pushing to the primary checkout dirties the tree for everyone else.
- Running all your agents on one machine is a bet that agent counts stay flat, which is a bet against the only trend that is obviously accelerating.
- Closed-source labs will never let you bring a rival harness, because their incentive is to capture the data and the subscription.
- Cloud agents have existed for a year and most people still have not migrated, which means the blocker is friction, not capability.
- Everything has to work at once. One broken piece, slow launches or missing logins, and nobody moves their real work over.
- Most people who insist their work requires local are describing a limitation of one cloud implementation, not a property of their work.
- A cloud agent that cannot reach your laptop fails the moment a task needs a file you forgot to upload.
- The target buyer is anyone already spending four hundred dollars a month or more on AI inference, not beginners or consumers.
- In the near future most agents will be started by triggers, schedules and other agents, not by a human typing a prompt.
- Past roughly fifty to a hundred open threads you lose track of what each one was for, so thread purpose metadata becomes infrastructure.
- Agent management will mirror company org charts: reviewer agents, manager agents and self-starting agents, not one human unblocking each worker.
- Computer use is productive and unusable at the same time on a shared machine, because the agent steals focus, opens tabs and fires popups.
- A GUI forked from VS Code inherits browser-process memory behavior, which is why one popular tool crashed past fifteen concurrent worktrees.
- An agent loop becomes a software factory somewhere around ten to twenty active automations, when meaningful work starts without you.
- Have one lab's model do the work and a second lab's model review the finding, then self-archive both threads when it was a false positive.
- Move to cloud one project at a time. Trying to move everything at once creates enough friction that you quit and conclude cloud does not work.
Give every agent its own machine
AGENT INFRASTRUCTURE
Models and harnesses are already good enough to run hundreds of agents, so the thing actually stopping you is the single computer they all share and everything that breaks when it sleeps.
01Five harnesses, twenty-five subagents
- One prompt can launch many agents across different harnesses at once, so the unit of work stops being a conversation and becomes a batch.
- Having a model spawn 25 subagents to scan different parts of a codebase finds more than one agent reading everything sequentially.
02Why this is different
- A tool that only runs its own harness forces you to abandon subscriptions you already pay for whenever a rival model gets better.
- Closed-source agent infrastructure means you cannot audit what your agent's environment does, fork it, or run it on your own hardware.
03The case for isolated sandboxes
- Scalability requires one computer per agent, because any single shared box has a fixed ceiling you will hit within a year.
- An isolated sandbox contains a compromised agent, so a prompt injection or a hostile package cannot reach your real filesystem.
- Worktrees stop being enough past five to fifteen agents, because one push to the primary checkout dirties the tree for all of them.
04Normal usage and teleport
- Deciding local or cloud per thread beats deciding it per tool, because most workflows have a few genuinely local tasks and many that are not.
- Moving a running thread between machines without losing context means the choice is reversible, which lowers the cost of trying cloud at all.
05Why nobody else did this
- A market gap usually has two causes at once: incumbents whose incentives block it, and engineering nobody wants to do.
- Partial solutions do not get adopted. If launch speed, credential sync or data durability is weak, people keep working the old way.
06Who it's for, and what it costs
- Qualify buyers with a number rather than a title. Two premium subscriptions or four hundred a month in inference is a test anyone can self-apply.
- Pricing that scales on compute hours and concurrent agents matches how the cost is actually incurred, which makes the tiers legible.
07Why the future of agents is cloud
- Agent usage is shifting from humans unblocking one agent at a time to webhooks, schedules and other agents launching the work.
- Past roughly a hundred threads you cannot remember what each one was for, so purpose metadata and completion percentage become necessary, not nice.
- Multi-agent orgs will mirror human orgs: reviewer agents, manager agents and self-starting agents instead of one human bottleneck.
08Building an agent loop live
- An automation becomes useful when it has a trigger, a narrow scope, a second-opinion reviewer and a rule for archiving itself.
- Having one lab's model check another lab's finding filters out overthinking before anything reaches you.
- Ten to twenty live automations is roughly where scheduled jobs start to feel like a team rather than a cron file.
09The laptop is the bottleneck
- Treat an agent like a remote hire. You would not make a new employee share one laptop with five colleagues and expect output.
- Computer use is only tolerable when the agent has its own screen, because otherwise it steals focus and opens windows on top of your work.
10Local versus cloud, and a 100-agent local test
- Expect something like a 90/10 split between cloud and local, with local reserved for privacy, OS-locked builds and heavy local rendering.
- Migrate one project at a time. Moving everything at once creates enough friction that people quit and blame the whole approach.
- Most claims that work requires local turn out to describe one weak cloud implementation rather than a property of the work itself.
- A GUI forked from an editor built on browser tech inherits its memory behavior, which is why some tools crash past fifteen concurrent worktrees.
12The architecture
- A Rust core and a deliberately thin GUI is what lets an app hold 300-plus open threads without lag, which is the real constraint at scale.
- Splitting core, GUI and web app into separate repos lets the interface stay replaceable while the orchestration engine stays stable.
- Keeping repos on GitHub rather than syncing files lets a fresh sandbox pull a project in seconds over a fast link.
13Cloud agents reaching back into the Mac
- A cloud agent that cannot read a file from your laptop fails on any task where you forgot to attach something, which is most of them.
- Graduated permissions, from off to read-only to ask-first to full access, make local access usable without handing over the machine.
14The bet, the hiring, the feedback loop
- Routing user feedback through the user's own agent into a database that triggers an investigation thread turns bug reports into work that starts itself.
Terms worth knowing.
- Harness
- The agent runtime that wraps a model: the CLI or app that handles tool calls, file edits, subagents and permissions. Claude Code, Codex, Amp and OpenCode are harnesses, and they are separate from the model running inside them.
- Isolated sandbox
- A dedicated Linux virtual machine in the cloud with its own filesystem, persistent state and internet connection, where one agent has the whole computer to itself and cannot touch any other agent's machine.
- Worktree
- A second working directory checked out from the same Git repository, letting two agents edit different branches without colliding. It solves file conflicts but not CPU, memory or shared-checkout contention.
- Cloud thread
- A conversation with an agent that executes on a remote sandbox rather than your own machine, so it keeps running when you close the laptop or lose wifi.
- Teleport
- Moving a live thread from your laptop to a cloud sandbox or back, carrying the full conversation context, repo and dependencies so the agent continues where it left off on different hardware.
- Subagent
- An agent spawned by another agent to handle a narrower task, usually on a cheaper or faster model, reporting findings back up to the parent thread.
- Agent loop
- A scheduled or event-triggered automation that launches an agent on its own, has it do a job such as a dependency scan, and then escalates, fixes or archives itself based on what it found.
- Software factory
- A collection of many agent loops running in parallel, covering roles a larger team would staff: security review, performance testing, user feedback triage, product gaps. The work starts without a human prompting it.
- Prompt injection
- An attack where hostile text inside a file, webpage or dependency gets read by an agent and treated as instructions, redirecting it to actions the user never asked for.
- Reasoning effort
- A per-request setting on frontier models that trades latency for depth of deliberation, typically exposed as low, high or max, and switchable per thread.
- ACP
- Agent Client Protocol, an interface that lets a single GUI drive agent harnesses it did not ship, so one app can host many vendors' agents.
Things they pointed at.
42:25toolThe upstream open-source GUI Cloudroom was forked from, credited repeatedly on air
04:13toolClaude Code
04:13toolCodex
04:00toolCursor
04:00toolAmp
04:00toolHermes
04:00toolOpenCode
11:41toolDevin / Cognition
30:30toolCua driver (open-source computer use)
23:50toolRoom CLI (the agent-facing command line inside Cloudroom)
51:27toolCloud Mac skill (lets a cloud agent act on the local machine)
20:39channelThe host's prior video on software factories
Lines you could clip.
55:40
“The models are good enough. The harnesses are good enough. So what is missing? The answer is everything else.”
56:31
“Agents need to be running. This should be a crime. Agents stop running.”
30:42
“Nobody hosts a website on a laptop.”
07:13
“If you're doing that, you're betting against the progress of AI. And if anything, that's one trend in the current world you don't want to be betting against.”
33:48
“A lot of the reasons why people think they need local just means there hasn't been good enough cloud agent solution so far.”
15:45
“My job is not to convince you that cloud agents are the future. It's going to be obvious to everybody over the next six to 12 months.”
29:54
“Imagine you hire somebody to your team and you say, oh, listen, bro, you're using this computer. And by the way, five other people on the team are using it. Like that person would probably leave on day one.”
22:56
“Forget about the UI. UI is a thing of the past.”
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.
metaphoranalogystory
My name is David Andre and I'm happy to introduce Cloudroom. Cloudroom is a new breakthrough in cloud agents that allows anybody to run any harness, any model with your existing subscriptions for cloud agents. And not only that, each cloud agent gets its own isolated sandbox and it's fully open source on GitHub and you can use it for free.
We're releasing the free plan today. We'll see how the capacity goes, but you can also self -host it, you can fork it, you can have your own agent inspect the code. Again, it's fully open source with three tier cloud agents, the first one in the world.
And let me just show you how powerful this could be because giving each agent its own computer means you can scale infinitely and these agents keep working even when your laptop runs out of battery or you just close it. So this is what Cloudroom looks like. The core thing is you can choose either local, local work tree or cloud, right?
So it's up to you where you launch each agent. And let me just show you how easy it is. Launch five different agents, each one with a different harness and different model, and ask them what machine are they on.
Launch all of them as cloud threads. Boom. I'm also going to do a new thread to show you the ease of launching many sub -agents, right?
Launch 25 sub -agents underneath you, each one using Haiku 5 .5, and tell them to look for different small bugs in different parts of the code base. But tell them to not make any changes yet. Right?
So on the left, look how fast that was. This Opus 5 .5 High just launched multiple agents just like that. And if we click through them, you can see this is a Cloud Code.
This one's Hermes. This one's OpenCode. This one's PyAgent.
And this one is Codex with Astra, right? So you can use any, your favorite harness, right? Whatever you're already using, your existing subscriptions.
There is no extra pay for tokens. Whether it's Cloud Code, Cursor, Codex, PyAgent, Hermes, OpenCode, FX, a Grog build or any other harness, we support ACP as well. You can use all of these.
And not only that, you can use them in the cloud. So I can say, what machine are we on? Just to see that we're not on my MacBook here.
And this is going to launch a cloud thread and look how fast that is. Within like two seconds, the agent is responding and boom, we're on a Cloudroom cloud sandbox, right? We've put a lot of work to make this as fast as local.
And I really believe this is the best solution for cloud engines. And look at that. It's launching 25 different Haiku sub -agents.
And each of these is in its own isolated sandbox. Let me just show that to you. If I reload, boom, you can see that I have 38 agents running.
Each of these is the own sandbox. I just have the privacy mode turned on so you guys don't see the name threads. But we can see the thread names here.
And you can see the models, right? So some of these are Sol, Opus 5 .5, Haiku 5 .5. So all of these are the agents that are running for me.
And this is just scratching the surface of what Cloudroom can do. And by the way, this is available right now. So as I mentioned, depending on capacity, I'll be releasing access to more and more people.
But the free plan is available today. So go to cloudroom .dev. It's also going to be the first link below the video.
And make sure to download the app. And again, you can use it completely unlimited. on local just like any app so whether you're using codex or cloud desktop or something else you know cursor all of these agents your existing subscriptions are here you can already use them um so yeah and by the way the same same thing works the other way i can say make sure to stop all of these agents and archive their threads everything is agent first they can modify they can update archive rename move them from local to cloud more on that later you can control everything with plain english All right, so let me explain why Cloudroom is different from all the existing Cloud Agent solutions.
Because there is, like, you know, Cursor Cloud or Codex Cloud, but there's many issues with them. First of all, they only let you use their own harness, right? So Anthropic is never going to let you bring Codex harness or PyAgent.
Same thing with Cursor. You need to use Cursor or GrokBuild. You cannot use Codex.
You cannot use Hermes. You can use OMP. You cannot use your favorite models, harnesses, and subscriptions.
With these existing cloud agent solutions, all of them are closed source. None of them is open source. Cloudroom is the first one.
Also, Cloudroom is the only AI coding tool that gives you an isolated sandbox for every thread, right? So, as I'm showing you here, these are different sandboxes. These are different Linux VMs, each agent running in his own computer, completely isolated from the other ones, which means...
You can scale infinitely, whether it's 38 agents, 380, 3 ,800. Obviously, we're going to see where the power users take it. There are limits on the free plan, but the paid plans can do much, much more.
So we're the only AI coding tool that gives you an isolated sandbox for every thread, which already is a major breakthrough. But the reason why I'm calling it a breakthrough is that Cloudroom is the world's first software where you can do that on a free plan. You get cloud agents on the free plan, each one of its own isolated VM.
Now, let me explain why this matters, right? It might not be obvious to you if you haven't been like deep in the field, but isolated sandboxes are like the obvious best architecture for cloud agents. A lot of people try to squeeze everything onto like a Mac mini or a single VPS or stuff like that, or maybe a second computer.
Let's say you have an old laptop at your home. There's many issues with that. First of all, infinite...
So scalability can only be achieved when you give each agent its own computer. If you have, let's say, a Mac mini, sure, it can maybe handle five agents, ten agents, but all of us are using more agents today than we used a year ago. And it doesn't take a genius to realize how fast AI is improving.
So me and you, we are using more agents today than 12 months ago. And by pure logic, we will be using a lot more agents 12 months from now than we are today. So if you buy a certain piece of hardware, What if you need that plus 20 %?
Well, you cannot run that on that hardware and you're limited, right? Also, running these in isolated sandboxes gives you a much better security because if one of these VMs, you know, maybe the agent gets prompt injected or downloads some harmful package, whatever, you really don't want that agent to be on your main computer.
If it's in an isolated sandbox, only that specific agent can get compromised. It's much better for security. And yeah, you need certain...
isolated walls so that agents don't interrupt on each other, they don't step on each other's toes. I mean, again, if you're running one or two codex instances or cloud code instances, it might not be obvious, but as soon as you start running 5, 10, 15, you'll be like, okay, I need work trees, right? But even then, in work trees, all it takes is one agent pushing something to the primary checkout and it's dirty and other agents are struggling, or maybe one agent is running database tests and that's...
taking up all the resources of your computer. It's not ideal at all when the agents share a single machine. And really, if you're doing that, you're .
And if anything, that's one trend in the current world you don't want to be betting against. AI getting better. It's getting better.
And the speed of improvements is only accelerating. So this is why isolated sandboxes matters. You can literally launch 100 sandboxes with one prompt inside of Cloudroom.
I'll just show you how to do that with 25. And yeah, it's infinitely scalable. So if you just need 20 agents, 30 agents suddenly to deliver a client work or take some opportunity in the stock market, you can just do that.
If you have hardware that's limited to a certain amount, you can't. So let me show you the normal usage, right? Because I don't want to do the fancy demos only.
Let me just do it here boom can archive this and we'll archive all the sub -agents as well So the normal usage you just work in a project, right? So right now this is the project which could be a repo could be a local folder up to you And again, you select local or cloud entirely up to you. You can also change it keyboard shortcuts You can there is like keyboard shortcuts for everything so we can change, you know Quick to Astra quick to Opus you can select the reasoning effort.
So let me do a low Let me do extra high. Let me do max or high if you're on like GPT like let's say, you know, Astra, you can do fast.
Whatever supports Harness, supports fast, you can just switch on that. Very easy. So that's that.
And again, you can switch to Cloud Thread just like that. And you simply speak your prompts, right? So you use it as you would do the Codex app or the Cursor app or Cloud Desktop.
Like if you're already using these, switching to Cloud Room will be so easy. So the way I work is like, let's say, give me change, like how we could improve the web app, maybe. I would like to improve this section to be a bit nicer, a bit more custom so that, I don't know, the color is different based on the color of the harness.
Okay, show me four different designs, each one rendered as a real image render. Boom, so I've just prompted that and it launches a new thread on the left. This one's running in the cloud and you can see on the left which threads are cloud threads and which are local on my own laptop.
Very easy with this icon. Now, another thing. as you might have noticed here, is teleport.
This is another feature we have that I don't think many other softwares have. I don't know if there's any other one that has it, to be fair. And that allows you to teleport threads from your MacBook to a cloud sandbox and back.
So let me just show you. So we're going to start on local and I'm going to do what machine are we on right now? So I'm going to prove it to you, right?
The agent will analyze the computer and it's going to say, oh, MacBook Pro, blah, blah, blah. And then we're going to run teleport.
We're on MacBook Pro, okay? So now I'm going to right -click, teleport to cloud, and you can see this cute little animation, teleporting to cloud, and the same thread with the same context and everything, same repo, all the dependencies it needs. It's going to move to a new isolated sandbox in the cloud and continue in there.
So let's say you're working for, I don't know, an hour. 90 minutes on your local, and then you need to leave suddenly. Some opportunity, you need to go to the airport, you need to go cafe, and you have your work running.
The agents are running, and they need to keep running, right? So now we can say, check again, what computer or machine are we on right now?
I mean, we're already answered, but I just want to prove it to you for, like, completely. We're still in a Cloudroom cloud sandbox. Not your Mac, see?
And now we're on the sandbox. And literally within a matter of seconds, the entire chat... same model, same harness, everything, working in an isolated cloud sandbox.
And again, each of these threads, and you don't need to stress this, each of these cloud threads has its own isolated sandbox. Yeah. So why did nobody else do it, right?
You might be thinking, okay, David, amazing innovation. Why didn't this exist yet? Like, how come nobody else figured this out?
Well, first of all... The existing solutions, like the big labs and the big companies, they have perverse incentives, right? They're training models.
They want all of the data and any breakthrough or innovation they have, it's closed. Fully closed source, like no openness to other harnesses. Like even Cursor, right?
Cursor, if you think about it for a long time, since like they started, you could use any model and that was the benefit of Cursor. But since the acquisition of SpaceX, SpaceX buying Cursor, You cannot use GPD models in there, right?
So Astra was the best model for a solid three weeks, and you could not use it in Cursor. And that's the problem with these existing solutions. They are not agent agnostic.
They are not harness agnostic. They want you to use their own harness. They're forcing you to pay for their own subscription.
They're forcing you to use their own harness and use their own GUI, even if you might not want to, right? All of us are already paying big money for... Claw subscription, Furcorex subscription, Grok subscription, whatever.
Or OpenCodeGo. You want to use those tokens, okay? If you're paying for the tokens, you should be able to use them.
And that's the entire vision of Cloudroom. You can use any model, any harness, any inference provider. And number two, so first of all, why nobody else did it.
the perverse incentives, right? These labs want to keep everything closed source and they will not open source their infra and definitely not their core of their infra fully on GitHub like we did right now. And we're already at 320 stars, by the way.
And the second reason why nobody else did it is that it's hard, right? It's very hard, right? You can have data loss while having so many different sandboxes.
And again, each of these is basically its own computer, right? If you don't understand what sandbox is, this is a Linux computer running in the cloud with persistent, internet connection where the agent has the full computer for himself, okay?
So spinning up hundreds of computers, constantly spinning them up and down, launching them, each one, persistent state, like, it's hard, okay? Data loss can happen if you don't know what you're doing. Speed, if it's, like, takes you 20 seconds to launch a new thread, you're not going to use it.
I showed you earlier how fast it is to launch a new cloud thread. We worked very hard to make this, like, nearly local speed, within half a second of launching a local thread.
That's how it needs to feel. Sync, having all of your repos and all of your API keys synced between your computer and your MacBook or Linux. Right now, we have full support for Mac and Linux.
So those are the two operating systems we support fully. Again, another thing, you need the sync. You need the same logins, right?
So again, codecs, code, code, whatever logins you're using in their CLIs, you need them. usable both on local and in cloud. So that's also very hard.
And by the way, you need all of these to work. If just one of these doesn't work, people are not going to use it, right? There's a reason why cloud agents have been around for, I don't know, a year or so, and most people still haven't migrated.
And that's because there's friction. And all it takes is for one of these to be not optimal, and people will not move their work over. So that's what I spent the last five or six weeks doing with Cloudroom, working closely with...
around 25 different beta testers, literally every day, like six to 10 hours every single day, just polishing and dogfooding this product so that all of these are as good as local. That really is the standard. It needs to be as good as local and in fact better because each agent has its own sandbox.
So who is Cloudroom for, right? It's not like competing with Muse or Instinct as a consumer product. Cloudroom is for power users.
It's for the serious builders, for entrepreneurs, for people who are already using multiple $200 a month subscriptions, right? So very simple question you can ask yourself, are you already paying $200 a month for Cloud Code and $200 a month for Codex? If you have at least two different $200 a month subscriptions, then Cloudroom is probably for you.
This is for people who already understand that the future of agents is cloud agents, who already understand that soon enough, all of us will be running hundreds. if not thousands of agents in parallel at the same time, launched by different triggers, not just typing manually on the keyboard, but some of them launched by webhooks, some routines, database outages, product improvements, new customers, different hooks, different situations, with different harnesses, different conditions, completely independent of the state of your laptop.
So the people who already understand that cloud agents are the future and are already power users of multiple $200 a month plans, this is... who I built Cloudroom for. So my job is not to convince you that cloud agents are the future.
It's going to be obvious to everybody over the next six to 12 months. The thing is, if you're that person who has multiple plans, and by the way, that's another thing we can touch on. It's very easy switching between multiple plans.
Here you can see the provider usage between your different subscriptions and you can see you can easily switch between multiple plans. So here I have two different cloud code plans. And I can switch between them because I just hit the limit on the 100.
So I switch to my main 200 and I can continue on there. You can see your limits. And yeah, so that's who Cloudroom is for.
And those who really want to be at the frontier of AI and want to maximize the amount of agents they're using. So again, you can go to cloudroom .dev, start for free, you know, try to push it to the limits. Once you need more agents, you know, you can see the differences on the pricing page.
Start with the pro plan or get to the ultra plan if you want direct access to me and my team. Everybody on the ultra plan gets a dedicated Slack channel with direct access to me so you can shape the product, you can report any bugs, features, we'll fix it like within a couple of hours. So that's who Cloudroom is for.
Now, why is the future of agents in the cloud, right? Again, this might not be obvious. Well, you have to think about the shifting usage patterns.
Like not all of us are using agents. At the frontier. So, if you think about a year back, or six months back, all of our agent usage was basically like this.
Analyze this repo and build a feature. Right? You're just prompting an agent.
And this is like you, one at a time, unblocking one agent at a time. And that's not scalable at all. Literally here, I have like, let me just ask.
Use room CLI and tell me how many open agents, open agent threads, I have inside of a slash code slash cloud room right now. Answer in short, don't leak any private stuff. I'm recording a YouTube video.
I'm actually curious how many agents I have right now. And that will make you understand you cannot be unblocking them one at a time. It's possible if you have like five agents, maybe 10.
But as soon as you go beyond 20 or 30, you can go crazy, right? Trust me, I tried. Right now I have 201 open threads, right?
So we need different solutions. We need different ways agents are started. And the way we use...
Today, agents on the laptop is not going to be the same as in six months, in 12 months, in 18 months. Mainly, the way agents are started are not going to be by humans. Because again, I think it's like the Dunbar number where like you can only remember 150 things, right?
So that's like 150 people in your life. It's similar with the agents. Like after you go beyond, you know, 50 or 100, you can completely lose track of like, what was this threat?
Like, what was I doing in this threat? And by the way, in Cloudroom, we have features like purpose, where you can hover over the name and see the purpose of the thread and what percentage it was done. Again, I think pretty...
I'm very certain we're the only AI coding tool in the world that has this, because I literally built it like two days ago. But that's one thing, right? Shifting usage patterns.
In the future, most of our agents will be launched by themselves or by some trigger or by some event, by some rule, by some instruction, by a software factory we've built, by a Gentic loop we have running. not by you and me unblocking each agent and one. I mean, think about a company with like 5 ,000 developers.
You think the CEO is telling each of those programmers one by one what to do? Of course not. There's multi -layered management structure.
Some of these people are self -starters. Some of them are like their work gets started by a customer feedback and stuff like that. Same thing will be by agents.
Everything in the AI field so far has been kind of inspired. by the human brain and by people, right? Neural networks literally inspired by the human brain.
And that's the same thing it's going to be with multi -agent management. Once we're running thousands of agents, you're not going to be unblocking each one at a time. Some of these are going to get reviewed automatically by a different agent.
Some of these are going to get launched by like a manager or like a director agent. Some of them will just get self -started, analyze some state of your database or health of the system, and then self -archive, right? There's going to be completely different usage patterns in the future.
And for that, you need a persistent environment, something that's running always and has a stable internet connection, fast internet connection. In fact, all of these sandboxes have like 10 gigabit or 15 gigabit per second. So extremely fast internet connection and like 99 .99 % uptime basically, where it's always available, right?
Your agents need to be always available because as your agents are doing more tasks in your life and business, you cannot have agents not running. And if they're on your laptop, how common is it your laptop is out of battery or you need to close it to go somewhere or you go to a cafe and the wi -fi is trash can happen all the time and it happens to me every single day and that's why cloud agents are the future especially as more of them run in software factories and agent loops and again i made a whole video on this like a couple days ago literally two days ago so if you want watch it after this video if you're more interested in software factories so let me show you how easy it is to actually build like a mini software factory or agent loop inside of cloudroom because What I showed you so far is the current way of working, right?
So I want to prove it to you. This is the best tool in the world at doing agentic engineering today. It's also the best tool for the future.
We have what we call an automation, automations, but this is really like agentic engineering. This is like the next era of agentic engineering. So a better word would be like a agent loop or , where basically you can select different triggers, such as, I mean, these are like running on a schedule.
So for example, Discord slowness monitor, checking why my Discord is lagging. I don't know how it started happening today. I just built a simple agent loop for that.
We have some, some of these are paused. Oh yeah, I think because they were launching, they were launching like customer information. So I paused it before recording.
But yeah, okay, this one is interesting. So it scrapes a archive with Deep API every single or every other day at 8 a .m. launches a new cloud thread, and I can show you how that looks like, so I can run it now, and sees what's happening on archive and what is relevant to me.
So I have, like, next to little, I have basically no time, no extra time. I'm already working from the day I wake up to the day I go to sleep, willingly, by the way, so please, nobody worry about my health or anything. I'm heading to the gym every day.
But I want to... educate myself and improve myself at the same time right so how do i do this well i create an agenda loop that checks archive which is you know where the research papers are and sees like what is relevant to me you know what could be something that i'm interested in uh something that could educate me and it's running every two days i think that's enough some of these are like security issues or like i can show you how easy it is to spin up a new one actually so let's let's do cloud one because You know, these automations also need to be running in the cloud, so they always run.
And I'm going to show you how easy it is to create one, because forget about the UI. UI is a thing of the past, you know, like user interfaces for humans. This is not going to be the case.
Everything needs to be controllable. In fact, explain the Room CLI to me and how powerful it is and all the things you can do with it. All right, so this agent was started here.
This is from the automation. And look, it's analyzing the archive for this. specific period, last 48 hours.
I don't even understand it, right? I build it with an agent. So the agent knows what to do and it writes the scripts and the system prompts for that.
But everything is like CLI first, right? So Room CLI is the command line interface we have for agents where they can control everything inside of Cloud Room. So they can spawn more agents, schedule work with automations, reach my Mac.
That's another breakthrough feature that no other coding tool has. giving the cloud agents access to your Mac. So let's say you forget to attach a file or you told the agent to complete a certain task, but for the agent to complete that task, he needs to check your downloads folder and get a file from there or get a certain repo that's in your document or like get a dependency that's only installed on your MacBook, right?
Well, most cloud agents products would completely fail. You know, maybe you have an API key in the .env, .local, and you told the agent to, like, use it to do some research, and you didn't attach it, right? You didn't upload it to the cloud agent.
Most, even, like, cloud code, even codecs, even cursor, they would fail completely. Why? Because they don't let the cloud agents access the Mac.
Guess what? Inside of Cloud Room, we have this sorted with this feature where you can control how much access the agents get. So you can either turn it off completely.
You can do read -only, you can have them ask before changes, or you can do full access. So if they forget something, if they need to access something from your MacBook, they can do that at the level of, you know, permissions that you decide. And yeah, they can also handle secrets and do all that other stuff.
So everything is CLI first. So you can build new automations just by talking in plain English. And let me show you that, right?
Start a new automation that runs every 30 minutes. And make it use GPT 6 .1 Sol Max fast. And have it do a security review of all underlying dependencies.
Make sure it's a Clutter automation. And make sure it runs on this repo every 30 minutes. And checks one different dependency of this project.
To see if there's any like breaches or public exploits or anything like that. Build this automation right now. And make it active.
Boom. Just like that. Literally I spoke for like what?
20 seconds.
agentic loop, a new mini software factory. I mean, once you have a lot of agentic loops, it really starts to become a software factory, right? When you have like one or two, it's like, okay, you know, it's really agent automations.
But once you have 10, 20, 30, and again, I have like 40 different ones. Usually I don't have all of them turned on. Usually I have like 15 to 20 turned on.
At that point, it really is like a mini software factory where a lot of work is just starting completely without me and the agents go. And in fact, I'm going to upgrade it. Once you build automation, Make sure that anytime it runs and it finds something, it spawns a subagent with a different model.
Let's go with Opus 5 .5 Extra High through Cloud Code Harness. And it reviews what it found to see if it's a real issue or if it's just overthinking. And if it's overthinking, just archive both of the threads.
Boom. So you can have an automation where it launches whatever, every 30 minutes, every five hours, whatever you decide, right? In the future, we're going to add different support for different triggers.
So it's even more configurable, even more advanced. Really, I'm trying to build cloud infrastructure for AI agents. If you're, you know, paying attention to this video, you probably realize that.
But not just for the current day, what's in the future, because I'm telling you, in the future, most agents will not be started by us. We are going to move to higher level of work and we're going to be managing and orchestrating agents. So there it is.
Within, what, one minute, 17 seconds, created the automation and started it. Script lists all 220 dependencies. Okay, okay.
And then basically it's going to check one of them. And it already started here. So it's checking this one dependencies we have, Axiom.
And it's running Solmax, running on it. And this is another test. So you can see that how it works.
It's already working. And this automation will run, you know, every 30 minutes. It's called dependency watch.
You can see the harness, the model, and the reasoning effort here inside of automations. And yeah. I just created it literally within 20 seconds, just speaking in plain English.
And that's how you build software. Let me get this straight. It's not about this one thing.
It's about building multiple of these, right? And thinking about like, how would a 50 times bigger team look in a software company? Well, it would have security researchers.
It would have front -end engineers. It would have billing testing team. It will have product, missing product features, right?
It will have a team for performance and of testing. And by the way, you can see the nested cloud agents. This guy decided to launch the reviewer here with Opus 5 .5.
And you can see that it was copying the repo from Mac. So much stuff is happening so fast. This is Cloudroom.
This is what it feels like to use cloud agents. And all of this is running on isolated threads. None of it is touching my computer.
I'm completely chilling. I'm recording a 4K video right now with OBS, and I'm completely chilling right now. It's not overloading at all.
I don't even hear the fans. Why? Because all these agents, they're running in isolated client boxes.
isolated sandboxes in the cloud. You can see right here, the ones we started, we have awake 34 different agents, asleep 42. And yeah, just like that, very easy to create an automation that's already quite advanced, where it launches a frontier model from one AI lab, and then it checks it with another AI lab.
And if nothing happens, it self -archives. So it literally can do pen testing, product improvements, user feedback research. all without your involvement, right?
Only if there's like a serious issue that requires your judgment, you can tell it to wait for you or you can just tell it to fix it. Like if the fix is obvious and clear, you know, you can tell it when the issue has obvious clear fix, like, you know, when there's a dependency that has been breached and a new version has been patched, make sure that the main agent fixes it and updates right away and pushes to production.
You are fully in control. You can do whatever you want inside of Cloudroom. You can configure it the way you want.
That's what I mean. It's for power users. It's for people who want to run the maximum amount of agents and people who really want to be at the cutting edge of AI.
So I already talked about how laptop is the bottleneck. So let me just quickly go through it. Office analogy, right?
Imagine like as these agents are more and more powerful, it's really like a equivalent to a remote employee. So imagine you hire somebody to your team, to your company, and you say, oh, listen, bro, you're using this computer. And by the way, five other people on the team are using it.
Like that person would probably leave on day one. And that's how agents really feel. And by the way, as the models get more powerful, they will need more resources, right?
Each model will need more resources of its own. And especially with computer use. Computer use has been making massive progress in the last three or six months.
You know, Codex app really pioneering, but even open source solutions like Cua driver or browser harness. Anybody who has used computer use knows how annoying it can be when the agent just... does pop -ups or opens some apps or switches the focus of your screen or opens new browser tabs, it can be extremely annoying.
But it's also productive because you want these agents to use the browser, to use different apps, right? Well, the solution is give each agent its own computer, aka isolated cloud sandboxes. Also, nobody hosts a website on a laptop, right?
And a lot of the same reasons why apply for cloud agents. It's just convenient running them locally, right? With cloud code pioneering this.
and like tools like agent zero and then codec cli and hermes they just pioneered like the terminal and it's easy to install it it's complex for somebody to manage like infrastructure for many different users and make it work and make it cheap right that's why nobody else did it that's why nobody else bothered to do it and why nobody else open sourced it and definitely didn't do it with a free plan which is by the way free forever and i'm gonna work as hard as i can to make the free plan as powerful as it can be.
Obviously, it's costing me money, and it's going to be subsidized by people buying the Pro and Ultra, so if you're interested in that, please go to cloudroom .dev and do that. But really, there hasn't been any software, any company that's figured this until today. So let me explain the differences between working locally in the cloud, because it's not black and white, right?
I think a pretty safe prediction is that it's going to be like 9 to 10. 90 % of our work, let's say in six months, will be done in cloud agents. And maybe 10 % will be done locally, right?
Again, depends what type of work you do, what types of tasks you do. I have people on my team who are literally doing only cloud. They're doing only cloud threads because their work is like more research, more like, you know, knowledge work type of stuff.
And they don't need the local ever. And they literally have 100 % on cloud threads inside of Cloudroom. Now, for me, as you can see, I still use local.
right? Because, first of all, I'm developing Cloud Room, so sometimes I need to fix something, and I need to run it as a local thread, but it's not going to be, you know, like, there is use cases where local still makes sense, right? Like, I don't know, maybe you want to do something highly private, super private, or you want to do it on your own operating system, right?
Like, maybe like some Xcode development for macOS, where Apple only restricts it to, you know, Mac devices only. Certain situations, it makes sense to run local, or like a heavy a rendering job and if you have a powerful like Mac Studio or maxed out MacBook Pro, it makes sense to run it on that machine because it's going to be faster than if you run it on the Linux sandbox, right?
But literally for 90, maybe even 95 % of tasks, cloud is better. And you're going to feel that as you move some of your work over. And the way to do that is, by the way, one project at a time, right?
Don't try to like move everything over to the cloud. You're probably going to be annoyed. You're going to face some friction and it's going to be like a big jump, right?
Move. 10 % over, 20 % over, one project, two repos, three repos, and like every week move more and more over and see like, wow, it's actually possible, right? Like a lot of people I talked in the very early weeks of building Cloudroom, they thought that their work needed local.
But actually, as I probed more and dug deeper, I realized that like it's only a limitation of existing cloud solutions, right? Whether they used... cursor or amp or devin and they hit some limit and they felt okay well yeah that's the issue with cloud agents no that's the issue with that one implementation of cloud agents right a lot of the reasons why people think they need local just means there hasn't been good enough cloud agent solution so far and actually if there is you can do that work just as well with cloud agents if not better and by the way just to be very clear i'm still highly confident that Cloudroom is still the best tool for local development as well.
Like, as I'm showing you, I'm using it on many different local threads, and I'm going to show you, like, what machine are we on right now. Okay, so I want you to launch 100 different subagents, all on local, and make half of them codecs and half of them cloud code. The codecs ones, make them use GPT -6 Luna, and the cloud code ones, make them use...
Haiku 5 .5, and just ask them to research different competitors and just, you know, say the name of a single competitor, but tell them to not make any changes. Don't overthink it, just launch these 100 sub -agents right now below you. Sometimes you gotta tell the model to not overthink it, right?
So, I already demonstrated how much the cloud agents can handle, but let me show you that this is still the most powerful agentic engineering tool, AI coding tool. for local development as well. And a big part of that is because we built it on top of BB.
So huge shout out of BB and the founder. Great tool. After working with it for like a month, month and a half, I decided it's time to fork it and go even faster.
But a lot of these foundations are like hardened, are fully, like I have literally hundreds of hours inside of Cursor GUI. And when Fable came out, boom, there it is. Look at this.
okay so it launched the first uh oh it's going it launched the first uh batches it's going it's yeah this is this is probably gonna be um i'm gonna hear the fans soon because again these are running local so they're using my computer's hardware and cpu and gpu so uh it hopefully doesn't start lagging this recording but my point is i was using the competitors i was like hundreds of hours inside of the codex app and the cursor gi app which are some of the best GYs out there, some of the best experience out there.
And... As soon as... I'm just gonna tell it to...
No, actually, let me finish it. Let's finish it, okay? I think my MacBook can handle it.
As soon as I was running more than 15 worktrees inside of Cursor, the app was crashing. I was literally tweeting about this multiple times per day. The Cursor GY was crashing, and the team, I don't know, at the time, I think they were focused on Grogbot, so they didn't really care that much.
But... there were multiple memory leaks inside of Cursor, and that's like the most famous, most popular AI coding tool, right? Okay, so it launched all of them, we can see there's literally 100 different sub -agents here, so I'm gonna tell it, alright, now pause all of them right now, just stop them to make sure they're not running.
Cursor GUI had multiple memory leaks, right? Because it's like a fork of VS Code, so everything is a browser. It's not really optimized for this.
A lot of softwares that were built before, you know, really the Fable generation and GBD 5 .6 and then Astra, they were not built for the volume of agents that people are running. And especially with Opus 5 .5, and by the way, Fable 5 .5 is just around the corner, we're going to be running even more agents. Opus 5 .5 is so fast that any work finishes fast.
In terms of... how long it took maybe with Astra, which is slower, right? So I already used a lot of these tools and they have issues, right?
So for example, Cursor, the reason I use the Cursor GUI is because you could use Fable, you could use GPT, you could use Grog, you could use any model. But then after the acquisition, it's no longer the case. They're training their own models and now openly I ban them from using the latest GPT models.
So when Astra 6 .5 comes out, You cannot use it inside of Cursor, right? If you look at Codex, it's more performant than Cursor GUI, right?
Codex app doesn't crash nearly as much as the Cursor GUI does, but the main issue is you can only use GBD models. Right now, Anthropic has the best models. The 5 .5 series is great.
Again, Fable 5 .5 is right around the corner. So you cannot use them inside of Codex app. I mean, it's as simple as that, right?
Another issue is maybe you use Cloud app, right? Again, you can only use Cloud models, but... You can even do stuff like this.
You cannot control threads. Agents cannot control different agent threads inside of your Cloud Desktop. Who knows why?
I have no idea, but it's not possible. And a lot of the early beta testers coming to Cloud Room were switching away from Cloud Desktop for this very reason. Make sure to not launch any more of your sub -agents and just archive all of them right now.
I think I already told it to stop it and not archive it. Oh yeah, pause all of them. Okay.
And by the way, you can do queue, make your previous answer simpler and shorter. So you can be queuing messages, right? What day is it today?
No problem, multiple queuing messages. And if you want to present something like, by the way, what is my name, answer in short. Boom, you can do command enter and present it, right?
So even when my queue is loaded, you can present all of the stuff you know in Codex, in Cursor GUI, in Cloud Desktop. We have it all, okay? So I want to make it clear, even though...
cloud is in the name of cloud room and it's fully like cloud first, it is still the best agentic engineering tool for local. And I'm highly confident in making that statement because we've seen that even now with like a small number of beta testers, we have like pretty crazy invite rate, like literally like 11 to 15 % of users brought a friend and that friend joined, right?
So over like 25 % of people invited a friend between 11 % and 15 % of those actually joined, which is insane for an early product, like early stage startup, right? So, again, everyone will use Cloud Agents in the future.
It's inevitable, right? You'll either be an early adopter and start using them today, or you'll try again in six months. Like, the choice is yours.
And again, I want to stress this. Cloudroom is free and open source, right? You can literally go with the free plan.
You can even self -host it on your own hardware if you don't want to use a MySolution. It's completely fine. do whatever you want the architecture is fully open source also the gy is fully open source let me show that as well boom this is the gy repo explaining some of the architecture behind teleport and how that works both are fully open source apache 2 .0 license so you can fork them you can penetration test them you can do whatever you want with them and you can start on the free plan and it's going to be free forever plan um and again there's i'm going to make this clear i'm going to let people in waves right so when you download it it's going to be um Local threats are going to be available right away.
And that is going to be probably Q, depending on how much the demand is, right? If this video gets 20 ,000, 50 ,000 views, it's going to be a lot of people coming in. So I need to make sure we have capacity and we let in people gradually.
But so yeah, it could take a day or two before you get access to cloud threats on the free plan. Obviously, if you want to skip that and get instant access, both of the paid plans give you that.
Again, it's free, it's open source, and you can self -host it, you can fork it, you can stay on the free plan forever. Let me talk about the architecture a bit. Let's see, we're recording for 40 minutes.
So this is good because it's only for the most technical people at this point. So some of the technical decisions, right? Rust first, especially for the core.
You can see 78 % of it is in Rust to make it as fast as possible. Memory, safe language. Asians love Rust.
So yeah, that was some of the first things I knew I wanted to do. build it as much in Rust as possible. Also, it's very modular.
So the GUI, the web app, and the core are split into like separate apps, basically, separate code bases. So yeah, I already showed you the core and the GUI. Both are separate GitHub repos, which are fully open source.
And again, you can actually access this from the landing page on cloudroom .dev. Again, it's going to be the first link below the video. I need to drink as I'm speaking for 40 minutes straight.
So you can access the GitHub here and get started right here and right here.
The GUI app is as lightweight as possible. So as I showed you, it can handle hundreds of threads. I showed you.
Which one was it? This one? I showed you I would like 200 open.
I think this one. Yeah, 201 open threads. No problem, like nothing is lagging.
I can just scroll through it very easily. Long chats work normally. And even, okay, actually on top of these 200, I launched another 100 sub -agents.
So that was like over 300 open threads running. No problem. No problem.
No crashes. Very stable. Again, built on top of Bibi.
So major shout out to Bibi. Let me actually, I will just ask it. Give me a direct link to the official GitHub repo of Bibi.
Why even search for it when you have agents nowadays, right? You can just have them find it and give you a direct link. Boom, there it is.
So again, major shout out of BB. This is what it was built upon. So if you're already using BB, it's going to be very familiar to adopt Cloudroom.
Very easy. You just get, you know, free cloud compute, basically. Cloud threads on top of that.
As well as a lot of optimizations, such as, you know, these fast keyboard shortcuts where you can like... move stuff around and better UI and polishes because I'm very particular with the UI in UX and like what is possible and you know making sure that you can like translate for example context command from cloud code a lot of people want to use that a lot of these things we've built and improved on top of bb over the past five to six weeks so again a huge shout out of bb made it faster to use a great GUI to build on top of So that's the beauty of the open source software.
So I'd be, you know, if you fork, I mean, 46 people already forked Cloudroom, right? So if you decide to fork it and build on top of it, I'm more than happy with that. It's advancing everybody.
And that's why I call it like a technological breakthrough because this makes cloud agents more accessible for everybody. Something that OpenAI, OpenAI, Anthropic, Cursor, you know, Devin, Cognition, all of these companies had the opportunity to do this. but none of them did it.
So I'm doing it myself. Again, sandboxes, right? We already touched on that.
Essential architecture decision. Speed matters. So everything is as fast as local, you know, for power users, speed matters.
So all of that stuff is like key bind first. Everything's accessible very fast. Convenient keyboard shortcuts for everything.
So I'm going to show you, you can go like to the bottom thread with a keyboard. Like let's say I'm, let's say here, I can go to the bottom thread at the bottom. I can jump back to the top thread right here.
Boom. uh switch that like you can do command n for a new thread you can like go to settings and basically keybind everything keyboards right here look how many different things are possible to keybind um yeah really incredible get up friendly right everything is like compatible with github you can like import stuff from github very easily once you authenticate it macOS and Linux first.
So I think these are, by the way, the two operating systems. If you're not on one of these, I would recommend getting at least one computer that's Linux or macOS. Why?
Well, macOS is just stable and Apple has the best hardware. So when people are building complex software, they don't want to deal with some weird operating system quirks, right? So that's why a lot of the top engineers in AI already use MacBooks.
And also MacBooks are just the best for having the shared... memory between the CPU and GPU. So not only is the operating system very stable and predictable, and it just works, which is a very important value add.
So that's the value of macOS, right? Stable, predictable, it always works, highly performant. And then Linux, just super customizable, lightweight, open source.
Yeah, with like OMRG, you can see the trend of really building it as agent first. So these two are going to be more popular, very easy production to make. um windows unfortunately is going to become or maybe fortunately you know it's going to become less and less popular still in enterprise a lot of big companies use it but i'm talking about the power users people on the frontier everyone uses either mac os or linux so please if you don't have either of these machines pick one up it's going to be a good investment for the future and uh yeah also if you want more of the like technical stuff what we're doing we have a blog as well so it's a cloudroom .dev blog again i'm gonna link it as another link below the video so you can read more about what we're doing and some of the architectural choices we've made here and read through some of these blog posts we've written and yes all of them are written by hand by humans either me either by me or my founding engineer so all of them are you know real written stuff uh let's see what else is for technical people i think that's that's the main things about architecture again both the core and the
And the GUI are fully open source, so feel free to have your agent read through these GitHub repos and understand more about the architecture and some of the technical decisions we've made. So, okay, let me also show you this feature I mentioned earlier. This feature, right?
Very, very powerful. Simple idea. Very simple and elegant idea, but extremely powerful.
So I'm going to launch a cloud agent, and I'm going to have it do some local work and basically show... that like if it needs something from my laptop it can get it right so look to my macbook and let me know how many files are in my downloads folder right now something like that and also we can test it on the on the some of the threads right in terms of um it's okay downloads has four items whatever whatever List out the five most recent items without like leaking any private names.
I'm recording YouTube video right now. So just if there's something private or sensitive, like censored part of it. But what are the most five recent files in my downloads folder on my MacBook?
And like how far, when were they created?
And actually, if we do a new one, command N, boom, let me switch to the Cloudroom repo. I can say, how many, on my MacBook, in the, like main slash code folder how many projects do i have there answer in short so it cloned the you see it's called from github so everything is like git and github compatible and uh since the as i mentioned earlier the sandboxes have extremely fast internet i do recommend storing stuff on github and have the agents just pull it up very quickly.
So you have 85 folders in slash code. Okay, roughly 40 different projects. What is the total file size of all of these and these repos?
Answer in short.
40 of them are Cloudroom site copies, okay. Interesting. Check which of these Cloudroom site copies are...
Actually, I'm going to do even more interesting. go into the main slash code slash Cloudroom repo on my MacBook, find the branding folder in there and find the logo, the main logo in there, the PNG file, and open it in preview for me on my MacBook. So again, this is a cloud thread.
I need to stress this. This thread is running in the cloud. I just told him to, I'm going to actually pre -send this, like interrupt it, steer it.
I just told him to... find a specific folder and a specific file, and to open it. I'm having my hands off, guys.
I'll show you. This cloud agent running in a isolated cloud sandbox, because I gave it the full permissions right here, and that's fully in your control, it can do stuff on your MacBook if needed. And again, it's just following my instructions for whatever task.
If the task doesn't require it, it's never going to do it. But if it needs it, if you tell it to, it can get something from your MacBook. I think anthropic inference is slow.
Because again, Fable 5 .5 is about to get released. So I'm not sure why Opus is so slow. Because this is very unusual.
Opus is normally very fast. We can try it maybe with Codex. And by the way, you can just jump back.
Let's see here. Five newest items, PDF document, image, blah, blah, blah. Okay.
So times are based on a Mac right now. Yeah, so these are the... These are the names and I'm just gonna jump in the future to this thread.
I don't know. Maybe let me try it with With Saul Let's do hi Maybe anthropic is rolling out fable, which is unfortunate if I'm really missing it while recording But hey, maybe a fable video coming soon depends when it drops. I've seen some leaks on Twitter You never know if they're true or not.
But yeah codex is working. So I don't know what's going on with anthropic But you can see now it's using the Cloud Mac skill to access my MacBook.
Then it's going to find the right repo. And I don't even, like, honestly, I overdescribe it. Like, you can be even more vague, right?
These powerful models, as long as you're using frontier models, they'll just figure it out. If they need to do something, they can figure it out. And again, my hands are off.
I'm not doing anything. I want to show you that this cloud agent running in a cloud thread can not only, like, find files and, you know, list out how many things are in my downloads. It can also open apps and fix stuff on my computer.
Again, if the permission level is enabled for that. Boom, there it is. Self -opened.
I was not touching my mouse or keyboard. It opened the logo on my computer. This is, you know, live on my MacBook.
And yeah, this is a cloud threat, right? Like say like, oh, by the way, what machine are you on? Like, are you running right now?
Just to confirm, this is not an agent running locally. It's running in the cloud. I want a Cloudroom VM, not your MacBook.
Okay, so yeah, I think you get the point. Okay, that's the slow one. So I don't know what happened.
The Opus one showed it as well. So yeah, just to update you guys, I'm going to wrap up so it's not too long. Cloudroom is my next big bet.
This is my full focus, literally where 80 to 90 % of my time is going towards. This is my next AI startup. I'm going to be building it between San Francisco and Poland.
And right now we're hiring. So I'm going to leave the email below the video. So if you're actually interested, we're hiring like developer roles, you know, engineers, but also content roles like YouTube strategists, video editors.
So honestly, anybody, like if you're talented, if you're locked in, if you're serious about AI and you're hardworking, just email me, okay? The email is going to be in the description. Introduce yourself, give your experience, tell me what role you're applying in.
Be as concise as possible, okay? So yeah, this is my next big project. I'm probably going to raise the first, I mean, right now we're fully bootstrapped, right?
We're a very lean team. I don't need to raise money. You know, obviously my existing businesses are doing well, but to move faster, I'm thinking I'm going to maybe raise the first round in December or January.
We're going to see how things go. Obviously, the biggest cost here is going to be the cloud compute by trying to make the free plan as powerful as possible, providing kind of the super -based business model, right? Super -based, they have a free plan as well, store like, I think, two different databases completely for free forever on Supabase.
But then, you know, after you hit certain limits, if you want to scale, you buy one of the paid plans. Same idea is for Cloudroom. And also it's fully open source, just like Supabase.
So to keep the free plan available and to make it as good as possible, that's going to cost a lot of money. So yes, I'm going to try to subsidize it by people who, you know, need more and buy the paid plans, obviously. But these also cost money because, you know, we're providing a lot of cloud compute for these as well.
I don't even know if they're going to be profitable. We're going to see, I guess, after I launch this video, once we have more usage data. But yeah, that would be the main argument for me, raising proper venture capital in December or January, is to support the compute costs, as well as aggressively hiring the best talent in the world.
So again, if you're interested in joining me, the email for that is going to be below the video. So just be very concise, please, and introduce yourself. Bonus points if you include a short video recording of who you are.
So yeah, this is Cloudroom. This is what I've been working on for the past five or six weeks. And really more than that, like probably this is like a combination of different projects because I was releasing like a small open source projects underneath my private GitHub as well as the like Vector Labs for the past three months, let's say.
And this is like the combination of that, right? The idea wasn't really clear what it's going to be over that period.
Over those weeks and months, it kind of crystallized into open source cloud agents and, you know, giving it the name Cloud Room. So probably like two to three months of work of really different open source projects and working on the main issue of agents must be running, right? I had this idea, I was like, the models are good enough.
The harnesses are good enough. What's missing? What is preventing us from running thousands of agents productively?
That's the important word is productively. Anybody can spin up. thousands of deep seek v4 .1 to just do random useless stuff, right?
The key is to have them do real meaningful work that you would pay for. Useful stuff to actually take your life and business to the next level. So thousand, like why aren't we running thousands of agents productively?
That was like bothering me for many, many weeks because again, with Fable and Astra and Opus 5 .5, the models are good enough. The harnesses are good enough. So what is missing?
The answer is everything else. All the other friction, right? Your computer disconnects from the internet.
Your computer overheats. Agents are fighting because you're running too many agents. Your computer needs to be closed so the agents stop running.
Agents need to be running. This should be a crime. Agents stop running.
All of these different reasons is why you cannot reach a thousand agents running productively. And obviously many other reasons which we're going to solve along the way. But all of these kind of two to three months of effort culminated in this one idea of Cloudroom.
And again, heavy testing over the last five weeks with my team and with around 20 beta testers. So shout out everybody who was a beta tester, who got early access. Highly appreciate the feedback.
And obviously I still, anybody watching this, you guys will be the first wave of users. You have the opportunity to shape this product. So please send me feedback.
In fact, there is a tool for this. I'm going to show you. It's called, well, you can just literally use it from any project.
You can report a bug right here. And using the feedback tool, report the following thing to David, the founder of Cloudroom. You can literally just say that.
Say like, today the app was feeling a bit slow. I don't know what's happening. Usually it's fast, but today it was feeling slow for me in the cloud threads.
And you can tell your agent, send this to David or send this feedback to David. It has a tool in the room CLI. where it can send feedback to me.
It goes to my Postgres database where it's a table. And then I have a cloud automation, which runs every 10 minutes. It's paused right now because again, I paused my main automations because they were leaking private info and like customer emails.
So I paused them before recording this. Normally I have like, again, 15 to 20 of these active. But you can say like, I sent David your report, CloudFest first slot today, even usually fast, right?
And then within 10 minutes, In my own cloud room, what would happen is a new thread would start investigating that customer report. So please, anytime you have any issue or bug or error, just tell your agent, yo, send this to David, you know, we encountered a bug.
Or send this to David, I have this feature idea. And your own agent already knows what to do. This is really the future of product.
And this is why, by the way, guys, all of you, no matter what you're building, you need to have these agentic loops. And you need to start building your own software factory. And I'm going to be working hard to build.
the infra for that. So it's easy for you guys to build these software factories and to really adopt the next generation. I don't know what to call it, like agenting engineering 2 .0.
It really is the next generation of building software and of using agents. It's like orchestrating large number of agents, creating the logic and the rules while they run and managing large amounts of agents without like starting each of them one by one. So yeah, this is Cloudroom.
It's really built for power users. Ultra power users, right? The superpower users, the people who are paying $400, $600, $800 a month or more for, you know, codecs or cloud subscriptions or cursor subscriptions, just AI inference.
If you're spending more than $400 a month on AI inference, you are the target avatar. If you're a business owner who wants to heavily adopt AI across himself and his entire team, you are the target avatar. This is not for consumers.
This is not for beginners. You know, I'm not trying to compete with news or instinct or stuff like that. This really is for the heavy power users.
And yeah, if that's you, go ahead and try the Pro plan and Ultra plan. Again, as I mentioned, these two plans include personalized onboarding, either with me or my founding engineer, whoever is available. And if you're on the Ultra plan, you get a Slack channel with me in it, so you can talk to me directly and my team as well.
So, you know, any issues that you or your team is facing are going to get solved within a couple of hours. because I have a lot of agents running, right? So I can do stuff like that and have insane leverage on my time.
So yeah, this is Cloudroom. Again, if you want to try it out, go to cloudroom .dev. Feel free to try on the free plan.
And if you're a serious builder, go with the pro plan or the ultra plan. So with that being said, thank you guys for watching and yeah, go and try it. Cloudroom .dev, first link below the video.
The Hook
The bait, then the rug-pull.
There is no cold open and no setup. The first sentence is the product name, and by second forty the host has launched five agents on five different harnesses and asked each one what machine it is running on. The rest of the hour is the argument underneath that demo: that the thing capping how many agents you can run was never the model.
Named ideas worth stealing.
05:18list
Three reasons to isolate every agent
- Scalability: a fixed machine has a fixed agent ceiling, a VM per agent has none
- Security: a prompt-injected or malware-infected agent is trapped in its own box
- Non-interference: no dirty primary checkout, no one agent eating CPU with database tests
The architectural argument the whole product rests on. Each point maps to a failure people hit in order as they scale from one agent to fifty.
Steal forany pitch where the right architecture needs defending against a cheaper-looking shortcut
11:00model
Why nobody else did it
- Perverse incentives: labs training models want the data and the lock-in, so they stay closed
- It's genuinely hard: data loss across hundreds of ephemeral VMs
- Launch speed has to be near-local or people won't use it
- Repos, API keys and CLI logins have to sync across local and cloud
- All of them have to work at once, because one weak link stops migration
A two-part explanation of a market gap: part motive, part difficulty. The all-or-nothing clause is the real insight, and it explains why a year-old category still has low adoption.
Steal forexplaining why an obvious-looking product doesn't exist yet
14:36concept
The target avatar filter
- Already paying for two or more $200/month coding subscriptions
- Spending $400+/month on AI inference total
- A business owner rolling AI across a whole team
- Already believes cloud agents are inevitable
A disqualification test stated as a dollar threshold rather than a job title, which lets a viewer self-select in or out in one sentence.
Steal forany offer page where you want the wrong buyer to leave before they buy
20:54model
The agent loop recipe
- A trigger: schedule, webhook, event or system state
- A cloud thread so it runs regardless of your laptop
- A narrow job with an explicit scope, like one dependency per run
- A reviewer subagent on a different lab's model to check the finding
- A terminal rule: escalate, auto-fix and push, or self-archive both threads
The structure of a single automation, built live in about a minute of spoken English. Repeat it ten to twenty times and the host calls the result a software factory.
Steal forany recurring review task you currently do by hand
31:39concept
The 90/10 migration plan
- Assume roughly 90% of work moves to cloud within six months
- Keep local for privacy-critical work, OS-locked builds like Xcode, and heavy rendering on strong hardware
- Migrate one project at a time, not the whole stack
- Add a repo or two each week and let the friction surface gradually
The adoption advice is the useful half. A big-bang migration generates enough friction that people quit and blame the category instead of the sequencing.
Steal forrolling out any infrastructure change to yourself or a team
41:15list
Architecture decisions
- Rust-first core, roughly 78% of the codebase, for speed and memory safety
- Modular split: core, GUI and web app as separate repos
- Deliberately lightweight GUI that holds 300-plus open threads without lag
- Keybind-first navigation because power users measure in keystrokes
- GitHub-native, so sandboxes pull repos over fast links instead of syncing files
- macOS and Linux only
Each choice traces back to a failure mode in an incumbent, most pointedly the lightweight GUI versus a VS Code fork that crashed past fifteen worktrees.
Steal forwriting a technical decisions post that reads as positioning
How they asked for the click.
VERBAL ASK
59:02product
“So again, if you want to try it out, go to cloudroom.dev. Feel free to try on the free plan. And if you're a serious builder, go with the pro plan or the ultra plan.”
The ask runs three times across the hour and never softens. Free plan first, paid plans named with the specific benefit attached, and a disqualifying line right before it so the wrong buyer leaves on their own.
MENTIONED ON CAMERA
Visual structure at a glance.
