How I Run AI Agents in the Cloud Without Leaving Claude Code (with Aether) Transcript, AI Summary & Key Points

00:07 I run AI agents on a machine that does nothing nothing else. Not my laptop. A dedicated box sitting in the corner whose entire job is to run agents while I get on with something else. It's a good setup and it's cheap. I paid for that box once. Renting equivalent by the month would have cost me more than the box did within a few months probably. And then it would have kept costing.

00:33 It also has a ceiling. Not a ceiling on how many agents I can have open though. The number that matters is how many of them are compiling, running tests or otherwise doing real work at the same moment. Once that gets to five or six, they start fighting each other for CPU, memory and disk and everything grinds or it breaks completely. So, what do we do when we want to run more agents than the laptop or the server they're on can handle?

01:06 Hmm? The obvious answer is to buy a bigger machine. Now, I don't want to buy a bigger machine. I hit that ceiling maybe twice a week, once, maybe not at all during some weeks. Most days four or five of them are actually building anything at once and buying hardware that sits idle six days out of seven to cover the seventh day that is is is exactly the mistake we spent a decade learning not to make with servers, right?

01:35 The other answer is the one we landed on with servers. Keep the steady state on hardware you own and rented the overflow when you need it. That works for agents as well. What's much less obvious is how you keep control of the rented ones because the moment your agents are somewhere else, most tools want you to go and look at them somewhere else, too.

01:59 In a browser, in their dashboard, not in the agent you actually use. So, I'm not switching. I use Claude Code, I use Open Code, I put real time and getting good at both into the prompts, the skills, the muscle memory. If you want me to drop all of that, all of that, and work inside your web interface instead, it had better be bloody spectacular, not adequate, not reasonable alternative, better than what they already have, or I'm not moving.

02:29 I'm not going anywhere. A dashboard with a list of tasks on it is not a reason to abandon the tool I live in all day. It's a reason to close the tab. That's what I wanted to find out, whether I can borrow somebody else's machine without giving up the thing I actually work in. The answer turned out to be mostly yes. And the mostly is the interesting part.

02:59 My dedicated machine runs Agent Deck, which is a thing I built to manage a fleet of agents from one place. It gives every agent a pain and a work tree of its own and lets me jump into any of them whenever I want to see what's what's going on. So, let's give it some work. A product requirement document and a couple of issues that I will let it choose for itself.

03:24 Each of those become its own agent in its own work tree, cut from the same commit on main. Now, the PRD is not one agent. A document like that gets split across roles because asking a single agent to write the code, test it, review it, audit, and release it tends to produce an agent that marks its own homework, right? So, there's an orchestrator, a coder, a reviewer, an auditor, a tester, and a release agent.

03:49 All all all all of them working on the same PRD. Add it up. One PRD and two issues turned into nine agents, all on that machine, and I can attach to any of them and watch. Now, nine sounds like a lot, and it's the wrong number to look at because check the counters at the bottom. Uh only some of those agents are working at any given moment. The rest are idle because a reviewer has nothing to review until the coder is finished, and a release agent has nothing to release until the tester says so.

04:21 What actually costs me is the handful that are compiling and running tests at the same time. And that is what's close to the limit here. So, what I need is somewhere to send the overflow. Not a different way of working, not a different tool, not a browser tab. The same agent, the same agent I'm already talking to, pointed at machines that are not mine.

04:46 That's what I want. Eater runs coding agents on machines you don't own. One micro VM per task, created when the work starts and destroyed when it's finished. Think of it like serverless, except the workload isn't a request that comes back in milliseconds. It's an agent that runs for minutes or hours or occasionally days, and that might need to ask you something halfway through.

05:15 That last part turns out to matter more than I expected. I tried it a while and gave up almost immediately. Almost immediately because using it meant leaving Cloud Code and doing everything in their web UI. Now, it changed since then, and now I can drive their agents from whichever agent I'm already using, which is the only reason the only reason we're having this conversation.

05:40 So, same session, same agent, same window. I just point to the next batch somewhere else. 10 tasks accepted covering 12 issues, each one on its own branch, cut from main, each with a link to the machine that's working on it. Notice what just happened because it will matter for the conversation later. I know I needed more capacity. What I never got to say is how much.

06:11 All 10 of those tasks spent out at whatever size the project happens to be set to. The same size, the same size for every one of them. Maybe that's the right size for all 10. Who knows? Nobody worked it out. Though, it it's just a number that was already sitting in the box. Nobody asked me and my agent couldn't ask either because the size isn't something it can see.

06:34 If that would be a parameter that Ether exposes, I would expect my agent to notice and then either pick one itself or turn around and ask me which one I wanted. It had just read all 10 issues and it knows what this repository puts every single commit through and it could make a far better, far better guess than a project-wide default can. Anyway, that was a segue.

07:07 What happened after that is that I went to bed. I went to sleep. The next morning, this was waiting for me. There are two things in it worth looking for. The first is agent deck telling my agent directly that a unit dispatched has finished and handing over the report. That's the easy case, though. Those agents are running on the same machine as the agent that dispatched them.

07:33 So, there's a demon in the middle that can just walk over and tap it, you know, on the shoulder. The second is the Eiter check firing when the session stopped and failing. Eiter delegation check failed. Check your connection and Eiter login. Unread updates remain available. There were updates waiting. And my agent never ever ever ever ever saw them.

08:04 Now, that matters more than a missed notification. I live in these agents now, and what they want from them isn't a heads-up, right? It's action. Review the pull request that came back. Merge the clean ones. Cut a release. None of that happens if the agent doesn't know that the work finished. And if one of those remote agents had got stuck overnight instead, I wouldn't have found out by looking at the place I actually look, and nothing nothing would have moved until I noticed and went digging.

08:37 So, I went looking myself, starting with my email because there was nowhere else obvious to start. That one over there, that one is from GitHub, not from Eiter. One of the remote agents had left a comment on its own pull request, and it's a good comment at that, right? Ev- every check is green, the one review finding fixed, and its thread resolved. Beautiful.

09:03 And they only read and this is the problem. I only read that email because I was already hunting for something. On any other morning, that email gets deleted unread along with every other GitHub notification that isn't a human opening an issue or a pull request. So, the one signal that made it through overnight is a signal I routinely throw away without looking at it.

09:26 Now, I will cut cut them some slack on that. Driving Eiter from a client agent instead of their web UI is new, and I would expect this edge to get sanded down soon, hopefully. So, I'm giving you a slack. Your new project, at least this feature. So, I went back to my own agent, right? The one that is oblivious what's happening in Ether, what's going on with those 10 issues, and I asked it directly.

09:53 Hey, 10 issues, 10 pull requests, every one of them green. That answer That answer over there is the argument for driving all of this from your own agent instead of somebody's website. Not because of web UI couldn't show me that table. It has the same connection to my repository that I do, and somebody could build that screen. Is that I never asked for a table, I asked a question in whatever words came to mind at the time, and I could have asked a completely different one.

10:20 Which of these touch the demon protocol? Which are safe to merge first? Merge the clean ones and tell me what's left. A screen gives you what somebody decided in advance that I would like to see. An agent gives you what you actually asked for, and then does the next thing you ask. Now, none of what I like or dislike here is really about Ether. It's about the model underneath it.

10:51 Running the X-ray agents on machines you don't own and renting them only for as long as the work takes. That's the mission. The obvious win is parallelism past what many single box will tolerate. 10 agents compiling the same Rust workspace at the same time is not something I'm doing at home. Close behind is isolation. One agent that decides to run the full test suite in a loop cannot starve the other nine because it doesn't share anything with them.

11:25 On one machine, it absolutely can. Then and then there's the fact that my machine stays mine. The work happens somewhere else. So, the thing in front of me doesn't turn into a space space heater, right? While I'm trying to use it. And if you're running agents on the machine you actually work on, which is most people, there's a bigger version of that.

11:50 Agents somewhere else cannot reach your files, your keys, or the 11 other repositories you have checked out. I solved that part by giving them a box of their own. Renting solves it as well. And the money works the way renting always works. I pay for the peak instead of buying it, and the rest of the week I pay nothing. Now, the one I feel most is that I cannot just look.

12:19 I'm not asking to sit and watch agents work. I'm not asking for that. The more autonomous they get, the less anyone does that. But, they ask questions, they ask for approvals, they fail. And when something has gone wrong, I want the whole context in front of me, not a summary of it. I can get it by asking my client agent to go and fetch it from the remote one, and that works.

12:47 It's a round trip and a wait every single time, where on my machine it's it's just one keystroke. Then, >> [snorts] >> nothing is watching the whole fleet. Nothing. Agent Deck knows what's running on my box. Eater knows what's running on theirs. Nothing sees both. So, I'm the scheduler. I'm the one who noticed my own machine was saturated, decided the rest had to go somewhere else, and moved it across by hand.

13:16 I'll be doing exactly the same thing again tomorrow. Now, related and then kind of worse, my agent cannot choose the machine. It read the issue, it knows the repository, and it knows what this particular change will likely actually cost to verify, which is the only thing that matters. But the tool it calls to dispatch the work doesn't take a machine size.

13:41 So, the task goes out at whatever default someone set for the whole repository. One setting, every single task, forever and ever and ever. An agent can only act on what its tools put in front of it. And that that that's a general lesson here, rather than a complaint about one product. The participant with the most context about the work is the one most likely to be left out of the decision.

14:14 Not good. To be specific about where I hit that, since I only tested one of these, uh Eater, and Eater does have machine sizes, and I can set one from the command line. What they cannot do is let my agent set one, because the tool it calls to create a task doesn't take that parameter. So, every task inherits the project default. Other platforms may uh well handle it uh differently.

14:40 I don't know. I haven't checked all of them. And here's the thing, really. Nothing nothing reaches back. When work out there finishes, or gets stuck, or needs an answer from me, it has to find its way into the agent I'm actually sitting in front of. That's the other half of the first problem. I cannot easily reach in, and it cannot reliably reach out.

15:07 And between those two, I end up checking on things that were supposed to free me from checking on things. And your code your code is on somebody else's computer. To get any of this working, you hand the third party a credential that can act as you against your repositories. That's a trade we make all the time with CI, with hosted runners, with every service any of us ever signed up to.

15:35 That doesn't make it wrong. It does make it a decision. Aware. You need to be aware of it. So, here's the trade. I can reach into any pane on my own machine with one keystroke and I cannot reach into a single one of the 10 that run overnight. What I got in exchange is work that actually got done properly on machines I never bought. And it's cheaper as long as you're honest about what you're using it for.

16:06 Renting wins at the peak. If the peak turns into everyday, that arithmetic flips and you should go and buy yourself another box, exactly the way it has always worked with servers. Which is the answer to the question I started with. You don't move your agents somewhere else. You keep the ones you want to stay close to and you rent machines for the rest. Thank you for watching. See you in the next one. Cheers.