Spaces:
Running
Prepaid credits never engage: ZeroGPU refuses when the reservation exceeds the remaining free quota
Summary
The tooltip on the ZeroGPU meter in account billing says:
Up to 40 min of ZeroGPU usage per day. Usage over the quota is billed to your credits.
On a PRO account with a positive prepaid credit balance, this never happens. Once the daily quota is nearly exhausted, every call is refused instead of billing to credits, and the billing breakdown shows that no ZeroGPU usage has ever been charged.
What I see
PRO account, daily meter at 39.9 / 40 minutes used, prepaid credits available. Every Space call returns:
You have exceeded your Pro ZeroGPU quota (180s requested vs. 5s left).
Try again in 8:36:04. Add credits to keep using ZeroGPU.
Current period billing shows ZeroGPU Usage: No usage โ not one second has ever been billed to credits.
Correction to my original framing
I first wrote that the reservation is a fixed platform floor. That is wrong, and #81 and #165 explain why: the "N s requested" figure comes from the Space's own @spaces.GPU(duration=N), and a Space that declares none reserves the maximum. So the size of the reservation is the Space author's choice, not the platform's.
That is not what I am reporting. My report is about what happens when the reservation โ whatever its size โ exceeds the remaining free quota: the call is refused rather than billed to credits.
Why the remainder is unreachable in practice
As a caller I cannot change another author's declared duration, and the reservations I encounter are:
| Space | refusal reports |
|---|---|
evalstate/flux1_schnell |
15 s (even at 256x256, 1 step) |
mcp-tools/z-image-turbo |
60 s |
mcp-tools/wan-2-2-first-last-frame |
180 s |
(That last Space declares duration=120 in its source and the refusal reports 180 s, so the requested figure appears to be scaled up from the declared one.)
I deliberately drained the quota from 86 s down to 5 s with small calls, expecting credits to engage at zero. They did not, and no Space can start once the remainder is below its own reservation. So the "over the quota" state โ the only state in which credit billing would begin โ is never reached. The tail of the quota is stranded and the prepaid balance cannot be spent at all.
There are several older threads about the same refusal message (#70, #81, #140, #150, #165, #182), but I could not find one asking this specific question, so I am raising it separately.
Secondary observation (possibly related to #177)
Opening a Space at https://<space>.hf.space directly, while signed in, drops the PRO identity. The error there reads "your ZeroGPU quota" rather than "your Pro ZeroGPU quota", and reports a separate, much smaller allowance with its own reset time. Going through https://huggingface.co/spaces/..., where the iframe receives the token, reports the Pro quota. That difference in wording is a reliable way to tell which pool a call landed in, and might be worth surfacing more explicitly.
Question
Is ZeroGPU Space usage meant to bill to prepaid credits, as the tooltip states? If so, could the duration check fall through to credit billing instead of refusing, when the reservation exceeds the remaining free quota?