tpmjs is a registry of ai sdk npm packages (i created them for sprites), which you can add to personal collections, we automatically server your collections as mcp servers if you want.
Creating sprites in an example chat bot -> https://imgur.com/a/ETNxR1o
Creating sprites in claude desktop -> https://imgur.com/myC0U28
Listing out my sprites in claude desktop -> https://imgur.com/rgBU0jm
---
You can view the collection of tools here -> https://tpmjs.com/ajax/collections/sprites (fork it to use it yourself)
I'm looking into exe.dev and sprites.dev to build out extra features into tpmjs, agent sandboxes make a lot of sense.
Documentation is sparse, or not even available? The API docs don’t tell you much about the service itself, and a Google search for docs returns an inaccessible website as the first result (https://docs.sprites.dev). Blog posts and forum threads and Claude skills shouldn’t be a substitute.
The snappiness of the sprites is very cool and I can definitely see it integrating into future Claude Code workflows. But the lack of a base container images means you’re still doing setup work on the sprite before you can begin development. I understand the philosophy is that sandboxes should be persistent, but Claude Code sessions also work better when isolated from each other, so it’d be nice to have some precepts to get a workspace setup quickly (given agentic coding is clearly a target).
I also found the CLI unintuitive but maybe that was just me!
So very cool idea but left with the impression that the Fly.io team’s should have spent a couple weeks on polish before shipping.
I've been needling Kurt for several months now that if we wait until it's polished enough that we don't see comments like this, we're doing it wrong.
I'm really jazzed about this particular product as a product (I just really enjoy using it), but the post is mostly about how we built it, and deliberately not much about how best to use it.
Incredible (truly, incredible, world-class) engineers that somehow lack that final 10% of polish/naming/documentation that makes things...well, seriously usable.
I remember last time I tried them the bizarre hoops/documentation around database creation. I _think_ they solved that but I remember at the time it felt almost like I was getting looked down upon as a user. Ugh, you need clarity? how amateurish!
It neatly did so and "registered" it as a sprite service. Then I exited my session, waiting for the sprite to go idle, but I don't think it ever does.. Still have it active. Don't know how to idle it.
Can't tell for sure if this means I'm losing credits as there is no billing usage shown anywhere.
Also waiting for the moment where I can launch a sprite from another's checkpoint.
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 expensive.
So for now it's `sprite destroy -s spritename`.
Maybe I'll check it out again in a few months after the fly team has iterated on this a few times.
* 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 don't make our money by billing people for stuff they don't want. We've always gone out of our way not to nickel-and-dime casual users and we're trying hard to find new ways to lean into that here.
(Destroying a Sprite you're done with is a perfectly reasonable move; they're disposable.)
Can't find any place in CLI or web UI to see how many minutes are charged for CPU, memory, storage.
$ sprite ls
Sprites in organization <redacted>:
┌────┬───────┬────────┐
│NAME│STATUS │CREATED │
├────┼───────┼────────┤
│duh │running│ 23h ago│
└────┴───────┴────────┘
Total: 1 sprite(s)They are advocated as Linux machines. How about daemons then, or cron jobs? What semantics can we expect from them?
I love the idea and most of the execution, I've really enjoyed getting my first sprite configured just the way I want it. It just needs the idling feature to work as advertised before I think I can use it as cost-effectively as it promises.
1. A timeout after the last console session is exited 2. Force idle using the CLI
$ sprite version
sprite version v0.0.1-rc30
$ sprite create quk
Error creating sprite: failed to create sprite: Post "https://api.sprites.dev/v1/sprites": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
$ sprite ls
Sprites in organization <redacted>:
┌────┬───────┬────────┐
│NAME│STATUS │CREATED │
├────┼───────┼────────┤
│quk │running│14m ago │
└────┴───────┴────────┘
Total: 1 sprite(s)and you should be good
Tried with xterm, tilix and ghostty, all of which support the title setter escape sequence locally. For some reason, these get messed up (smells like edge case with escaping) and the result looks like this:
$ sprite c ": history-search-backward'
\]\u@\h\[\]:\[\]\w\[\]\$ ' ": history-search-forward'sprite@sprite:~$
"sprite@sprite:~$
Of course you can do similar with a VPS, but this makes it very easy (and cheap!) to spin up an entire new machine with a public url and HTTPS whenever you want to.
I tried several things and this is going to be the next one.
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?
(Or in other words, a graphical object on screen that is not present in a framebuffer of any kind.)
https://www.merriam-webster.com/dictionary/sprite
I personally associate the term Shakespeare's The Tempest: https://en.wikipedia.org/wiki/Ariel_(The_Tempest)
I think people can get bogged down in the technical weeds over what a sprite is in graphics. Historically it started out as mini graphics overlays in hardware. There was a transition period motivated by Amiga documentation to have Sprites and Bobs, to distinguish, and perhaps advertise, the use of the Blitter. When software or Blitter Sprites became nearly ubiquitous, they returned to simply being called Sprites, the fairly rare use of the original form became known as Hardware Sprites. Usually it was only mouse pointers that remained as Hardware Sprites
Obviously the term Hardware Sprites is not strictly a distinguishing label either. They are all controlled by software using hardware with some degree of balance between the two.
Is that what you guys are thinking of? I get that Sprites are a new primitive, but I feel confused as hell about what exactly I'd want to do with it.
I realize this is all very fresh, but still wondering…
I just want an easier way to connect to and launch sprites from my phone.
any ideas there?
Also I like a lot of what you get built-in with Fly machines(ex:Grafana). So I am curious how this would fit in my workflow. Maybe Sprites for rapid development and toy projects, and move to a Fly machine when I need something a little more beefy?
Looking forward to checking this out.
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 looking out the corner of our eyes on metrics.
The global state for Sprites is on object storage. Each organization gets a separate SQLite database, and that database is synchronized to object storage with Litestream.io (Lightstream is load bearing in a bunch of places here; solid as a rock for us).
I think people really still sleep on the "multiple SQLite database" backing store design.
OrgTracker.with_repo(org_id, fn ->
repo.all(from sprite in "sprites", select: ...)
That will find or place an Elixir process on the cluster and rpc the target node with our code. Placements can be sticky so they pin to a machine so we don't have to suck down the db every start, but we also balance out the load and handle failover of durable processes automatically. Combined with litestream, the result is distributed sqlite with failover while treating it essentially like a locally reachable sqlite db. Yes there is the speed of light to contend with, but by sending the execution across the wire rather than individual queries, we only ever pay a single hop to reach the process/sqlite.
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 me)
- the Cambodian fried chicken sandwich that’s occasionally available at Hermosa
- honorable mention: the comically oversized chicken torta at Migos
(Edit: I inexcusably transposed Bari and Fontano’s; the nomination is intended for Fontano’s)
Nhu Lan's Banh Mi #1 and JPG's Muffaletta are the top 2 current noms, but I think the Tempesta B. Franklin is a sleeper, and the Phodega Viet Dip has a cheering section and I haven't tried it yet. The joy of doing an actual bracket is that it'll involve people doing field trips to have their first Mr. D's Pork Shish-Ka-Bob sandwich, or the Alpine Combo.
It's a 16 sandwich tournament and we're at like 26 nominations right now so it'll be interesting to see what happens.
I’d love to see a post of some kind when it’s all settled; you’re doing the lord’s work here.
>Now, today, under the hood, Sprites are still Fly Machines. But they all run from a standard container.
So its basically a faster VM?
What are some use cases for this that benefit from the faster boot time?
/fs/read?path=X | GET | Read file (supports Range headers)
/fs/write?path=X | PUT | Write file (body = raw bytes)
/fs/list?path=X | GET | List directory
/fs/delete?path=X | DELETE/POST | Delete files/dirs
/fs/rename | POST | Rename/move
/fs/copy | POST | Copy files/dirs
/fs/chmod | POST | Change permissions
/fs/chown | POST | Change ownership
/fs/watch | GET (WebSock) | Watch for filesystem changes
But I've just been using magic-wormhole for this.
Pull from sprite to local: sprite exec -s my-sprite sh -c "tar -czf - /home/sprite/<my_dir>" | tar -xzf - -C ./
Push from local to sprite: COPYFILE_DISABLE=1 tar -czf - <my_dir> | sprite exec -s my-sprite sh -c "tar -xzf - -C /home/sprite/"
npm install hasn't bothered me, but I know of people with massive npm issues that would like faster first installs. Fortunately, it's incrementally quicker after that.
The storage performs pretty well for running claude + my dev. It'll improve immensely in the next few months, though. We should be able to get near native NVMe speeds for the working storage set on reads/writes/flush/fua.
While looking into giving fly another shot as a cloud provider even though I think it's still pretty much a commodity for me, I found an issue in Google: I searched for "fly.io sao paolo" and the title of the first result on fly.io is "Regiones · Fly Docs", translated from english to Spanish. While I find the translation in titles on Google annoying, I haven't often seen the characters messed up like this. I reproduced this in Incognito at this URL: https://www.google.com/search?hl=es&q=fly.io%20sao%20paolo
why would anyone do anything else, anywhere else?
Low and behold, yet another AI product selling advertisement + veiled promotion on HN.
It's almost as if the guidelines don't matter anymore. From [0].
'Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.'