Try Turborg Free → Open App →
← All posts

I moved my AI coding agent to a cheap cloud shell and it finally stopped crashing

July 19, 2026 · 5 min read · The xShellz Team

I was genuinely excited when borg, the AI terminal coding agent from xShellz, first dropped. A tool that could autonomously read my codebase, run builds, fix tests, and generate pull requests sounded like a force multiplier. In practice, on a 16 GB MacBook Pro, it kept turning my machine into a heater that couldn't decide whether to build my project or just page itself to death. The agent itself, a local LLM (or even an API client juggling large context windows), plus Docker containers for isolated environments, plus my editor and a browser full of tabs would push memory pressure into the red. The fan noise became the soundtrack of "I'm trying to work here." Then the OOM killer would step in.

Moving the whole thing off my laptop and into a dedicated, persistent cloud shell changed everything. It's a small architectural shift but it redefines what an AI agent can actually do for you.

The local-first assumption breaks with AI agents

Traditional dev loops are bursty: edit, save, run a local server, write a test, repeat. My machine could handle that for almost anything short of a massive monolith. But an AI coding agent operates in long-lived, computationally greedy cycles. It reads large swaths of a codebase, spins up subprocesses, runs linters and build tools inside containers, and often keeps an LLM inference engine warm in the background. It doesn't pause just because you want to check Twitter.

On a local setup, contention is brutal. Docker for Mac's VM ballooning, the agent's Node or Python runtime, and any local model server are all fighting for the same RAM. The moment a swap storm starts, the agent's responses slow to a crawl, the shell becomes unresponsive, and eventually something crashes. You can try to tune limits, but you're still sharing a single machine's finite resources with your own desktop work. The bottleneck isn't the agent's logic; it's the hardware you're sitting in front of.

What a remote shell gives you that your laptop can't

A cloud shell instance, whether it's a $5 Linode, a Hetzner box, or a managed service like xShellz, flips the resource model:

  • Dedicated CPU and RAM for the agent and its containers, completely isolated from your laptop.
  • Persistent sessions via tmux or screen. You attach and detach without losing state. The agent keeps running while you close your laptop and go to bed. When you reconnect in the morning, you see the full log, not a dead process.
  • Always-on networking. No VPN reconnects or IP changes when you switch Wi-Fi. The agent can push to Git, call APIs, and stay connected to IRC or Slack without interruption.
  • Consistent environment. You configure development tooling once. No drift between your Mac and a Linux server because the agent lives on the same Linux host.

I'm not saying your laptop becomes irrelevant. I still edit locally and push code. But the heavy lifting, the multi-minute builds, the AI agent's long reasoning passes, and any background monitoring all live on the remote shell. My laptop stays quiet, and I can actually think.

A concrete workflow: borg in a tmux session

Here's what a typical session looks like after you've set up a remote shell with borg (and tmux) installed:

ssh [email protected]    # or your own VM
tmux new -s borg-task

Inside that tmux window, I'll start borg on a feature branch:

cd ~/projects/my-api
git checkout -b feat/add-rate-limiting
borg --apply-changes --context "Implement rate limiting as described in issue #42"

Borg will analyze the code, propose file edits, run tests inside a container, iterate, and potentially auto-commit once everything passes. That process might take 20 minutes or run overnight if it's a complex change. I detach with Ctrl-b d and close my laptop.

Next morning, I reconnect, attach to the session (tmux attach -t borg-task), and see the results. The agent has already created a pull request with passing CI. I didn't have to leave a laptop plugged in with "never sleep" settings, and I didn't wake up to an unresponsive machine.

This pattern works equally well for long-running data processing scripts, model training, or just keeping a Jupyter kernel alive. The key is that the remote shell becomes the persistent execution layer. Your local terminal is just a window into it.

Trade-offs you actually care about

No architectural shift is free of downsides. Here's what I've noticed:

  • Latency over SSH. Typing is slightly laggier than a local terminal, especially if the remote host is far away. It's fine for command execution but annoying if you're using a heavy terminal UI. I solve this by leaning on tmux's scrollback and copy mode rather than relying on pixel-perfect responsiveness.
  • Cost. A cloud shell costs money, usually a few dollars a month. For me, that's more than worth reclaiming my laptop's performance and getting unattended agent runs. If you're just running things occasionally, spin up a VM on demand.
  • Security scope. You're trusting a remote host with your source code and access tokens. Choose a provider with SSH key management, consider restricting access by IP, and don't put sensitive secrets in plain environment variables. Same as any CI server.

For the specific case of AI coding agents, the biggest benefit is continuity. An autonomous agent needs time to work, often uninterrupted hours. That's simply not possible on a machine that travels with you and sleeps when the lid closes.

Where xShellz fits in

I ended up using xShellz's managed cloud shells because they come with borg already integrated and tmux sessions that persist across disconnects by default. The shell stays alive even when I'm not connected, and it includes an always-on IRC bouncer (ZNC) which is a nice bonus if you hang out in developer IRC channels. But the core idea stands regardless: offloading your AI agent and heavy tools to a remote Linux instance frees your local machine and gives the agent the runtime it needs to be genuinely useful.

If you're still running your AI coding agent on the same box you use for Spotify and Slack, try moving it to a cloud shell for a week. You'll probably wonder why you didn't do it sooner.