Since there still seems to be.a bug with sprites not going to sleep - it is possible to create a checkpoint for a sprite and then destroy it and restore it? If so, I would potentially just destroy sprites when I no longer need them and then restore them since there is no force sleep / suspend option. I get the need for this goes away once the sleeping works.
This would also be helpful in forking new sprites based on a good starting checkpoint.
Heya, as @bglw mentioned in the other thread, even though your sprite might still show running, it has begun the suspend process and is no longer being billed. So if the concern here is about being billed for sprites that should be inactive, it’s not actually a problem (although definitely understand the concern)!
When a sprite is inactive, you’re only paying for cold storage (we just updated storage pricing to distinguish between “cold” and “hot”). Cold storage is very cheap ($0.02/GB-month), and destroying a sprite but continuing to store a checkpoint wouldn’t really be any cheaper, because the checkpoint is also stored in cold storage and we’d probably price checkpoint storage identically.
Hi @jfent I confirmed that once you destroy a sprite it’s gone and there is no way to restore it with a checkpoint.
On the sleep issue that’s good to know. Do you have a sense of when there will be a fix so it properly shows the status? Right now there is no way of knowing which makes this feel like a pretty critical bug given that that’s one of the core value props vs. going with a permanent VM. I’m REALLY loving a ton of the design decisions and using sprites so far. I’m a bit concerned on the lack of clarity on the comms relating to this. Just tell me it’s a priority and being fixed so I can continue to invest in using this. 
The price and the features are right. Since there is currently NO way to see your usage this is a pretty critically bad bug that’s been pending for a few days now from what I can tell.
Also to note it takes some engineering on the user end to know if we have processes running that are keeping the sprite live so we can’t really build reliable systems that manage cost until we have visibility. For example, I’d love to confirm that I can keep a bun server running and it’ll sleep if it receives no activity.
@bglw (staff member) is communicating in the pre-existing thread. I’d suggest moving to posting in/watching that thread - it’s where we are giving updates on this particular bug.
As I understand it, the problem is fixed for new Sprites and we are investigating whether/how to deploy a fix to existing Sprites.
As mentioned above, it’s a display issue, you’re not being billed. What is the ongoing concern over value prop?
Here are the conditions under which Sprites will go to sleep: Working with Sprites | Sprites
I’m not sure I follow your concern - it seems like you might be referring to the stale running state once again.
I’ll check the other thread. I’m creating new threads and and i believe still getting the error (others have reported this too).
If this works I have no concerns (and I’m sure it will). The value prop point I was trying to make is you can create these and they smartly turn off is a huge selling point especially if you want to set these up to run coding agents etc.
Thanks for your help.
Yes, that is what is happening. The running state is stale. Without putting too fine a point on it, you are not being billed for these stale running Sprites.
Hi quick one - Working with Sprites | Sprites
The docs on the site take you to this:
The docs you just shared are much more useful but I don’t think are somewhere users can access them.
There are people working on Sprites docs, I believe they’re going to update the links on the landing page soon.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.