FRESH

Hacker News

Home

Code and Let Live

73 points by usrme

by simonw

1 subcomments

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/

by psanford

2 subcomments

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/

by qhwudbebd

1 subcomments

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

by dtkav

1 subcomments

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...)

by mwcampbell

2 subcomments

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.

by sheepscreek

0 subcomment

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

by jmogly

1 subcomments

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.

by psanford

0 subcomment

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

by CGamesPlay

1 subcomments

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?

by a_lanfranco

0 subcomment

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.

by nextaccountic

2 subcomments

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?

by memset

1 subcomments

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?)

by skybrian

3 subcomments

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

by jamietanna

1 subcomments

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

by indigodaddy

1 subcomments

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?