{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreih3wjjk7wvp4r3hflgcnyn6m534kohdolfv473y7rrnerkzmy6s2u",
"uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3moyhaxjrhsn2"
},
"path": "/t/spaces-tokens-no-longer-work-and-no-generated-files-are-being-saved/177110#post_2",
"publishedAt": "2026-06-23T22:01:37.000Z",
"site": "https://discuss.huggingface.co",
"tags": [
"Disk usage on Spaces",
"(click for more details)",
"@spaces.GPU"
],
"textContent": "Hmm, I can’t fully isolate it, but one thing is clear: this is a pretty rare symptom:\n\n* * *\n\nI would first treat this as a **ZeroGPU lifecycle / cleanup problem** , not as a normal “my Hugging Face personal access token expired” problem.\n\nThe useful user-side next steps are probably:\n\n 1. **Do not expose the full`allowToken` publicly.** Redact it, even if it is probably not your normal `HF_TOKEN`.\n 2. **Check the few log lines immediately before`/release`.** The important part is likely before the line you posted.\n 3. **Print your package versions** , especially `spaces`, `gradio`, `huggingface_hub`, `torch`, `diffusers`, and `transformers`.\n 4. **Check whether`/schedule` and `/allow` returned 200** before `/release` returned 404.\n 5. **Check whether there is a Python traceback before the`/release` line.**\n 6. **Test whether the failure is really generation, or only save/output delivery.**\n 7. **Try a minimal ZeroGPU file-output test.**\n 8. **Try CPU or a non-ZeroGPU GPU if possible** , just to separate your save/output code from the ZeroGPU lifecycle.\n 9. **Clarify where the files are being saved** : temp path, local Space disk, `/data`, Storage Bucket, dataset repo, model repo, or external storage.\n 10. **If you report this to HF staff, include timestamp, Space URL, versions, and redacted logs around`schedule`, `allow`, and `release`.**\n\n\n\nThe line you posted is:\n\n\n POST http://device-api.zero/release?allowToken=...&fail=true\n HTTP/1.1 404 Not Found\n\n\nThe important part is that this is `device-api.zero/release`, not a normal Hub upload endpoint. So I would not start by assuming that your normal `HF_TOKEN` is invalid.\n\nA short useful report would be:\n\n\n This looks like a ZeroGPU release cleanup issue rather than a normal HF token issue.\n\n The visible error is:\n POST http://device-api.zero/release?allowToken=<redacted>&fail=true\n HTTP/1.1 404 Not Found\n\n Generation reaches 100%, then saving/output fails.\n\n Could you check whether the corresponding ZeroGPU task/lease was already aborted, expired, released, or missing on the backend side?\n\n I can provide:\n - Space URL\n - timestamp with timezone\n - package versions\n - redacted logs around schedule/allow/release\n - whether it reproduces on duplicate / CPU / standard GPU\n\n\n## Quick checks you can run\n\nPackage versions:\n\n\n import importlib.metadata as md\n\n for pkg in [\n \"spaces\",\n \"gradio\",\n \"huggingface_hub\",\n \"torch\",\n \"diffusers\",\n \"transformers\",\n \"accelerate\",\n \"pydantic\",\n \"httpx\",\n ]:\n try:\n print(pkg, md.version(pkg))\n except md.PackageNotFoundError:\n print(pkg, \"not installed\")\n\n\nMinimal ZeroGPU test:\n\n\n import gradio as gr\n import spaces\n import torch\n\n @spaces.GPU(duration=30)\n def test_gpu():\n return f\"cuda={torch.cuda.is_available()} device={torch.cuda.get_device_name(0)}\"\n\n demo = gr.Interface(fn=test_gpu, inputs=None, outputs=\"text\")\n demo.launch()\n\n\nMinimal file-output test:\n\n\n import gradio as gr\n import spaces\n import tempfile\n from pathlib import Path\n\n @spaces.GPU(duration=30)\n def test_file():\n p = Path(tempfile.gettempdir()) / \"zerogpu_test_output.txt\"\n p.write_text(\"hello from ZeroGPU\\n\")\n return str(p)\n\n demo = gr.Interface(fn=test_file, inputs=None, outputs=gr.File())\n demo.launch()\n\n\nIf the first test fails, the issue is probably closer to ZeroGPU itself.\nIf the first test works but the second fails, the issue may be closer to file output, Gradio queue completion, temp files, or cleanup after the GPU task.\nIf both minimal tests work, the issue is probably in your app’s generation/postprocess/save/upload path.\n\n## Things I would check before changing tokens\n\nCheck | Why\n---|---\nDoes a normal `huggingface_hub` upload still work? | Separates normal HF token auth from ZeroGPU `allowToken`\nDoes the error happen without saving files? | Separates generation from save/output\nDoes it happen outside `@spaces.GPU`? | Separates app logic from ZeroGPU lifecycle\nDoes it happen on CPU or standard GPU? | Separates storage/output code from ZeroGPU\nDoes it happen after duplicate or factory rebuild? | Separates Space state/cache from code\nAre dependencies pinned? | Rebuilds can pick up new package versions\n\nIf your app saves to the Space filesystem, also check the storage target. The default Space disk is not the same thing as persistent storage. HF’s storage docs are here:\n\n * Disk usage on Spaces\n\n\n\nIf your app needs generated files to survive restarts, use an appropriate persistent target such as `/data` with persistent storage, a Storage Bucket, a dataset repo, a model repo, or external storage. But note: a pure storage persistence problem alone would not fully explain the `device-api.zero/release?...404` line.\n\nWhy I read this as a ZeroGPU lifecycle / cleanup symptom (click for more details) Possible causes, ranked from outside (click for more details) A more detailed isolation plan (click for more details)\n\n## Bottom line\n\nI would not start by assuming your normal HF token is invalid.\n\nI would treat this as:\n\n\n A rare ZeroGPU failure/abort cleanup symptom,\n where /release could not find the internal task/lease represented by allowToken.\n\n\nThe next useful evidence is the log immediately before `/release`, especially whether `/schedule` and `/allow` succeeded, and whether there is a Python traceback before the cleanup line.",
"title": "Spaces tokens no longer work, and no generated files are being saved"
}