$ sprite ls
Sprites in organization ←[96mtest←[0m:┌────┬──────┬───────┐
│NAME│STATUS│CREATED│
├────┼──────┼───────┤
│test│warm │ 5h ago│
└────┴──────┴───────┘Total: 1 sprite(s)
Hey guys, I just created a sprite 5 hours ago, immediately exited. Now it’s still warm.
Shouldn’t it become hibernating after 30 seconds?
Also, is there any way to reboot the sprite or is this against the philosophy? “shutdown” and “reboot” both are not in the shell by default.
Thanks.
This is expected - Sprites move to warm more or less as soon as they can (when they detect inactivity). There’re some rules around when a Sprite will move from warm to cold, but ultimately this isn’t something users really need to care too much about. Most will probably only be concerned with their “max warm Sprites” limit.
Warm Sprites are much quicker to boot back up - in fact for the first ~10 mins of warm, your Sprite is still “running” but CPU util drops to 0 and RAM util drops significantly. After ~10 mins, we suspend the Sprite (suspended Sprites are still warm).
What need do you have for rebooting out of interest?
Thanks for the quick reply!
The background reason why I am asking these is, I would like to figure out the realistic cost of sprites.
Currently these are what I observed while playing with the trial credits:
As for the reboot question, basically if a program in sprite runs haywire and causes some dead lock (thus blocking console access), it seems we can only either restore it with a checkpoint or destroy it. In some cases, neither of these might be the better option if there is a way to just reboot the sprite.
Overall I like the idea of sprite very much. It’s just that the cost part is confusing because there is no way to actually see it as of now. I would like to evaluate more once there is more visibility. Thanks 
I don’t think they are charging anyone yet. If i were to take a guess, they may be tracking usage but not charging anyone anything because of some bugs or just to gauge interest. I paid for a month and it says i haven’t used it according to my usage on the billing page or whatever and i know that’s not true.
Yeah that makes sense for the situation. But missing such important insight also makes some of us…”indecisive” about whether to use it or not 
I haven’t cross-checked the numbers with anything, but daily sprites costs show up in the “Cost Explorer” linked from the “Billing” page of the Fly.io dashboard (look in the “Invoices” section). It’s not detailed, though.
The Fly.io invoice preview/cost explorer will both show Sprites charges. Here’s a screenshot from my preview invoice:
and cost explorer:
Could you explain why you’re concerned about this? As I said, this is expected behaviour, and warm Sprites do not bill (except for the tiny amounts of RAM they use in the initial 10 mins after moving to warm but before being fully suspended).
Thanks for the screenshots. On my fly.io usage & billing dashboard, as well as cost explorer, I see 0.00 in all columns. That probably makes sense because I’m still using the trial credits to evaluate sprites.
In addition, the bottom right I finally found the “Spirtes: Trial Credit” block. There is no breakdown, but I’ll take it for now.
Could you explain why you’re concerned about this? As I said, this is expected behaviour, and
warmSprites do not bill (except for the tiny amounts of RAM they use in the initial 10 mins after moving towarmbut before being fully suspended).
Thanks for the additional explanation. After experimenting more I realized that there is actually a “running” state of the sprite (which is the state sprite is in if I console to it).
On the other side, in the “billing” section of https://sprites.dev/ , I see there is “hot” vs “cold”. So which states map to “hot”? Is it only “running”, or both “running” and “warm”? I’d like to suggest making these terms consistent between the docs and CLI, to avoid confusion.
There’s a tooltip explaining what hot storage is on that page:
When your Sprite is first moved to warm (that first 10 minutes I mentioned upthread), since the VM is still running, I believe we may still bill for hot storage - I’m seeking clarification on this.
After the Sprite is suspended, no hot storage is billed. The way we bill for CPU/RAM/hot storage is by having the Sprite report utilisation of these metrics itself, so once the VM is suspended/stopped, there’s no possible way to be billed (except, of course, for cold storage).
Again thanks for the explanation!
You know, it’s fun because that tooltip did attract my attention when I first viewed the page on mobile. I was thinking “Great, a tooltip button that is not interactive on mobile. Are these guys using Nuxt UI?” And then of course I forgot to check it again on a PC 
After your explanation it’s a lot more clear.
There is still a question left about “when does the storage become cold storage”. Since I never see my sprite’s status become “cold”, is it correct to assume that the status of a sprite will never become “cold”, and only the storage will become cold when the sprite has been in “warm” for longer than 10 mins?
Sorry for digging so much into the terminologies.
Okay I can see the cold/hot terminology is confusing here, and we’ll think about renaming these potentially.
Right now, what we’re calling “cold” storage is everything we’re storing in Tigris. Which is the entire filesystem of your Sprite. Since we have to keep this around 100% of the time (a Sprite’s data has to be stored somewhere 100% of the time, else there’ll be data loss), you are always billed for cold storage for all of your Sprites, until your destroy them. But that’s why cold storage is extremely cheap - $0.02/GB-month.
“Hot” storage is the amount of local NVMe that we need to use for caching when your Sprite is running. Since we can offload this whenever your Sprite is not running (i.e. when your Sprite is warm/cold), you are only billed for hot storage when your Sprite is actually running (as mentioned, Sprites self-report their usage of CPU/RAM/hot storage, so there’s no way we can bill you when your Sprite is not running).
The amount of hot storage used by your Sprite depends a lot on the workload. E.g. some Sprites’ workloads might require touching most/all of their filesystem regularly, in which case we’ll end up caching a lot of the filesystem. Others (probably most) will in general touch a small fraction of the filesystem at any one time, and so we don’t need to keep that much cached at once.
So just to directly address the q: storage doesn’t switch between hot and cold, those are just two different kinds of storage we utilise and therefore for which we bill. Cold storage is what we keep in Tigris, hot storage is what we need to cache on a local NVMe volume.
Hey again, just to mention we’ve updated the naming so that we now refer to “storage” and “hot storage”. “Storage” is the stuff in Tigris, “hot storage” is the local NVMe stuff.
Hot storage is indeed only billed when your Sprite is running. “Storage” is billed all the time. Hopefully this naming is a bit clearer and less confusing.
Also an update to this for anyone visiting this thread going forward - we now completely turn of billing when a Sprite moves from running to warm. So you are only billed for CPU/RAM/hot storage when your Sprite is running, and not billed at all when warm.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
