Lalit Maganti (Tag: Llm)

The surprising attention on sprites, exe.dev, and shellbox

Thu, 29 Jan 2026 00:34:22 +0000

Over the last few weeks, three new products have announced themselves on Hacker News to great success, each making the frontpage:

Sprites (fly.io) with 508 votes and hit #7
exe.dev with 457 votes and hit #2
shellbox.dev with 316 votes and hit #4

All three have a very simple pitch: they will give you full access to Linux virtual machines to act as a sandboxed developer environment in the cloud.

At first glance, the attention these have gotten is very head-scratching. The idea of a Linux VPS has been around for more than 20 years at this point and VPS providers like DigitalOcean and Hetzner are widely known and used in the industry. From a technological standpoint, there’s very little revolutionary here.

Is it price then? Well no: the hardware specs are pretty awful for what you pay. For example, exe.dev gives you 2 CPUs and 8GB RAM shared across your whole account for $20/month. For comparison, at Hetzner for roughly that price, you can get a single VPS with 16 CPUs and 32GB RAM…

And moving a local dev environment to the cloud has real downsides: added latency, needing a network connection, making graphical access painful. If all you wanted was the ability to partition hardware resources, we’ve had VMs and containers for more than a decade. You can use Docker on any decent Linux machine and spin up containers to your heart’s content. And with apple/container, it’s very easy to launch a semi-sandboxed Linux environment on macOS too.

So why is there so much excitement around fancy VPSes?

Why the criticisms miss the point#

The real reasons are two-fold: we’re in the age of AI and the user experience of these products.

First, sandboxing. If you’re using LLM coding agents and you’re not looking to YOLO things, sandboxing matters. Most prominently, Simon Willison has been beating the drum on the security risks of agents, with sandboxing being a good way to cut off the “Access to Private Data” part of the Lethal Trifecta. Segregating to a fresh VM, while by no means perfect, significantly limits the blast radius compared to using your personal dev machine if something goes wrong.

Second, there’s been an explosion in prototyping projects due to tools like Claude Code and Codex. They make it so easy to spin things up that developers want more “fresh starts” instead of piling features onto existing projects. And if an experiment doesn’t work out, you just delete the machine and start over without figuring out how to clean up.

But why these new services over a traditional VPS? Speed. All three are optimized to get you from zero to “machine running Claude Code” in 1-2 minutes, versus 20-30 with traditional providers. They also handle the annoying bits of sharing web services: reverse proxy, TLS termination, DNS are all available instantaneously and with zero fuss; it’s night and day vs trying to roll your own.

In some sense, this is developer environments catching up to what has happened to production systems over the last decade. We’ve had infrastructure-as-code and “cattle not pets” thinking in deployment since containers and Kubernetes took the world by storm. GitHub Codespaces was a step in this direction for dev environments. Put another way, this new crop of services are an evolution: they let you go beyond just the “development” part and to the full end-to-end stack.

Speedrunning the services#

But enough about the abstract philosophy about why these services are having a moment: I decided to try out all of these services to see for myself whether they were actually useful and which one I liked the most.

My motivating use case for this: I was looking to understand how COOP and COEP work in all modern browsers for building a new feature in Perfetto ¹. This was a perfect vibe-coding task: it was fully throw-away code for testing something that would never directly end up in any prod project. And it was a web based thing where I needed https and certs etc. Literally could not design a better use case for this.

Here’s a quick rundown of the services:

Service	Pricing	Specs	Interface
exe.dev	$20/mo for up-to 25 VMs	2 CPU, 8GB RAM, 25GB disk shared across all 25 VMs	SSH + web shell + built-in AI agent
sprites	Usage-based ($0.07/CPU-hr, need to pay for RAM + storage also)	Bursts to 8 CPU, 16GB RAM	CLI tool for setup + SSH afterwards
shellbox	Usage-based ($0.05/hr running, $0.005/hr stopped)	2 CPU, 4GB RAM, 50GB SSD	Pure SSH

Immediately, it’s clear that there are three different “dimensions” these services are competing on:

Pricing model: flat fee vs usage based
Maximum possible specs: laughably poor vs somewhat reasonable
Interface: ssh vs custom CLI

It’s amazing how three tools in such a short space ended up in such different places! But which one actually worked best for me?

My experiences#

shellbox#

The UX to interface with shellbox is very cool: everything (billing, creating VMs, deleting VMs) is all done via ssh! You ssh into a server and they use your public key to figure out your account. You then add “credits” to your account that you can then use. Having not seen any other service like this before, I was already very impressed by the “cool factor”.

Unfortunately, that quickly faded as I found I couldn’t even try it without paying first some amount of money. And the payment UX was rough: no indication of how long I’d have to wait, and for a while their SSH status command kept telling me I had no credits; they finally showed up 15 minutes later.

Once in, I found Ubuntu 18.04: not exactly a “modern” environment (it’s actually been EOL since 2023…). And nothing was pre-installed; I even had to install Python myself! Certainly not ideal if the goal is “get to a usable dev environment fast”.

But the real dealbreaker for me is that, in their world, they consider a VM “stopped” the moment you disconnect SSH. To my understanding, this means you can’t run a webserver in the background even for a day or two to test something. Instead you need to stay connected constantly, which for the sort of thing I was trying to build, was very non-ideal.

exe.dev#

Firstly, I want to make clear that the homepage for exe.dev sucks, especially on mobile: it doesn’t tell you anything about what you’re getting and just tells you “ssh exe.dev”; I wasn’t about to SSH into a random server without understanding why. You only understand what you’re getting by clicking “About” at the bottom which takes you to their docs (which are actually decent!).

Once you SSH in, though? The UX is fantastic. It recognized my public key, looked it up against my GitHub account automatically ² and pulled my email and associated it to my account. On the VM, there was Ubuntu 24.04, Claude pre-installed, recent Python. They clearly understand their user base and what they’re trying to accomplish.

And beyond the command line, there’s a web shell for when SSH isn’t convenient. And they have a custom, web-based coding agent called Shelley which works surprisingly well (honestly, in many ways, nicer than Claude Code on web). I especially like their ability to look at the web service running and take screenshots to understand the state of the page; very cool!

It’s night and day between the homepage and the actual product. The only annoyance I ran into is that you can only expose a single public port, which I needed in my particular case (but I can understand this is a somewhat niche ask). Beyond that, I had a very nice experience.

sprites#

Having tried shellbox and exe.dev, the need to generate a token and install their CLI for sprites made me feel like I’d left my magic SSH kingdom and was back in the real world.

Once installed, the process to create a VM and ssh in was very smooth. Claude comes pre-installed, and interestingly, they configure it with --dangerously-skip-permissions by default! You’re given Ubuntu 25.04, so relatively bleeding edge. Beyond that, it all felt very standard, you’re just getting a VPS fast and fuss-free but with no other “magic” like exe.dev had.

In general though, the vibe I got throughout my experience of interacting with the tools and their web dashboard was that it felt very corporate" and designed for companies with teams of developers.

I think this feeling is best summed up by how their home page looks when logged in:

Not exactly flattering to see myself labelled as an organization!

Overall assessment#

exe.dev is my pick for solo developers. The flat $20/month cap feels psychologically nice—you know your max spend. The 2 vCPUs might feel limiting, but for Claude Code sessions where you’re not doing anything CPU-intensive, it’s probably fine. And frankly, the UX is so good it makes up for a lot.

shellbox has the simplest pricing model, but the user experience left me underwhelmed. The environment is ancient, the payment flow was confusing, and the SSH-disconnect behavior kills too many use cases. It feels a bit hacked together.

sprites is the most interesting technically. I love their design blog post: the ability to burst to 8 CPUs and 16GB RAM while only paying for what you use is very clever and I can imagine it would be great if you were only planning light usage. But the UX feels corporate, not magical. If I were running a company, I’m reasonably certain sprites would be the way to go. But for solo experimentation, exe.dev wins.

Conclusion#

You might find these services incredible or baffling depending on your stance on AI and how much you’re willing to pay for convenience.

These services aren’t targeting customers who care about “value for money” or raw specs. They’re targeting developers who want frictionless access to machines, without setting up VMs, wrestling with containers, or configuring certificates to show off prototypes.

I’ve been won over by the neat UX and “joyous” feeling of exe.dev. I’ll probably pay for it in months where I expect to do a lot of prototyping. Having tried the alternatives (Docker, local VMs, traditional VPSes) it’s nice to have something that just works.

https://github.com/google/perfetto/discussions/3227 if you’re interested! ↩︎
How, you might ask? Well if you didn’t know GitHub by default makes the all SSH public keys publicly accessible both via their API but also just by going to github.com/username.keys. For example, for my account: https://github.com/lalitmaganti.keys. ↩︎

What Makes a Good Tool for Claude Code

Sun, 12 Oct 2025 00:00:00 +0000

I’ve been using Claude Code extensively for personal projects, and similar AI coding tools at work. Recently I came across this excellent blog post that resonated with a lot of my experience.

One part stuck with me though: Noah emphasizes that tools fail with LLMs when they’re “overly complex,” with the Unix philosophy being particularly well-suited for tool calling. But then I thought about git.

Git breaks the Unix philosophy completely. It’s sprawling, stateful, and complex. And yet Claude Code handles it effortlessly. It composes commands that, even after 10+ years of daily git usage, I wouldn’t think to use. It handles rebasing, cherry-picking, complex resets—stuff that trips up experienced developers regularly.

So if simplicity and the Unix philosophy aren’t the whole story, what else matters?

I’ve come up with three “hallmarks” of a good tool for tool calling with LLMs.

1. It’s been around for a long time and/or is used by lots of people

Examples: Unix tools like cat, sed, awk, grep, find—but also git, npm, docker, kubectl. Every Stack Overflow thread, blog post, and tutorial using these tools has likely ended up in the training data. Claude isn’t reasoning from first principles—it’s drawing on millions of examples.

This is why git works despite its complexity: Claude has effectively memorized decades of collective wisdom.

2. It has really good documentation (built-in help or external docs)

Even if a tool isn’t widely used, great documentation can bridge the gap. I’ve been building a finance system on top of Beancount—a double-entry accounting system that’s definitely not mainstream (maybe I’ll write a post about this in the future). Claude Code handles it surprisingly well because Beancount has exceptional documentation. When I point Claude at the docs, it can figure out the directive syntax, transaction formats, and account structures without necessarily having seen millions of examples in its training data.

Good --help text matters. Clear external documentation matters. If Claude can discover how your tool works, it can use it effectively.

3. Good error messages

Error messages, especially those with suggestions like “you used X, did you mean Y?”, can be tremendously helpful for LLMs. The best example is the Rust compiler: it gives errors like “you typed foobar, did you mean foobaz?” and Claude Code can actually use that feedback to correct itself.

This might be one reason why people feel Claude Code is particularly good at Rust programming—the compiler is essentially coaching it through mistakes in real time.

This isn’t to say the Unix philosophy is wrong — it’s that Unix tools work well with Claude Code for different reasons than we might think. Tools like sed and awk nail hallmarks 1 and 2: they’ve been around for decades (massive training data) and have extensive man pages (great documentation). The fact that they follow “do one thing well” is almost incidental to their success with LLMs.

So if I’m building a tool today, I can’t make it instantly popular, but I can make it understandable. That means good documentation, clear error messages, and a few solid examples of how it’s used. Those aren’t new ideas — they’ve always mattered. The difference now is that there’s much higher ROI in doing them than there used to be.

In other words, we used to write docs for humans. Now, we’re also writing for AIs that help humans. That shift changes the economics of good documentation in a big way.

Harnessing Frustration: Using LLMs to Overcome Activation Energy

Mon, 14 Jul 2025 00:00:00 +0000

One of my biggest weaknesses as a software engineer is procrastination when facing a new project. When the scope is unclear, I have a tendency to wait until I feel I’ve “felt out” the problem to start doing anything. I know I’ll feel better and work much faster when I get “stuck in” but I still struggle with that first step, overcoming the “activation energy” required to engage with the details.

LLMs have been a game-changer for me in this respect: I can just throw a couple of sentences at them with the shape of the problem. This leads to one of two outcomes:

The LLM comes up with a good solution, usually in a slightly different way than what I was thinking. I realize “oh wow the solution is much simpler than I thought”. Straight away I start thinking about the consequences of implementing and improving what the LLM suggested.
The LLM comes up with a solution that I intuitively recognize as “wrong”. My immediate reaction is frustration (“How could it get it so wrong”) which leads me to go back and forth with the model, explaining to it why its solution could not possibly work. But in the process of arguing with the model, my brain is churning away and generating variations or different approaches that could work. After a while, even if the AI is still on the wrong track, the debate will trigger a moment of inspiration where suddenly the solution will come to me. I’ll excitedly start up a new conversation and start working through it with the model.

The key is the emotional reaction I have immediately to the LLM’s response, either excitement or frustration. By harnessing this immediate feedback loop, I get my brain out of its passive, procrastination mode. It’s almost like a jolt: either I’m thrilled because it’s simpler than I thought, or I’m spurred to action by the urge to correct a perceived ‘wrong’ answer. This forces me to engage with the problem in a meaningful way.

For what it’s worth, this experience is very similar to talking through a problem with another engineer: the advantage of LLMs is that it’s available 24/7 and I never have to worry about my problem being “too insignificant” to bother someone with. The simple act of articulating my thoughts and hearing a response seems sufficient, regardless of the response’s quality.

So next time you’re procrastinating a problem don’t wait around for inspiration. Outsource the first step. Throw the problem at an LLM and see what happens. Whether excitement or frustration, by channeling that emotion you can solve your problem faster.