Hmm. Your workaround is in the right direction. In most cases, repeatedly pausing old Spaces until enough CPU-basic runtime is freed should be the first thing to try. The exact limit changes, or at least seems to be enforced somewhat flexibly, so I would pause more Spaces than the minimum if possible. If it still fails after that, it may be an HF-side quota/policy change, delayed quota accounting, or a temporary backend issue.
Short answer
Yes — I think the intended workaround is to pause previous CPU-basic Spaces, then restart the Space you actually want to run.
The error message itself says:
“You’ve reached your CPU-basic quota limit, please upgrade your account, or pause your previous Spaces to restart this one.”
So I would interpret this as a concurrent CPU-basic runtime limit, not a simple daily/monthly usage quota.
In other words, the likely issue is:
too many CPU-basic Spaces are currently counted as running or occupying runtime capacity.
The practical fix is:
pause old or unused Spaces until the number of active CPU-basic Spaces is clearly below the current Free-tier limit, wait briefly, then try restarting the target Space again.
Why “8 Spaces” is a reasonable clue, but not a guarantee
There is some basis for the number 8.
The current Hugging Face plan comparison docs list Free accounts as having:
Spaces – CPU-based runtime: 8 units*
* running at the same time
Reference:
So, based on the public docs, it is reasonable to say:
Free accounts currently appear to have around 8 concurrent CPU-based runtime units.
However, I would not treat this as a perfectly stable or guaranteed number.
A safer wording would be:
The public docs currently show 8 concurrent CPU-based runtime units for Free accounts, but the effective Free-tier limit may change or be enforced dynamically.
This distinction matters because CPU Basic used to feel effectively unlimited for many normal small Spaces, while recent behavior suggests that HF is now enforcing a stricter concurrent-runtime quota.
Current rough picture
| Point | Current understanding |
|---|---|
| CPU Basic itself | Still the default free Space hardware for many Spaces |
| Default free CPU resources | The Spaces Overview docs describe the default environment as 2 CPU cores, 16 GB RAM, and 50 GB non-persistent disk |
| Free concurrent runtime | The plan table currently shows 8 CPU-based runtime units running at the same time |
| Exact effective limit | May be lower or may change depending on HF-side policy/capacity/quota enforcement |
PAUSED Spaces |
Should normally stop running and free runtime capacity |
| Best practical response | Pause unused Spaces, preferably more than just one, then retry |
Useful docs:
- Spaces Overview — hardware resources
- Spaces Overview — lifecycle management
- Team & Enterprise plans — Spaces & Jobs quota table
- Using GPU Spaces — pausing a Space
Possible evolution of the limit
This is my rough interpretation of the situation:
| Period / situation | Likely behavior |
|---|---|
| Earlier Spaces behavior | CPU Basic often felt effectively unlimited for ordinary small Spaces |
| Current documented state | Free accounts have a visible CPU-based runtime quota; the docs currently show 8 units running at the same time |
| Current practical state | The real effective threshold may vary, and some users report quota errors even when the apparent active count seems low |
| Practical troubleshooting assumption | Do not rely on exactly 8; pause enough Spaces to get clearly below the apparent limit |
So I would avoid saying:
“Free users can always run exactly 8 CPU-basic Spaces.”
I would instead say:
“The docs currently suggest 8 concurrent CPU-based runtime units, but in practice I would keep the active count lower if possible.”
Basic workaround
I would try this:
- Open your list of Spaces.
- Find old or unused Spaces using CPU Basic.
- Explicitly set them to Paused.
- Do not rely only on auto-sleep; the error message specifically says to pause previous Spaces.
- Wait a short while for quota/state accounting to update.
- Restart only the Space you actually want to use.
- If it still fails, pause more Spaces and retry.
- If it still fails with only a few active CPU-basic Spaces, it may be an HF-side issue rather than just your Space count.
Why pausing only one Space may not be enough
Pausing one active Space not fixing the issue does not necessarily mean the workaround is wrong.
Possible reasons:
| Possibility | Explanation |
|---|---|
| Still above the effective quota | If the effective limit is lower than expected, pausing one Space may not be enough |
| Quota accounting delay | The UI may show PAUSED before the backend quota counter fully updates |
| Transitional states | Spaces that are starting, building, restarting, or recently stopped may still be counted temporarily |
| Account/org scope | Quota may apply across all relevant Spaces under the user or organization context |
| Dynamic Free-tier enforcement | The practical Free-tier limit may change depending on HF-side capacity or policy |
| Backend quota-state issue | If the count is clearly low but the error remains, the quota state may be stale or broken |
Related discussion:
Practical rule of thumb
If the visible documented number is 8, I would not aim for exactly 8 while troubleshooting.
A more conservative practical target would be:
| Active CPU-basic Spaces after cleanup | Interpretation |
|---|---|
| 8 | Maybe allowed according to the visible docs, but not a safe troubleshooting target |
| 6 or fewer | More conservative and probably safer |
| 4 or fewer | Stronger test that you are clearly below quota |
| 0–1 and still failing | More likely to be backend/account/quota-state related |
This is not an official number. It is just a practical way to debug the issue without assuming the quota is perfectly documented or perfectly stable.
Bottom line
Pausing old Spaces is the right first workaround.
The only part I would be careful about is the exact number. The docs currently provide a reason to think the Free CPU-based runtime limit is around 8 concurrent units, but the effective limit may be lower or may change over time.
So the practical answer is:
Pause unused CPU-basic Spaces until you are clearly below the apparent Free-tier limit, wait briefly, and retry. If it still fails with only a few active Spaces, it is probably not just your Space count; it may need clarification or investigation from Hugging Face.