How is Sprite RAM billed? Does it include Linux page cache?

Questions / Help
,
1

Hi! I’m evaluating Sprites for a GitLab Runner that stays awake using a renewable Task and mostly waits for jobs. I’m trying to estimate its idle cost, but I couldn’t find the exact definition of billable RAM.

Does the RAM GB-hour meter include Linux filesystem/page cache, including both active and inactive file pages? Which counter or formula is used? For example, is it cgroup memory.current, memory.current - inactive_file, a VM-level measurement, or something else?

Some measurements from one 8 GiB Sprite:

With the runner running but idle after a small build, a roughly five-minute sample averaged 75.8 MiB runner RSS. The guest cgroup averaged 975.3 MiB in memory.current, including 911.5 MiB of file cache, of which 684.0 MiB was inactive_file.

In a later check after stopping the runner, htop 3.4.1 showed 7.07 GiB / 8 GiB, while free -h reported approximately 128 MiB used, 7.1 GiB cache, and 7.9 GiB available.

The htop number appears to come from its upstream fallback calculation: the reported free + cached + reclaimable + buffers slightly exceeded MemTotal, so htop fell back to total minus free. I’m therefore not assuming that either htop or free matches Fly’s billing meter.

Could you clarify:

Whether active file cache, inactive file cache, and reclaimable kernel memory are included in billed RAM.

Which in-Sprite counter, if any, should match the billed memory usage.

Whether there is a per-Sprite usage metric or API we can use to validate an estimate against billed RAM GB-hours.

I found the hot-storage pricing explanation, but that concerns the local NVMe cache; my question is specifically about the RAM meter.

Thanks!

2

Hi Miguel,

Billed RAM is the cgroup v2 memory.current of the cgroup your Sprite’s workload runs in. It’s sampled about every 15 seconds and added up over the time the Sprite is running. Nothing is subtracted, so it’s not memory.current minus inactive_file, and it isn’t a VM-level number. For your estimate, keep in mind:

  • it’s GB (10^9), not GiB (2^30).
  • There’s a minimum of 0.25 GB. Each second of runtime is billed at whichever is higher: actual usage or 0.25 GB.

To your questions:

  1. Is cache included? Yes. memory.current includes active file cache, inactive file cache and kernel memory such as slab, including reclaimable slab. In your idle-runner sample, the billed figure would be about the 975.3 MiB cgroup value (≈1.02 GB), not the 75.8 MiB runner RSS.

  2. Which counter should match? Inside the Sprite, read /sys/fs/cgroup/memory.current. That’s the number you already sampled. Don’t use free or htop for this. /proc/meminfo inside a Sprite is adjusted: “used” is the cgroup’s usage minus its file cache, which is why free showed about 128 MiB, and “cached” is VM-wide. So the 7.1 GiB of cache in your later check doesn’t tell you what was being billed, but /sys/fs/cgroup/memory.current at that moment would.

  3. Per-Sprite usage metric or API? The Usage → Compute page in the dashboard breaks memory GB-hours down per Sprite, so you can compare your estimate against it. We don’t currently offer a per-Sprite usage API but it’s a frequent ask so something may be available in the future.

To estimate idle cost, I’d recomend sampling /sys/fs/cgroup/memory.current over a representative idle period and averaging it (GB, units as discussed above). Apply the 0.25 GB floor, then multiply by the hours the Sprite is running. Page cache left over from builds counts until the kernel reclaims it, so sample over a realistic stretch after jobs rather than just after the runner starts.

Hope that helps!