{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibaybc2vyryx2ryn5hop3rn4zyiyuksfor2rtdj3s2nauibxtngbm",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mnsursi6uvc2"
  },
  "path": "/t/question-about-the-cpu-basic-quota-limit/176628#post_2",
  "publishedAt": "2026-06-08T23:20:41.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "Team & Enterprise plans — Spaces & Jobs",
    "Spaces Overview — hardware resources",
    "Spaces Overview — lifecycle management",
    "Team & Enterprise plans — Spaces & Jobs quota table",
    "Using GPU Spaces — pausing a Space",
    "CPU-Basic Spaces hitting quota limits despite “unlimited hosting”"
  ],
  "textContent": "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.\n\n* * *\n\n## Short answer\n\nYes — I think the intended workaround is to **pause previous CPU-basic Spaces** , then restart the Space you actually want to run.\n\nThe error message itself says:\n\n> “You’ve reached your CPU-basic quota limit, please upgrade your account, or pause your previous Spaces to restart this one.”\n\nSo I would interpret this as a **concurrent CPU-basic runtime limit** , not a simple daily/monthly usage quota.\n\nIn other words, the likely issue is:\n\n> too many CPU-basic Spaces are currently counted as running or occupying runtime capacity.\n\nThe practical fix is:\n\n> 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.\n\n## Why “8 Spaces” is a reasonable clue, but not a guarantee\n\nThere is some basis for the number 8.\n\nThe current Hugging Face plan comparison docs list Free accounts as having:\n\n> `Spaces – CPU-based runtime: 8 units*`\n>  `* running at the same time`\n\nReference:\n\n  * Team & Enterprise plans — Spaces & Jobs\n\n\n\nSo, based on the public docs, it is reasonable to say:\n\n> Free accounts currently appear to have around **8 concurrent CPU-based runtime units**.\n\nHowever, I would not treat this as a perfectly stable or guaranteed number.\n\nA safer wording would be:\n\n> 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.\n\nThis 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.\n\n## Current rough picture\n\nPoint | Current understanding\n---|---\nCPU Basic itself | Still the default free Space hardware for many Spaces\nDefault free CPU resources | The Spaces Overview docs describe the default environment as 2 CPU cores, 16 GB RAM, and 50 GB non-persistent disk\nFree concurrent runtime | The plan table currently shows 8 CPU-based runtime units running at the same time\nExact effective limit | May be lower or may change depending on HF-side policy/capacity/quota enforcement\n`PAUSED` Spaces | Should normally stop running and free runtime capacity\nBest practical response | Pause unused Spaces, preferably more than just one, then retry\n\nUseful docs:\n\n  * Spaces Overview — hardware resources\n  * Spaces Overview — lifecycle management\n  * Team & Enterprise plans — Spaces & Jobs quota table\n  * Using GPU Spaces — pausing a Space\n\n\n\n## Possible evolution of the limit\n\nThis is my rough interpretation of the situation:\n\nPeriod / situation | Likely behavior\n---|---\nEarlier Spaces behavior | CPU Basic often felt effectively unlimited for ordinary small Spaces\nCurrent documented state | Free accounts have a visible CPU-based runtime quota; the docs currently show 8 units running at the same time\nCurrent practical state | The real effective threshold may vary, and some users report quota errors even when the apparent active count seems low\nPractical troubleshooting assumption | Do not rely on exactly 8; pause enough Spaces to get clearly below the apparent limit\n\nSo I would avoid saying:\n\n> “Free users can always run exactly 8 CPU-basic Spaces.”\n\nI would instead say:\n\n> “The docs currently suggest 8 concurrent CPU-based runtime units, but in practice I would keep the active count lower if possible.”\n\n## Basic workaround\n\nI would try this:\n\n  1. Open your list of Spaces.\n  2. Find old or unused Spaces using CPU Basic.\n  3. Explicitly set them to **Paused**.\n  4. Do not rely only on auto-sleep; the error message specifically says to pause previous Spaces.\n  5. Wait a short while for quota/state accounting to update.\n  6. Restart only the Space you actually want to use.\n  7. If it still fails, pause more Spaces and retry.\n  8. 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.\n\n\n\n## Why pausing only one Space may not be enough\n\nPausing one active Space not fixing the issue does not necessarily mean the workaround is wrong.\n\nPossible reasons:\n\nPossibility | Explanation\n---|---\nStill above the effective quota | If the effective limit is lower than expected, pausing one Space may not be enough\nQuota accounting delay | The UI may show `PAUSED` before the backend quota counter fully updates\nTransitional states | Spaces that are starting, building, restarting, or recently stopped may still be counted temporarily\nAccount/org scope | Quota may apply across all relevant Spaces under the user or organization context\nDynamic Free-tier enforcement | The practical Free-tier limit may change depending on HF-side capacity or policy\nBackend quota-state issue | If the count is clearly low but the error remains, the quota state may be stale or broken\n\nRelated discussion:\n\n  * CPU-Basic Spaces hitting quota limits despite “unlimited hosting”\n\n\n\n## Practical rule of thumb\n\nIf the visible documented number is 8, I would not aim for exactly 8 while troubleshooting.\n\nA more conservative practical target would be:\n\nActive CPU-basic Spaces after cleanup | Interpretation\n---|---\n8 | Maybe allowed according to the visible docs, but not a safe troubleshooting target\n6 or fewer | More conservative and probably safer\n4 or fewer | Stronger test that you are clearly below quota\n0–1 and still failing | More likely to be backend/account/quota-state related\n\nThis 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.\n\n## Bottom line\n\nPausing old Spaces is the right first workaround.\n\nThe 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.\n\nSo the practical answer is:\n\n> 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.",
  "title": "Question about the CPU-Basic quota limit"
}