I noticed over the past few days that after using a sprite (Claude Code session), it gets slower and slower. For example, a ‘git status’ can take a minute to respond.
After a while, a sprite often becomes completely non-responsive:
>sprite c
Error: failed to start sprite command: failed to connect: read tcp {addr}:{port}->{addr}:443: i/o timeout
I’m also getting timeouts.
$ sprite checkpoint ls -s foo
Error: Failed to list checkpoints: failed to make request: Get "https://api.sprites.dev/v1/sprites/foo/checkpoints": context deadline exceeded
While sprite checkpoint ls -s <some-different-sprite> works fine.
Does sprite list also result in an “unknown” status for your unresponsive sprite?
┌───────────┬───────┬──────────┐
│ NAME │STATUS │ CREATED │
├───────────┼───────┼──────────┤
│foo │unknown│4 days ago│
Also odd that last_started_at is null, even though this sprite ran and paused a few times on different days before it ended up in this broken state. The updated_at time from yesterday might be the time when the issue started.
{"id":"sprite-0e87ca3d-c378-4262-bf85-4fadd9540a66","name":"foo","status":"unknown","version":"0.0.1-rc32","url":"https://foo-h2ni.sprites.app","updated_at":"2026-02-15T20:57:50.054356Z","created_at":"2026-02-11T19:28:43.145668Z","organization":"<redacted>","url_settings":{"auth":"sprite"},"last_active_at":null,"last_started_at":null,"environment_version":null}
Having the same issue, no idea what’s going on but this is really questioning the recent investments I’ve done into some agent infrastructure based leveraging sprites.
maxpleaner@Maxs-MacBook-Pro ~/D/C/n/scripts (master)> sprite ls
Sprites in organization nameless-identity:
┌────────────┬──────┬──────────┐
│ NAME │STATUS│ CREATED │
├────────────┼──────┼──────────┤
│show-scraper│warm │6 days ago│
│test2 │warm │ 18m ago│
└────────────┴──────┴──────────┘
Total: 2 sprite(s)
maxpleaner@Maxs-MacBook-Pro ~/D/C/n/scripts (master)> sprite -s test2 console
Error: connection closed
maxpleaner@Maxs-MacBook-Pro ~/D/C/n/scripts (master)> sprite -s test2 console
Error: connection closed
Nothing new to report, just want to chime in that I was experiencing the same sequence of steps/symptoms. Perhaps a recent change in Claude / Sprites / both?
@nihakue I am using Codex, so we can rule out Claude as the source. I think it’s fairly safe to assume Sprites are the problem here because I mean, the problem is in connecting to the Sprite.
It’s also crazy that we need to use some community forum to report breaking bugs like this.
Fly.io does read the forum for bug reports, even if they don’t leap into the fray themselves by default, 
. (I don’t work for them myself, but that’s what they’ve said in the past.)
It would be nice to have a mechanism for lighter-weight “we’ve noticed and are / will be looking at this” kinds of feedback, though…
Some other forums that run on the same software (Discourse) have started using categories to similar effect. In this case, maybe there could be an Under Investigation category that noticed platform issue threads could be moved into by the mods, 
.
Aside: Most of the Sprites plans come with email Support, if I’m reading the release notes correctly. That’s a bit pricey when you’re just testing things out, but if you do already have one…
@mayailurus I am still on the free plan, but it seems they do have support plans which are prorated, so I paid $10 for 10 days and messaged them about it.
Thanks for reporting this - we’ve seen, and are investigating, other reports of similar Sprites behavior. We are preparing a new version of the Sprite runtime which should help.
At first, I thought that the unknown status correlated with the timeouts when trying to list checkpoint or to start the Sprite. But now I see a Sprite having the unknown status while it can be started correctly and changes to status running. But the broken Sprite still has the timeout issues.
So, the status column in sprite list doesn’t actually tell anything about which Sprites are broken.
This issue was a good reminder to me to not treat a built-in checkpointing feature as a replacement for proper backups (in a different cloud or something). Though I’m still hoping to regain read access to the broken Sprite’s filesystem since I didn’t make a backup of that.
Just raising my hand to say I am running into the same issue. One of the main draws of Sprites for me was the easy filesystem persistence and checkpoint features. Now I have a Sprite that has become unresponsive and throws errors if I try to restore a previous checkpoint. This is nowhere near acceptable, even for a beta product.
Hello, linking my response to the other thread on this, but we hear you and we are working rapidly to address!
I’m also experiencing this. My sprite became completely unresponsive. Without a way to reboot it, I’m not sure what else I can do.
One odd observation I have is that the sprites that end up becoming non-responsive have a hostname of “sprite”, so the console shows
sprite@sprite:~$
while the ones that behave normally have a hostname that is the sprite name:
“sprite@:~$
These sprites were all created with sprite version 0.0.1-rc31 (pretty recent)
The problem often happens after I connect to the sprite, and after a few commands, it becomes non-responsive. At this point, its status still shows “active”.
Side note - I’m also seeing some sprites with a status of “unknown”, but I’m able to connect to it and run commands on it.
I to have a sprite that I am unable to log back into, that was last night.
This morning I’ve been sitting on this prompt fro 2+ mins.
Any way to diagnose what might be the issue. Happy to help.
Same issue here. I cannot connect to my existing running sprite. I can create new sprites no problem, and as soon as I disconnect it goes to a warm state. The original sprite is just running idle. I also cannot create a new checkpoint. If only there was a way to reboot it somehow.
Still cannot access the locked sprite, days later.
I’ve noticed a lot of this too. Some notes:
I really hope they fix the robustness issues here because sprites are such a cool primitive and feel like such a good answer to the AI sandbox problem
Happening to me too, can’t access my sprite anymore:
sprite console -s testError: failed to start sprite command: failed to connect: read tcp [2806:2f0:57a1:e105:98c6:ca97:cb9e:e0df]:58129->[2a09:8280:1::99:d7b3:0]:443: i/o timeout
┌────┬───────┬──────────┐
│NAME│STATUS │ CREATED │
├────┼───────┼──────────┤
│test│running│7 days ago│
└────┴───────┴──────────┘
Total: 1 sprite(s)
My bad sprite is now status: cold but I still cannot access it
@GiforGif @davidalejandro @rudyjellis-sbl Can you check the sprites you were having issues with again and see if you’re still unable to console / exec against them? They should be good now.
In short we identified an issue with either versions of sprites that could cause them to lockup due to IO issues in some cases. This has been fixed and performance is improved in versions rc35+. I’ve updated those Sprites to rc39 and they should be good. Let me know if you still have issues with any of them
We’re working on automatic updates for existing sprites, that’s a WIP right now though.
Thank you, yes I was just able to connect