Design and Implementation of Sprites • Hacker News Board

Re: Design and Implementation of Sprites

#81

Post by rokob » Thu, Jan 15, 2026, 9:45 PM UTC

tptacek wrote: post #79

amonks wrote: post #77

Very cool product, but I have to ask, out of personal interest: What did the bracket in the slack channel determine was “Chicago’s best sandwich”? Or the top three, even? I’m always looking for new sandwiches. Off the top of my head, I might nominate, - the pork tenderloin at JT’s - the Big L from Fontano’s (hot take, I know; it might go to Graziano’s if they hinge-cut the bread, but not doing so is a fatal flaw to m…

It's too early to say. We started the bracket back in 2020 with a nomination Google Sheet, and then the pandemic happened, and then I kept saying I'd throw a web app together for us to actually do a seeded bracket with; 5 years later, some of the restaurants have changed, so we're re-doing nominations, and we'll have bracket voting rounds starting probably in February. I owe it all to Sprites! Nhu Lan's Banh Mi #1 an…

I’m so happy I kept reading these comments and came across this gem. Sprites are cool and all but a sandwich tournament is next level.

Re: Design and Implementation of Sprites

#82

Post by blackqueeriroh » Thu, Jan 15, 2026, 9:48 PM UTC

I love my sprite.

I just want an easier way to connect to and launch sprites from my phone.

any ideas there?

Re: Design and Implementation of Sprites

#83

Post by blackqueeriroh » Thu, Jan 15, 2026, 9:49 PM UTC

Freebytes wrote: post #49

tptacek wrote: post #29

Earlier quoted context omitted.

Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console. They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering. This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we d…

There needs to be a way to see how much it is being used then and not simply the life of the Sprite.

You can. There’s a usage dashboard

Re: Design and Implementation of Sprites

#84

Post by blackqueeriroh » Thu, Jan 15, 2026, 9:52 PM UTC

adriand wrote: post #11

roywiggins wrote: post #3

I've been having fun with OpenCode's webui in a Sprite, set it up right in Termux and you can vibe code a website with a full backend from your phone. I have a Termux shortcut that sets up a port forward and pops open my web browser to the OpenCode webui. OpenCode can pick up the Sprite skill built into the containers so it can manage the instance itself (mostly setting up and destroying services). Of course you can…

What's the option for iOS? I've tried installing ish and a-shell and can't get the sprites CLI installed on either of them.

Yeah, i’ve been looking at this. The easier this is to attach to your tailnet and ssh in from inside, I don’t think you’re dealing with the proxy then.

I tried several things and this is going to be the next one.

Re: Design and Implementation of Sprites

#85

Post by blackqueeriroh » Thu, Jan 15, 2026, 9:55 PM UTC

I love sprites. I’m currently trying g to figure out how to best launch and connect to sprites from iOS. I’ve tried several things - vibe coding a terminal app is a little wild and not the best way maybe to handle this.

I believe currently the sprites CLI is using websockets to handle the connection, and the external proxy when you make a sprite public doesn’t handle websockets correctly?

Does that sound right?

Re: Design and Implementation of Sprites

#86

Post by gcr » Thu, Jan 15, 2026, 10:16 PM UTC

tptacek wrote: post #29

panarky wrote: post #25

Earlier quoted context omitted.

There's no way to stop sprites from the CLI. Supposedly they auto-stop when inactive. But I've tried multiple times and they don't stop, and it's not just Docker that prevents them from stopping. I created a new sprite and installed ffmpeg. Then exited. Next day I run `sprite ls` and it's been running continuously for 23 hours. No way to tell if I'm being billed for it or not. And the per-hour pricing is extremely ex…

Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console. They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering. This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we d…

What does "when you stop interacting with it" mean? Closing all TCP connections? When CPU usage drops to below some threshold?

Re: Design and Implementation of Sprites

#87

Post by dangoodmanUT » Thu, Jan 15, 2026, 10:27 PM UTC

Checkpoints defined by the guest, not the host, was something I was working on recently too [1] (just before this came out). Very validating!

[1] https://github.com/danthegoodman1/checker

Re: Design and Implementation of Sprites

#88

Post by disillusioned » Thu, Jan 15, 2026, 10:32 PM UTC

Made a sprint and connected via Windows Terminal and noticed it's purely white on black, not observing the normal Claude terminal color schemes... any ideas why that's the case? Am I missing something insanely simple?

Re: Design and Implementation of Sprites

#89

Post by ergonaught » Thu, Jan 15, 2026, 10:36 PM UTC

tom_ wrote: post #16

The sprite is a pretty outdated thing these days, but is the term sufficiently unused to make it free for reuse?

Not even remotely outdated. This was a terrible name to select.

Re: Design and Implementation of Sprites

#90

Post by doublet00th » Thu, Jan 15, 2026, 11:20 PM UTC

tptacek wrote: post #2

I wish I'd had more space to write about the global orchestrator design, because it's fun. The Fly Machines orchestrator goes through some trouble to keep the source of truth for each VM decentralized, owned by the physical it runs on. But there's still global state --- apps, organizations, services. That stuff is all on Postgres. Postgres keeps up with it just fine but I'd be lying if I didn't say we're always looki…

Cloudflare definitely isn't with their Durable Object design. As an infra developer/Django user myself, I know it's a pretty big paradigm shift to think in the 1 DB per user realm.

However, I do think it'll unlock "globally available" apps as a first class citizen moving forward. If Uber were made today, I suspect it'd follow the 1 DB per user and be deployed really close to the edge with providers like Fly.io, Koyeb, or Cloudflare.