Code and Let Live

by usrme • 6 months ago

508 184 6 months ago

jmogly• 6 months ago

Like it, a lot. I think the future of software is going to be unimaginably dynamic. Maybe apps will not have statically defined feature sets, they will adjust themselves around what the user wants and the data it has access to. I’m not entirely sure what that looks like yet, but things like this are a step in that direction.

dmux• 6 months ago

I think the future of software is going to be unimaginably dynamic.
...I’m not entirely sure what that looks like yet, but things like this are a step in that direction.

This made me stop and think for a moment as to what this would look like as well. I'm having trouble finding it, but I think there was a post by Joe Armstrong (of Erlang) that talked about globally (as in across system boundaries, not global as in global variable) addressable functions?

cess112• 6 months ago

Not sure if I've read such an article, but it would be a reasonable next step from the globally addressable processes of the BEAM VM.

As I understand it Unison tries to do something like that but that might be wrong.

https://www.unison-lang.org/

skybrian2• 6 months ago

This sounds great and it's roughly what exe.dev is doing too. Coincidence?

tptacek25• 6 months ago

This has been in the works for quite awhile here. We put a long bet on "slow create fast start/stop" --- which is a really interesting and useful shape for execution environments --- but it didn't make sense to sandboxers, so "fast create" has been the White Whale at Fly.io for over a year.

breakingcups2• 6 months ago

What I like about exe.dev is that you only need ssh to access it, is something like that under consideration for Sprites.dev?

Additionally, is Tailscale/Wireguard connectivity something you'd consider?

memset2• 6 months ago

I have just now learned about exe.dev and it looks awesome.

I really hate that modern development means not having persistent disk. I’m glad there are new options coming out which let you do this in and easier way than managing my own EC2 instances!

HumanOstrich• 6 months ago

Not really. One of the primary features of sprites.dev that I don't see anywhere on exe.dev is a fast way to create and restore checkpoints, like a git repo for your entire VM.

This is needed for sandboxes if you don't want to throw them away and start over when something goes wrong.

With sprites.dev you can create an additional checkpoint and then turn Claude Code (or your preferred agent) loose to do anything. Even if it burns down the sandbox you can just restore a checkpoint in about a second.

skybrian2• 6 months ago

Yes that’s certainly a great feature and they don’t have it currently. For what it’s worth, they do have a teaser about “Persistent disks with some really interesting work coming soon.”

https://blog.exe.dev/meet-exe.dev

crawshaw• 6 months ago

[exe.dev co-founder here] If you are curious, we have a `clone` command coming soon for sub-section creation of a new VM out of an existing VM. This is our first pass at checkpointing, rather than introducing an independent `snapshot` noun, you can keep a VM around as the snapshot.

We realize that is not going to cover all the business cases we have been discussing with customers and plan to introduce a snapshot concept (in particular for rewinding the state of a VM to an automatic backup), but we have a lot of FS work underway before we can launch it. There are some other things we want out of our VMs that we cannot do using conventional cloud techniques, so we have code to write.

simonw3• 6 months ago

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.

I wrote more a bunch more about this here: https://simonwillison.net/2026/Jan/9/sprites-dev/

realty_geek2• 6 months ago

I have found container-use to be super useful for this.

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!!!

skrebbel2• 6 months ago

For those of us who weren’t on that podcast, can you clarify who Theo is?

throwup238• 6 months ago

BTW Simon, I was super happy when I heard on Theo's podcast that he will be encouraging you to monetise your work more.

There goes the neighborhood.

dang• 6 months ago

I know you know this, as you posted it, but readers might want to look at this related thread:

Fly's Sprites.dev addresses dev environment sandboxes and API sandboxes together - https://news.ycombinator.com/item?id=46561089 - Jan 2026 (10 comments)

indigodaddy9• 6 months ago

So this is neat and useful and I think will/should get traction.

So let's say sprite is my building/dev ground floor. I get my thing/app to where I want it, but at the end of the day I think my thing/app is so awesome that it should be a production app for the whole world, and, I want to actually deploy it on fly, say.

Have you guys thought about that workflow, and what it might take to push button/migrate a sprite app over to fly?

Also, any plans for GPU sprites?

tptacek25• 6 months ago

It depends on which Fly person you talk to. If you talk to Kurt he'll try to sell you on his crazy dream of how all software is going to be malleable and "prod" doesn't mean anything anymore. If you ask me: tell Claude to make a Dockerfile of the current state of your Sprite, and then deploy it as a Fly Machine. It's a good question, and we're working out how the transition from Sprite to Fly Machine works, but that's how I'd do it today.

I don't think we're going to do anything new with GPUs any time soon.

memset2• 6 months ago

Could you clarify what this actually is?

Would I think of this as an EC2 instance which automatically and quickly scales to zero, with pricing only for resources consumed? (CPU and RAM when up, and disk all the time?)

simonw3• 6 months ago

Yeah that's about right.

It's a fast starting and fast pausing persistent VM, with a ton of built in developer tools (including a preconfigured Claude Code) and an extra JSON API for executing commands within it so you can treat it as a sandbox.

You may find my writeup here useful: https://simonwillison.net/2026/Jan/9/sprites-dev/

dtkav6• 6 months ago

fly.io is doing really good work. I've super enjoyed building our product on their platform. I love fly-replay combined with super fast start-up.

I've been thinking a lot about how to run agents (and skills) securely while giving them a lot of powerful capabilities.

I recently used their macaroons library to turn arbitrary API keys (e.g. for stripe's API) into macaroons. I route requests for an upstream host (like stripe) through Envoy as a mitm proxy which injects the real creds after verifying the macaroon.

It is such a powerful pattern. I'm always worried about leaking sensitive keys through prompt injection attacks (or just sending them to anthropic), but in this model you can attenuate the keys (both capabilities & validity window) client side. The Envoy proxy lives inside my flycast network so it can't be accessed externally.

It would be so cool if fly built something like this into sprites.dev (though I can see how it would be spooky to have fly install their own certs for stripe, etc...)

tptacek25• 6 months ago

If you read Ben Toews work on the tokenizer you have a good sense of where I want Sprites to go with key leaks and prompt injection:

https://fly.io/blog/tokenized-tokens/

dtkav6• 6 months ago

Awesome stuff! Thanks for the reply.

Tokenizer is an explicit proxy though right?

My use case is very similar, but I wanted a transparent proxy so I could run unmodified scripts. It is a tricky design decision though.

I also mount a little fuse filesystem that mints macaroon on read (with a shorter lifetime, probably inspired by y'all but i forget from where).

I work on realtime collaboration of markdown files (currently in Obsidian), which has become a shared-context substrate for agents, skills, etc.. Our own company workspace has skills that have scoped access to fly, stripe, gmail, etc. We're definitely drinking the file-over-app personal-software-for-teams Kool-Aid, so the problem space for us includes access control and auditing.

Love your work :)

CGamesPlay4• 6 months ago

Did you write up anything about this? Is this off the shelf behavior for Envoy or did you create this API yourself?

dtkav6• 6 months ago

I can open source it next week when i get a chance.

dtkav6• 6 months ago

sorry for the delayed response. I ended posting on this [0] thread where they (Formal) are doing something similar.

Here's the repo [1]. I modified it a bit to post publicly and remove the details of my setup within my tailnet/flycast network.

[0] https://news.ycombinator.com/item?id=46605155

[1] https://github.com/dtkav/agent-creds

nextaccountic2• 6 months ago

How exactly can code agents make use of this? You install claude code inside a Sprite and run it there? Do you also need to put all your codebase in this sprite?

tptacek25• 6 months ago

Claude Code is already in the Sprite; just create one and type "claude". But they have an API and Claude (or Gemini or Codex) can use them remotely too. They're disposable computers. Use them however you want.

indigodaddy9• 6 months ago

Will you guys get mad if I try to do something like transcription with a tiny model on a sprite?

hashim-warren• 6 months ago

You can use git to pull down code from a remote repo

qhwudbebd2• 6 months ago

AFAIK fly.io run firecracker and cloud-hypervisor VMs. This seems to have a copy-on-write filesystem underneath.

Given their principled take on only trusting full-VM boundaries, I doubt they moved any of the storage stack into the untrusted VM.

So maybe a virtio-block device passing through discard to some underlying CoW storage stack, or maybe virtio-fs if it's running on ch instead of fc? Would be interesting to hear more about the underlying design choices and trade-offs.

Edit: from their website, "Since it's just ext4, you won't run into weird edge cases like you might with NFS or FUSE mounts. You can happily use shared memory files, for example, so you can run SQLite in all its modes." So it's a virtio block device supporting discard that's exposed to the VM. Interesting; fc doesn't support virtio discard passthrough, and support for ch is still in progress...

tptacek25• 6 months ago

I have a post coming next week about the guts of this thing, but I'm curious why you think we'd avoid running the storage stack inside the VM. From my perspective that's safer than running it outside the VM.

wmf• 6 months ago

Safer from what? It depends whether you're protecting the infra or the data.

qhwudbebd2• 6 months ago

My impression is that you (very reasonably) treat anything inside the VM as untrusted. If you want trusted rollback, presumably that implies that the VM can't have any ability to tamper with the snapshot?

But maybe you have parts of the stack that don't need to be trusted inside the VM somehow? Looking forward to the article.

a_lanfranco• 6 months ago

sprites.dev looks very interesting to me. Is there a way to set up a limit to how much scaling a sprite can get, or to set a spending limit? I wouldn't want to spin something up, and then be surprised by an unexpectedly high bill.

mwcampbell2• 6 months ago

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.

indigodaddy9• 6 months ago

Maybe bend smolvm to your needs?

tptacek25• 6 months ago

That's coming. It's what Jerome has been working on these past few months.

haute_cuisine2• 6 months ago

What about `docker run`? It'll be the same isolated container that keeps state. You can also mount some local directory

jamietanna• 6 months ago

Unsure if it's an intended typo: `rm -rf $HMOE/bin`

CGamesPlay4• 6 months ago

I ran the command to check and it erased /bin and now my sprite is busted. But I was able to restore from a checkpoint and it's all good.

mrkurt9• 6 months ago

Intended typo so you can see restore happen ;)

CGamesPlay4• 6 months ago

I spun one up, started a server on port 8080, ran `sprite url`, it gave me a URL, that URL just has `{ "error": "unauthorized" }`. How am I supposed to access it?

mrkurt9• 6 months ago

sprite url update --auth public

It requires your api token by default.

CGamesPlay4• 6 months ago

Oh, thanks, that works. ([edit] rewrote this whole post) I guess I need to install my own tunneling into the VM to do web development on it, but that's not so bad. The lack of regional support is crippling, because whatever region you put me in is ~200ms from me and the typing lag is terrible.

I'd love to adopt this for all my development (which I currently do using rented cloud instances, so I'm pretty comfortable with the remote development paradigm). I'm especially excited about the snapshot/clone pattern, and have (this past week) been researching solutions for exactly this problem.

Hope you launch multiple regions for this ASAP. Will be watching.

indigodaddy9• 6 months ago

Do we handle our own certs or do you have a proxy in front of the sprites that can do auto ssl stuff?

sheepscreek• 6 months ago

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 alone was worth the upvote!

psanford3• 6 months ago

What is the criteria for a sprite being "idle"? Is it no network activity or is it cpu based?

simonw3• 6 months ago

Looks like it's no network activity for 30 seconds.

mrkurt9• 6 months ago

It stays awake if you have an open connection (like sprite console) or an exec session if running and producing stdout.

You can specify a max exec time for a process when you launch it via the API.

karmajunkie3• 6 months ago

Is there something we have to do to get a sprite to idle? Because I started one over the weekend that's still running despite no network usage, so that seems to be currently broken.

psanford3• 6 months ago

Playing around with this for a small amount of time, it is very neat but also there are a bunch of things that are unclear / undocumented (I assume the documentation is coming so I'm not faulting them for it not being there yet).

Some things that are unclear:

- How should I auth to github? sprite console doesn't use ssh (afaik) so I guess not agent forwarding?

- What on machine api's are available? Can I use the fly oidc provider[1]? There's a /.sprite/api.sock but curl'ing /v1/tokens/oidc gets a 404.

- How much is it going to cost me? I know there is pricing but its hard to figure out what actual usage would be like. Also I don't see any usage info in the webui right now.

[1] https://fly.io/blog/oidc-cloud-roles/

psanford3• 6 months ago

To follow up on this a bit, something that I really want is a way to build and launch apps from an llm really easily. I am imagining and environment with a database, object storage, and a publicly reachable webserver. I think this could be that with OIDC auth to an s3 bucket and litestream.

I was previously thinking about doing the same thing on my homeserver with tailscale to expose the web interface publicly and tailscale oidc auth to an s3 bucket for object storage.

mrkurt9• 6 months ago

I have a Sprite with an auth token to an isolated Sprite org, it works really well for this.

SQLite works great for my apps. I haven't needed object storage yet, storing files on disk is enough.

fideloper• 6 months ago

i believe the .sprite dir has some stuff to help claude answer those questions. haven’t done it myself but my friend said he was able to get claude to set it all up for him (yolo mode helps) including connecting to github.

tptacek25• 6 months ago

Don't think of this as in any way connected to the Fly Machines API. For now, just take it on its own terms. We'll have an open-source local version of it relatively soon, if that clarifies anything.

johnfn• 6 months ago

Wow, this looks absolutely fantastic. Can't wait to take it for a spin. I'm actually surprised it isn't seeing more traction here!

In particular, I'm really excited about the extremely fast start up time and checkpointing. I'm curious if anyone knows any alternatives in this space?

stogot• 6 months ago

I have kids. They have devices. I wanted some control over them. So I did what many of you would do in my situation: I vibe-coded an MDM.

Wait, what?

zahlman• 6 months ago

I'm so far from the target audience for this article that I had to look up what MDM even stands for.

abelanger2• 6 months ago

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.

indigodaddy9• 6 months ago

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.

mrkurt9• 6 months ago

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?

abelanger2• 6 months ago

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.

setheron2• 6 months ago

On one hand it sounds cool. On the other, I feel like I missed it.

Is this just a fancy VPS like digital ocean with, https endpoint, snapshot and restore?

(Same thing goes for exe.dev)

tptacek25• 6 months ago

Yes, plus:

* Near-instant creation

* Automatic spin-down scale-to-zero, so you're not paying for it when it's not in use.

If you're using these like we are internally, you've got like 2 dozen of them sitting around in the background sleeping. They're BIC disposable computers. "When in doubt just make another one."

setheron2• 6 months ago

I see.

Also "containers" always had the option to attach durable storage via bind mounts.

I still get confused by the "this isn't containers" but it's kind of similar.

Maybe I am just too caught up in semantics.

A VPS that is instant to boot, super simple automatic routing and https proxy, with snapshot and durable is a win regardless.

karmajunkie3• 6 months ago

something that isn’t clear to me: what’s the billing when i’m not actively using a sprite? does that go to zero as well, or am i still being billed for storage?

csomar2• 6 months ago

That's roughly what Cloudflare containers are right? (with migrations being the checkpoints?). Cloudflare containers are also nearly instant and have scale-to-zero pricing. The only difference here is the CLI?

Your pricing looks competitive on compute but roughly 4-5 times more expensive on memory and double on storage.

dangoodmanUT5• 6 months ago

Will you have higher tier pricing plans in the future? I don't see a way to sleep them (if you mean other than idle), and the max plan has 10 running concurrently

zackify3• 6 months ago

I wonder the same thing. What’s so different than your own vps and using lxd to create a container. Make two bash aliases and wow you can go in and out quickly and recreate it with one command.

tptacek25• 6 months ago

If you have an LXD setup working for your own workloads that's working well for you, that's awesome. Why would we want to talk you out of that? Fundamentally you're getting at the difference between "elastic" cloud services and personal infrastructure. Personal infra is great!

If it helps: Jerome has been working for a couple months on a local, open-source Rust version of Sprites, so you can use the same DX with your own infrastructure. We just think this is the right "shape" for modern sandboxes, wherever you actually run them.

roncesvalles• 6 months ago

Basically endgame VPS. Instant creation, snapshotting, restore. Actually quite impressive even if you don't buy the whole Claude spiel.

senko2• 6 months ago

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.

tptacek25• 6 months ago

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.

mcintyre19945• 6 months ago

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.

senko2• 6 months ago

It's coming, and it'll make sense how and why next week when I run the "how this shit works" post.

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.

obsoleetorr• 6 months ago

something simpler I've did, in the same spirit: LXC containers (using Incus) in a VM. LXC containers look and feel like VMs, but are very lightweight. And the VM they all run in provide the hard sandbox.

and when I spin up a new LXC container cloud-init sets it up with the agents and my repos inside

Spivak• 6 months ago

I'm not really sure I get the value of these being remotely hosted. We're writing code on super powerful machines with hypervisors built in.

My libvirt setup does this right now, I have a little dumb cli I wrote that lets me create, start, stop, save, restore, and destroy preconfigured machines. I use it for testing provisioning scripts and playbooks. You get the full cloud experience by including a cloud-init ISO so you can ssh to it the moment it boots with my key. Didn't realize I was at the frontier of computing paradigms.

Don't get me wrong the interface fly has is super nice but it feels like the endgame isn't remote hosted computers but a nice user-friendly interface (i.e. what docker did) but it's for persistent local VMs.

indigodaddy9• 6 months ago

Sure, but plenty of users don't want to have to do/configure all that locally, sorta like I want shared hosting vs my own VPS as a sort of analogy.

haute_cuisine2• 6 months ago

Thanks for the writeup on the libvirt setup. At some point I used local docker containers for this.

mbm2• 6 months ago

This is amazing. Great job Fly team!

mbm2• 6 months ago

Hmm, so even just doing a simple ls -la on the home dir is occasionally taking ~10s. Other times, it's instant (I'm on a stable 1 Gbps connection).

Have been experiencing intermittent connection drops as well.

siliconc0w• 6 months ago

It'd cool to create a MCP for this so you can have your agents run persistent code/other agents.

This is a large pain point today if you aren't technical, most of the chat interfaces just let you create frontend only apps.

tptacek25• 6 months ago

You can do this now without an MCP, by auth'ing the `sprite` command inside of a Sprite and telling Claude to go document it for you. You can do things like "make me three versions of this feature on three different Sprites so I can compare them". It is spooky how easy it is to teach agents this stuff.

godzillafarts• 6 months ago

When you start a feature branch on your own, do you create an entirely new development environment to do it?

… yes? We have a few wrapper scripts around worktree operations that copy some docker volumes (pg data, bundle cache, etc.) from the base and spins up an entirely new stack on different ports with a host alias. We don’t have to install any deps beyond that because we copied over the ruby gems bundle cache and we’re using Yarn PnP + “zero installs” for client-side deps.

jagged-chisel• 6 months ago

Wait - you have a repository with a dev environment, and now that you want a new feature branch, you’re creating an entirely new dev environment?

Maybe I’ve been isolated from The World for too long, but this sounds … unhealthy.

tinodb2• 6 months ago

Not if you want to run multiple agents in parallel…

adastra22• 6 months ago

Stop killing your sandboxes every time you use them.

Fo people do this? I’ve never heard of it.

zaptheimpaler• 6 months ago

The sprite installer got stuck after "Installed to ..." for me. After waiting a few minutes I just ctrl+ced and looked at what it does after and manually ran "sprite auth setup --token <token>" and that seems to just hang for me.

valinator• 6 months ago

There are some important million-person apps, but most of them just destroy civil society, melt our brains, and arrange chauffeurs for individual cheeseburgers.

All the cool technical stuff aside - this, for me, was the standout line of the article

dangoodmanUT5• 6 months ago

I thought fly.io snapshots weren't guaranteed to stick around? Although I can can't find the docs mentioning it, but i checked within the last few months... maybe they changed it?

tptacek25• 6 months ago

More complicated than that, but with respect to Sprites --- this is a totally new stack.

dangoodmanUT5• 6 months ago

it seems like when you snapshot, you snapshot memory AND the filesystem (immutable ftw), that's pretty awesome

i am dying to know: firecracker still? I know you have an upcoming post abt it, but i'm incredibly impatient when it comes to fool new infra

chrismccord• 6 months ago

I've been having so much fun working on sprites (and working with sprites) the last the several months. There's some neat parts of the Elixir side of this we're going to open source soon.

Also check out the 5 min demo we put out where I walk thru some sprite basics: https://www.youtube.com/watch?v=7BfTLlwO4hw

tptacek25• 6 months ago

One of the coolest things about this is that Claude in his environment --- without him asking to --- knows how to drive Sprites. If you ask it to run a server, it will register it as a local service so it survives reboots. Without you asking to, it'll checkpoint when it makes big changes. I think this is kind of freaky.

I can't say enough how, if you're using this like Kurt and Chris have been, you have like, a dozen sleeping Sprites in your Sprite list. If you're not doing anything with them, they're not really costing you anything. When you want to do something new, there's no point figuring out which of your existing Sprites to do it on. Just make a new one.

Always having a sane place to run anything I happen to be doing, without making any decisions, it's a weird feeling.

indigodaddy9• 6 months ago

Do we pay a storage penalty for inactive sprites?

mcintyre19945• 6 months ago

That’s a great demo! For curious mere mortals, are all those custom instructions that make Claude know how to use it public? I’d like to learn how to drive it myself too, just out of curiosity!

losvedir2• 6 months ago

Oh no, as someone who hoards browser tabs, I fear where this will lead me...

aostiles• 6 months ago

This seems cool but maybe not for a production setting requiring concurrency? I just signed up on PAYG which offers 3 concurrent sprites. I only see an option to upgrade to 10 concurrent sprites.

tptacek25• 6 months ago

Without getting into Kurt's galaxy-brained take on the declining importance of "production" in a post-AI world, I'd say: yeah, run prod apps on Fly Machines, for more predictable performance, scaling, and pricing. Do exploratory computing --- "figuring out what you'd run on a Fly Machine" --- in Sprites.

BoorishBears• 6 months ago

The last few hours were a roller coaster after spending my weekend trying to build something Sprites-like on Fly Machines to power a feature in a larger project, then coming across this (great, I don't need to build it!) to realizing this is a seemingly a consumer product and I haven't been saved from an awful slog.

therealwardo2• 6 months ago

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.

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.

nextaccountic2• 6 months ago

Can this issue be reported?

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)

tvink• 6 months ago

Probably because you didn't include the content type header?

therealwardo2• 6 months ago

yep that would fix it. just needs a little docs change.

a "quick start" really should just work when you copy paste them.

rendaw2• 6 months ago

Can it be some other content type?

ch2026• 6 months ago

why does an API that only accepts json need me to specify in a header that it’s json.

just assume it’s json. you’re gonna parse and validate it anyway.

Aurornis• 6 months ago

The documentation is correct now. I assume someone from fly is reading the comments.

mrkurt9• 6 months ago

Believe it or not, that's the only example that's not autogenerated from tests (yet).

https://github.com/superfly/sprites-js/tree/main/examples https://github.com/superfly/sprites-go/tree/main/examples https://github.com/superfly/sprites-py/tree/main/examples https://github.com/superfly/sprites-ex/tree/main/examples

bravura• 6 months ago

Now, please make it easy to control network egress!

timabdulla• 6 months ago

This seems cool, but beware that Fly's other products are not exactly models of stability and polish.

API downtime is a semi-frequent occurrence, as are transient API errors and slowness.

I've also had a ticket open with support for weeks due to rampant billing issues. For instance, a destroyed instance still shows up in my usage report as actively accruing billed time, and at a rate faster than is even possible (something like 2 hours for every 1 actual hour that has passed.)

They've released two new products in the AI space, this and Phoenix.new, and my worry is that they are focused on new products over making what they have good and reliable.

cschmatzler• 6 months ago

yeah nobody should use this based on reliability and support alone

dotemacs• 6 months ago

I saw this headline, saw the tweets and missed what this was about.

Then read Simon Willison's breakdown and got the 'Aha!'.

I like what they've done, played with it and immediately started to plan how I'd try to implement it myself.

I guess this will be the way to go, for development setups instead of using a dedicated machine. Especially when mobile clients are created for Sprites.

yoavsha1• 6 months ago

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.

_kb• 6 months ago

Check out LXC and the wider Incus set of projects: https://linuxcontainers.org/incus/.

Running IncusOS on some local hardware with ZFS underneath is a phenomenally powerful sandbox.

zackify3• 6 months ago

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

mkagenius• 6 months ago

If you are on mac, you can use Coderunner[1]. It will run locally on your and execute any AI generated code in an apple container.

1. Coderunner - https://github.com/instavm/coderunner

mcintyre19945• 6 months ago

Okay this is super interesting!

As I was reading this I was a bit confused by the issues they mention, but at work I use Claude SSHed to a persistent dev server and I’d be annoyed if I didn’t have eg my git repos there all the time or any part of that workflow was ephemeral. I’m not really aware of what everyone else is doing with sandboxes etc.

But the bit at the end with the MDM server made it click for me. I’ve started generating tiny iOS apps for personal software stuff, because they solve data storage better than the web (at least on iOS). A database on some other server seems like a bad fit/overkill for this stuff, client side storage is too flaky because Safari. But iOS apps are limiting in their own annoying ways compared to web apps.

This looks like a really interesting solution, I can just store the data on a sprite with SQLite or whatever. Visit its URL to use my app, then does it go away on its own after a short time? I could have done that before with a server with storage, but this seems easier/probably cheaper.

If this works well/the way I’m hoping it might be the sweet spot for simple personal software that needs persistent data and you want to run anywhere.

One feature that would make this really nice is if it could have something like Vercel preview environments, where I need to auth my fly account to view the URL. That'd solve the public URL without me needing to do my own auth thing in every app.

losvedir2• 6 months ago

How do you make these personal iOS apps? Do you have to release them to the App Store? What if you want a small handful of users (eg family members)? And does Android work similarly?

mcintyre19945• 6 months ago

You can deploy from XCode to your iPhone, and it seems to behave like any other app when you do that. I do have a paid Apple developer account, and I think I read that if you don't then you have to re-sign the app every 7 days. If you wanted a small number of users then I don't think this would work. I think you could use TestFlight, which is Apple's method for distributing an unreleased version of an app, but I'm not sure what the review process would look like for that. Android would be much easier as long as you can still sideload APKs, you could just build the APK and send it to everyone to install. I read that there were some changes to sideloading APKs but I don't know the details.

In terms of actually making the app, I don't know Swift or iOS at all so it's all generated. Usual caveats, and I'm only running them on my own phone. I ask Claude (not code) to help me with the spec, I give it some bullet points and it asks a bunch of clarifying questions then gives me a spec. I put that in a new directory, fire up Claude and use the ralph-loop plugin (https://github.com/anthropics/claude-code/tree/main/plugins/...):

/ralph-loop:ralph-loop "Implement the iOS app described in app-spec.md. You have access to xcode CLI tools. You should write tests and use them to verify your work. The task will be complete when the app is fully implemented, with all tests passing. Output <promise>COMPLETE</promise> when finished." --max-iterations 50 --completion-promise "COMPLETE"

Once it's done you can open the app in XCode, test it in a simulator, play with it and iterate a bit and then send it to your phone!

Editing to add because I can't edit the original post: I think the limiting factor here might be the concurrent sprites limit. It seems like if you're on pay-as-you-go then you can only have 3 running concurrently, and have to subscribe to get 10.

resonious• 6 months ago

Would LOVE a Termux build of the CLI. I ran the linux install script and got an incompatible binary.

spondyl• 6 months ago

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.

causal• 6 months ago

Same. Abandoned fly for Digital Ocean when I found myself hitting my head against the wall trying to get their "just works" to work too often.

mrkurt9• 6 months ago

flyctl is complicated and, unfortunately, needs pretty aggressive auto updates. The sprite CLI should be much better in this respect.

ksclk• 6 months ago

Does cron work (wake up the vm) there?

phelm• 6 months ago

This looks great, i've been wanting a dev sandbox that doesn't run the risk of costing a lot if I forget to turn it off.

I had a few issues

1. manpath: can't set the locale; make sure $LC_* and $LANG are correct

suspect this is due to it inheriting locale from my local machine? easy to get around with some updates to .bashrc

2. the $SHELL environment in my sprite is `/opt/homebrew/bin/fish` I use fish on my local (mac + homebrew) machine and it seems to have inherited from my local machine, its nice to be using fish in the sprite, but seems weird that $SHELL in the sprite points to non-existent path. Slightly concerning that a local env var is being transferred to a remote machine without my explicit permission, I have some sensitive env vars locally.

mrkurt9• 6 months ago

Good point about quietly grabbing env vars, we can warn about that on first run. All it's getting are these:

  var envVars []string
    shellEnvVars := []string{
    "BASH_VERSION",
    "ZSH_VERSION",
    "FISH_VERSION",
    "KSH_VERSION",
    "tcsh",
    "SHELL",
  }

It's also reading terminfo. It's not handling absolute paths to shells properly, though.

If you want to skip this, running `sprite exec -tty /bin/bash --login` or similar avoids the magic.

cyberax• 6 months ago

Nice. I'm trying it for our CI/CD, with GitHub actions just launching sprites.

PanMan2• 6 months ago

I liked this idea so much I signed up and linked my personal cc (to my job email) to try it out. Unfortunately, it keeps saying "You must add a credit card to use Sprites with this organization" - even though I just linked a card. No way to continue from there: it's a loop that shows my account with an "activate" button, clicking it shows the error and my account again. Fly.io says I have an account now and it's "in good standing".. :(

PanMan2• 6 months ago

This did resolve itself.. I guess adding the card took.. a few minutes? Errors were confusing tho

mehdi1964• 6 months ago

Treating agents like full computers instead of ephemeral sandboxes makes a lot of sense—durable state and checkpoints solve real pain points that stateless containers force you to work around. Curious how this approach scales when you need dozens or hundreds of Sprites at once.

dzonga• 6 months ago

I don't really know the details of the architecture - but I bet there's heavy use of sqlite - if the sprites can be paused without consuming resources.

tryauuum2• 6 months ago

They go idle and stop metering automatically, so it’s cheap to have lots of them. I use dozens.
Despite all that, they’re fully durable. They don’t die until I tell them to.

what?

tryauuum2• 6 months ago

I guess they autoresume from idle if an https request comes to a sprite

jFriedensreich2• 6 months ago

i dont think i really get what this gives me over docker. everything i read is how i work for years

vulcan01• 6 months ago

Docker does not and cannot offer full isolation. A sandboxed VM on someone else's computer is less likely to be problematic for running untrusted code than a container on your system.

jFriedensreich2• 6 months ago

seems not to justify submitting to a proprietary single vendor solution where users are locked into opaque checkpoints they forgot how to migrate away from. this is not something made for users lets be clear. there are tens or hundreds of vm layers for defense in depth for docker so thats a non argument, no one says docker has to provide security its for tooling and common practices that allow vendor independence and moving to self hosted stacks as needed!

varyherb• 6 months ago

Does anyone know of similar solutions that can be self-hosted? (without a 12 service stack like Daytona [1])

[1] https://www.daytona.io/docs/en/oss-deployment/

handfuloflight• 6 months ago

Have you tried https://orbstack.dev/?

rco8786• 6 months ago

This is cool but like...a docker container running locally works fine too?

atomon• 6 months ago

Putting aside the details of the product itself, I love the style of this post. I wish more announcements read like this.

tinodb2• 6 months ago

docs.sprites.dev requires authentication? And what about adding /llm.txt? I want Claude Code Web to install the cli and deploy what it is working on in a sprite :)

rao-v• 6 months ago

I'd really love a locally hostable limited version of this, so I can do some quick messing around before switching to the cloud version for long term usage. It cannot be too hard to spin up an API compatible version that just uses the local device + 20GB or something right?

atleastonce• 6 months ago

Fly.io is so cool.

The way they force at least one "fuck" into all of their promo is just so cool.

Erm, I mean so fuck cool!

indigodaddy9• 6 months ago

How does the sprite ecosystem know when a sprite needs additional resources? If you start maxing out cores or ram usage gets too high you just automatically get allocated more cores/ram? (Assuming live/dynamically correct?)

djmashko2• 6 months ago

On the documentation, you install the NPM package via Anthropic: https://sprites.dev/api (on this page, if you select Node)

npm install @anthropic-ai/sprites

Is there some relationship between Anthropic and Fly.io that I didn't hear about?

Omni5cience• 6 months ago

I noticed the same thing, I suspect it's hallucinated. It seems like the correct package is @fly/sprites --https://www.npmjs.com/package/@fly/sprites

cedws• 6 months ago

Not really seeing what's amazing about this. It looks like something very similar to what Fly already offers, just ad-hoc and snapshottable. Still Firecracker underneath.

I've been wanting to sandbox Copilot/Claude Code for a while, but I don't want to pay for a PaaS just to do that. I want to run the sandbox on my M4 chip instead of needing a constant internet connection to run code on an anaemic remote CPU.

raducu• 6 months ago

Would it be possible for the CLI not to be binary and just a shell script, or a webshell would be great.

My issue is I've had my work laptop wiped twice because of things I've installed on it and it's a hassle to switch accounts/devices but I've love to give sprites a go.

mikomraz• 6 months ago

really? how come? what are they using to detect binaries?

Zababa• 6 months ago

Rather: an intended part of the ordinary course of using a Sprite. Like git, but for the whole system.

What I've been waiting for, for a long time. Basically the thing you need if you want agents to run freely but still in a safe way kinda.

For reasons we’ll get into when we write up how we built these things, you wouldn’t want to ship an app to millions of people on a Sprite. But most apps don’t want to serve millions of people. The most important day-to-day apps disproportionately won’t have million-person audiences.

I appreciate a lot this vision of personal computing.

I'll give sprites a try, they sound super cool.

kristo• 6 months ago

It looks like tmux sessions don't keep the sprite alive though, so you can't run cc in the background :/

messh• 6 months ago

checkout also https://shellbox.dev/ which has pure ssh access

Code and Let Live

Related Stories