101–110 of 195 posts
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?
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.
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…
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.
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…
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 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…
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…
Probably because you didn't include the content type header?
a "quick start" really should just work when you copy paste them.
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.
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.