# Sprites becoming non-responsive after usage

**URL:** <https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137>\
**Category:** Questions / Help\
**Tags:** issue, sprites, login-only\
**Created:** [February 16, 2026, 12:50am UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137 "2026-02-16T00:50:45Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![sam20260215](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sam20260215](https://community.fly.io/u/sam20260215)\
**Post date:** [February 16, 2026, 12:50am UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/1 "2026-02-16T00:50:45Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mat0](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@mat0](https://community.fly.io/u/mat0)\
**Post date:** [February 16, 2026, 6:58am UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/2 "2026-02-16T06:58:54Z")

</div>

I’m also getting timeouts.

```console
$ 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?

```console
┌───────────┬───────┬──────────┐
│ 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.

```json
{"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}

```

---

<div class="post-metadata">

**Author:** ![protean](https://avatars.discourse-cdn.com/v4/letter/p/edb3f5/32.png) [@protean](https://community.fly.io/u/protean)\
**Post date:** [February 17, 2026, 6:26am UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/4 "2026-02-17T06:26:08Z")

</div>

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.

```auto

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

```

---

<div class="post-metadata">

**Author:** ![nihakue](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/nihakue/32/50820_2.png) [@nihakue](https://community.fly.io/u/nihakue)\
**Post date:** [February 17, 2026, 11:31am UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/5 "2026-02-17T11:31:46Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![protean](https://avatars.discourse-cdn.com/v4/letter/p/edb3f5/32.png) [@protean](https://community.fly.io/u/protean)\
**Post date:** [February 17, 2026, 5:45pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/6 "2026-02-17T17:45:05Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mayailurus](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/mayailurus/32/17593_2.png) [@mayailurus](https://community.fly.io/u/mayailurus)\
**Post date:** [February 17, 2026, 6:29pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/7 "2026-02-17T18:29:49Z")

</div>

> [@protean](#):
>
> 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](https://community.fly.io/t/more-sprites-plans/26857) come with email Support, if I’m reading the [release notes](https://sprites.dev/release-notes#release-2026-02-04) correctly. That’s a bit pricey when you’re just testing things out, but if you do already have one…

---

<div class="post-metadata">

**Author:** ![protean](https://avatars.discourse-cdn.com/v4/letter/p/edb3f5/32.png) [@protean](https://community.fly.io/u/protean)\
**Post date:** [February 17, 2026, 6:36pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/9 "2026-02-17T18:36:55Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mat0](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@mat0](https://community.fly.io/u/mat0)\
**Post date:** [February 17, 2026, 7:12pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/10 "2026-02-17T19:12:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![billk](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@billk](https://community.fly.io/u/billk)\
**Post date:** [February 17, 2026, 11:15pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/11 "2026-02-17T23:15:23Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Matt\_C\_Fly](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@Matt\_C\_Fly](https://community.fly.io/u/Matt_C_Fly)\
**Post date:** [February 17, 2026, 11:39pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/12 "2026-02-17T23:39:28Z")

</div>

> [@New sprites sometimes randomly won't respond after creation](https://community.fly.io/t/new-sprites-sometimes-randomly-wont-respond-after-creation/27135/8):
>
> Hi All, Appreciate your patience, as this is a new product. We are aware of these reports and are tracking a number of Sprites bugs that we are working to fix quickly. We have new releases coming very soon (in the next week or so) that should address these issues.

Hello, linking my response to the other thread on this, but we hear you and we are working rapidly to address!

---

<div class="post-metadata">

**Author:** ![amartsinovich](https://avatars.discourse-cdn.com/v4/letter/a/f05b48/32.png) [@amartsinovich](https://community.fly.io/u/amartsinovich)\
**Post date:** [February 18, 2026, 12:41am UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/13 "2026-02-18T00:41:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sam20260215](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sam20260215](https://community.fly.io/u/sam20260215)\
**Post date:** [February 18, 2026, 8:12am UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/14 "2026-02-18T08:12:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rudyjellis-sbl](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/rudyjellis-sbl/32/44439_2.png) [@rudyjellis-sbl](https://community.fly.io/u/rudyjellis-sbl)\
**Post date:** [February 18, 2026, 11:23am UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/15 "2026-02-18T11:23:27Z")

</div>

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.

 ![image](https://global.discourse-cdn.com/fly1/original/3X/b/9/b9598bd936a94589ffde5969fc5766fea34717b5.png)

Any way to diagnose what might be the issue. Happy to help.

---

<div class="post-metadata">

**Author:** ![GiforGif](https://avatars.discourse-cdn.com/v4/letter/g/258eb7/32.png) [@GiforGif](https://community.fly.io/u/GiforGif)\
**Post date:** [February 18, 2026, 3:55pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/16 "2026-02-18T15:55:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![GiforGif](https://avatars.discourse-cdn.com/v4/letter/g/258eb7/32.png) [@GiforGif](https://community.fly.io/u/GiforGif)\
**Post date:** [February 20, 2026, 8:03pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/17 "2026-02-20T20:03:11Z")

</div>

Still cannot access the locked sprite, days later.

---

<div class="post-metadata">

**Author:** ![mcintyre1994](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/mcintyre1994/32/653_2.png) [@mcintyre1994](https://community.fly.io/u/mcintyre1994)\
**Post date:** [February 20, 2026, 10:02pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/18 "2026-02-20T22:02:16Z")

</div>

I’ve noticed a lot of this too. Some notes:

- I think if you create a sprite with a name you’ve used before it messes up something and that sprite usually doesn’t work
- Long-running non-tty sprite exec commands seem to be quite shaky, and sometimes seem to brick sprites
- If your client doesn’t close websockets properly after short-running execs, that seems to be able to brick sprites
- Services seem to be more reliable for long-running non-interactive tasks, from what I’ve seen so far. Potentially helpful: there’s an undocumented DELETE /sprites/{name}/services/{service-name} for cleaning them up. Re-using the same service name doesn’t cause any issues

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

---

<div class="post-metadata">

**Author:** ![davidalejandro](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/davidalejandro/32/38856_2.png) [@davidalejandro](https://community.fly.io/u/davidalejandro)\
**Post date:** [February 22, 2026, 7:50pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/19 "2026-02-22T19:50:03Z")

</div>

Happening to me too, can’t access my sprite anymore:

```auto
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

```

```auto
┌────┬───────┬──────────┐
│NAME│STATUS │ CREATED │
├────┼───────┼──────────┤
│test│running│7 days ago│
└────┴───────┴──────────┘

Total: 1 sprite(s)

```

---

<div class="post-metadata">

**Author:** ![GiforGif](https://avatars.discourse-cdn.com/v4/letter/g/258eb7/32.png) [@GiforGif](https://community.fly.io/u/GiforGif)\
**Post date:** [February 23, 2026, 6:37pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/20 "2026-02-23T18:37:50Z")

</div>

My bad sprite is now status: `cold` but I still cannot access it

---

<div class="post-metadata">

**Author:** ![Sam-Fly](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/sam-fly/32/48731_2.png) [@Sam-Fly](https://community.fly.io/u/Sam-Fly)\
**Post date:** [February 23, 2026, 10:47pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/21 "2026-02-23T22:47:30Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![GiforGif](https://avatars.discourse-cdn.com/v4/letter/g/258eb7/32.png) [@GiforGif](https://community.fly.io/u/GiforGif)\
**Post date:** [February 23, 2026, 10:59pm UTC](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137/22 "2026-02-23T22:59:45Z")

</div>

Thank you, yes I was just able to connect

[Next page](https://community.fly.io/t/sprites-becoming-non-responsive-after-usage/27137.md?page=2)
