I'm really excited about https://sprites.dev/ - it hits two of my favourite problems at once:
1. Developer environment sandboxes. This is a cheap and convenient way to run Claude Code / Codex CLI / etc in YOLO mode in a persistent sandboxed VM with a restricted blast radius if something goes wrong.
2. Sandbox API. Fly now have a product that lets me make a simple JSON API call to run untrusted code in a new sandbox. There's even snapshotting support so I can roll back to a known state after running that code.
BTW Simon, I was super happy when I heard on Theo's podcast that he will be encouraging you to monetise your work more. I'm super appreciative of your work and I'm pretty convinced that the more you profit from it, the better the universe will be!!!
I really want to love this, but my experience in the first 20 seconds is unfortunately like some of my other experiences coding against Fly APIs, they're broken.
can I live with some rough edges for some personal workflows that only impact me when things break? sure. however, I was thinking about playing with some CI/CD stuff using sprites that would impact our whole team if things broke and I'm really on the fence because of this experience in the first 20 seconds.
Fly team - please put some black box probes or just better testing on the example you give in the quick start. if you document it, test it.
I wish more companies had open issue trackers (some proprietary software have issues on Github for example, but, it doesn't need to be Github, just let people discuss issues in the open)
I might have missed this in the docs, but is there a way to fork/clone a sprite, or restore a checkpoint into a new one?
Use cases: set up my preferred env in one sprite and use that as a template for others; or fire off a few independent sprites with claude code exploring alternative solutions, then choose a winner and reap the rest.
It's coming, and it'll make sense how and why next week when I run the "how this shit works" post.
I actually pushed to include it in the launch release. You'd have to ask Kurt why he didn't, but I think the idea is just to get more real-world usage first.
Do you expect that to replace git worktree for getting Claude to work on multiple things in parallel? That was something I was curious about watching the demo video.
> Claude is a hyper-productive five-year-old savant. It’s uncannily smart, wants to stick its finger in every available electrical socket, and works best when you find a way to let it zap itself.
This is seriously cool - it's exactly the DX and API I've been waiting for from sandboxed execution providers.
I'd love to be able to configure the base image/VM in a way that doesn't bundle coding tools or anything else I don't need, and comes with some other binaries installed (I'm more interested in using this as an API for a sandbox use-case I have). Is there a way to do this at the moment / is this on the roadmap?
Another option would be configuring the sprite via checkpoint and then cloning the checkpoint from a base sprite, but I don't see this option anywhere either.
This is on the roadmap. The open question right now is if we can just do "fork from checkpoint" for customized template environments, or if we need all the docker infrastructure.
If the fat bundled environment harmful for you, or just extra stuff you don't care about?
Not harmful for now - "fork from checkpoint" would be perfectly fine for me at the moment. The main issue (as flagged in the post) is that setting up additional tooling can take a while!
In the longer term, docker is nice from a reproducibility + CI perspective, and a docker build is already something can easily work with and track in my system.
One thing I've heard but not verified with other sandboxed execution providers is that startup times for custom images can be quite slow, so it could be a potential differentiator given Fly's existing infra.
Yes! It would be kinda cool to have the ability to docker-deploy (think the fly method even -- just to get your sprite on its feet the way YOU want it) a base sprite image and then just go from there in the normal sprite way from then on.
I know it's one me for thinking this -- since the domain is fly.io -- but I was really hoping this is some local solution.
Not self-hosted, but just local. A thin command line wrapper to something (docker? bubblewrap?) that gave me sort of a containerized "VM" experience for my local machine using CoW.
Yeah I can make an lxc container called "ai" that has an ssh read key and then a few pre cloned projects. When I want to work I can clone and start it then get the same effect on my own hardware and for free. Just need a small little wrapper to make this a bit more streamlined
I want something like this, but running on my own box. I now have a Linux box with plenty of RAM and storage under my desk. (It happens to be an NVIDIA DGX Spark, but I'm not really interested in passing the GPU through to these sandboxed VMs; I know that's not practical anyway.) Maybe I'll see if I can hack together a local solution like this using Firecracker.
Philosophically, I like Fly and have been a customer since very early on.
That said, I dread having to do anything CLI related, which for hobby projects is like once every few weeks.
Glancing at the docs for Sprite, I worry that this will be another CLI where a good 95% of the time that I go to invoke a command, my workflow is interrupted by an auto-updater that takes longer than whatever interaction I'm trying to do and derails my train of thought.
Readit News
1. Developer environment sandboxes. This is a cheap and convenient way to run Claude Code / Codex CLI / etc in YOLO mode in a persistent sandboxed VM with a restricted blast radius if something goes wrong.
2. Sandbox API. Fly now have a product that lets me make a simple JSON API call to run untrusted code in a new sandbox. There's even snapshotting support so I can roll back to a known state after running that code.
I wrote more a bunch more about this here: https://simonwillison.net/2026/Jan/9/sprites-dev/
Fly's Sprites.dev addresses dev environment sandboxes and API sandboxes together - https://news.ycombinator.com/item?id=46561089 - Jan 2026 (10 comments)
https://container-use.com/quickstart
BTW Simon, I was super happy when I heard on Theo's podcast that he will be encouraging you to monetise your work more. I'm super appreciative of your work and I'm pretty convinced that the more you profit from it, the better the universe will be!!!
There goes the neighborhood.
https://sprites.dev/api has this command:
$ curl -X POST "https://api.sprites.dev/v1/sprites" \ -H "Authorization: Bearer $SPRITES_TOKEN" \ -d '{"name": "my-sprite"}'
which responds with
{"error":"name is required"}
if you use the request body in the full "Create Sprite" documentation at https://sprites.dev/api/sprites#create then it does work.
can I live with some rough edges for some personal workflows that only impact me when things break? sure. however, I was thinking about playing with some CI/CD stuff using sprites that would impact our whole team if things broke and I'm really on the fence because of this experience in the first 20 seconds.
Fly team - please put some black box probes or just better testing on the example you give in the quick start. if you document it, test it.
https://github.com/superfly/sprites-js/tree/main/exampleshttps://github.com/superfly/sprites-go/tree/main/exampleshttps://github.com/superfly/sprites-py/tree/main/exampleshttps://github.com/superfly/sprites-ex/tree/main/examples
a "quick start" really should just work when you copy paste them.
just assume it’s json. you’re gonna parse and validate it anyway.
I wish more companies had open issue trackers (some proprietary software have issues on Github for example, but, it doesn't need to be Github, just let people discuss issues in the open)
Use cases: set up my preferred env in one sprite and use that as a template for others; or fire off a few independent sprites with claude code exploring alternative solutions, then choose a winner and reap the rest.
I actually pushed to include it in the launch release. You'd have to ask Kurt why he didn't, but I think the idea is just to get more real-world usage first.
Thanks! Also looking forward to reading the post :)
> the idea is just to get more real-world usage first
My particular wish notwithstanding, I agree with this.
This alone was worth the upvote!
I'd love to be able to configure the base image/VM in a way that doesn't bundle coding tools or anything else I don't need, and comes with some other binaries installed (I'm more interested in using this as an API for a sandbox use-case I have). Is there a way to do this at the moment / is this on the roadmap?
Another option would be configuring the sprite via checkpoint and then cloning the checkpoint from a base sprite, but I don't see this option anywhere either.
If the fat bundled environment harmful for you, or just extra stuff you don't care about?
In the longer term, docker is nice from a reproducibility + CI perspective, and a docker build is already something can easily work with and track in my system.
One thing I've heard but not verified with other sandboxed execution providers is that startup times for custom images can be quite slow, so it could be a potential differentiator given Fly's existing infra.
Running IncusOS on some local hardware with ZFS underneath is a phenomenally powerful sandbox.
1. Coderunner - https://github.com/instavm/coderunner
That said, I dread having to do anything CLI related, which for hobby projects is like once every few weeks.
Glancing at the docs for Sprite, I worry that this will be another CLI where a good 95% of the time that I go to invoke a command, my workflow is interrupted by an auto-updater that takes longer than whatever interaction I'm trying to do and derails my train of thought.