The other day news appeared in my feed of a big funding round and a new CEO at fly.io so I pulled up their web site, which had a big headline for "Computers for agents":
That sounded new and interesting, and silly me, I thought it meant, you know, "an actual computer". So off I went to find more information. That led to documentation about "machines" and an API to manage them:
Word association kicked in here because we have a tool we developed mostly for automating complex test scenarios, (entirely coincidentally) called "machine". It allows quick and easy (but opinionated) management of VMs at various cloud providers. In the past Claude had successfully added support to machine for additional providers, so it seemed obvious to ask it to take a look at fly.io in that context. Not all hosting providers support the features the tool needs, so the first step was to do some feasibility analysis. Here's my initial prompt:
The current project is a Python CLI tool that helps automate the deployment of VMs at various hosting providers (Digitalocean, Vultr, Google at present), along with the configuration of accociated DNS records and specification of cloud.init scripts. I noticed there is a new hosting provider called fly.io that looks to provide similar hosting services but on bare metal machines. Can you evaluate whether it would feasible to add support for fly.io? Their documentation is at : https://fly.io/docs/machines/api/
Claude (using Fable 5 on this occasion) came back with this initial assessment:
Basically says "this is not the machine you are looking for" <waves hand>
Which of course made me want to ask "what is it then?"
Ok that's interesting, and swiftly cut through the marketing fog for me! So fly.io basically offers a kind of "remoted WSL2" service for desktop users?
At this point Claude falls into the same trap I often hit when trying to decode corporate marketing material. It gets distracted by information on the company's previous product, not the one we're interested in now:
I didn't realize at the time the source of the confusion, but none of this made sense to me, so asked some clarifying questions:
Ah ok. I understand better, but still not quite getting it. I get the "VM from docker image" aspect -- I've worked with several products that supported that in the past, and it's a good move in terms of beefing up isolation but retaining familiar tooling and artifacts. I'm still not totally seeing how you'd use this for a production service -- if there's no DNS support how is client traffic routed to my FAAS firecracker instances?
Claude now has its teeth firmly sunk into the red herring and proceeds to tell me why I'm wrong:
At this point I figured it might help if I created an account on fly.io which should let me see these machines close up. Oddly, Chrome already had a password saved for the site which meant either I was in a time loop, or I'd been here before.
In the dashboard, I saw "Apps" and thought "Je l'avais déjà vu", and one other thing which was named "sprites":
Sprites in Computer Science, everyone surely knows, is the technique originally pioneered in arcade games, to allow fast movement of space ships on the screen. But that use of the term seemed very unlikely to be in scope here. On the theory that "sprites" could be a new name for machines, but the fly.io api documentation hadn't yet been updated accordingly, I let Claude know about the name change:
Interesting. They're marketing the "sprites" service as "to run your AI agents", which seems quite different from that edge FAAS use case you described.
Claude maintains focus, avoiding the rabbit hole to do with the Danny Hillis-coined term for the first graphics hardware acceleration technique, first in a long lineage that led ultimately to today's AI chips and Claude. But a simple nudge was enough to make Claude realize it might have been barking up the wrong tree. It knows about the possibility that what's in its training data might be out of date, so begins live web searching:
Claude is also nice enough to note that I was right all along:
Having straightened out exactly what fly.io machines/sprites actually are, both myself and Claude get to experience the shared relief of having the seemingly irreconcilable finally reconciled:
Ah ok, it's all coming into focus now. Like many things it's easier to understand from the provenance and history of how it came to be. They began with the edge/FAAS service and someone had the brilliant idea later that they could make some small changes and thereby have the "Linux on a rope" service to address malicious LLM concerns.
The full agent session can be found here. These are the documents Claude cited during that session: