Spaces tokens no longer work, and no generated files are being saved

Hmm, I can’t fully isolate it, but one thing is clear: this is a pretty rare symptom:

I would first treat this as a ZeroGPU lifecycle / cleanup problem , not as a normal “my Hugging Face personal access token expired” problem.

The useful user-side next steps are probably:

1. Do not expose the fullallowToken publicly. Redact it, even if it is probably not your normal HF_TOKEN.
2. Check the few log lines immediately before/release. The important part is likely before the line you posted.
3. Print your package versions , especially spaces, gradio, huggingface_hub, torch, diffusers, and transformers.
4. Check whether/schedule and /allow returned 200 before /release returned 404.
5. Check whether there is a Python traceback before the/release line.
6. Test whether the failure is really generation, or only save/output delivery.
7. Try a minimal ZeroGPU file-output test.
8. Try CPU or a non-ZeroGPU GPU if possible , just to separate your save/output code from the ZeroGPU lifecycle.
9. Clarify where the files are being saved : temp path, local Space disk, /data, Storage Bucket, dataset repo, model repo, or external storage.
10. If you report this to HF staff, include timestamp, Space URL, versions, and redacted logs aroundschedule, allow, and release.

The line you posted is:

POST http://device-api.zero/release?allowToken=...&fail=true
HTTP/1.1 404 Not Found

The 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.

A short useful report would be:

This looks like a ZeroGPU release cleanup issue rather than a normal HF token issue.

The visible error is:
POST http://device-api.zero/release?allowToken=<redacted>&fail=true
HTTP/1.1 404 Not Found

Generation reaches 100%, then saving/output fails.

Could you check whether the corresponding ZeroGPU task/lease was already aborted, expired, released, or missing on the backend side?

I can provide:
- Space URL
- timestamp with timezone
- package versions
- redacted logs around schedule/allow/release
- whether it reproduces on duplicate / CPU / standard GPU

Quick checks you can run

Package versions:

import importlib.metadata as md

for pkg in [
    "spaces",
    "gradio",
    "huggingface_hub",
    "torch",
    "diffusers",
    "transformers",
    "accelerate",
    "pydantic",
    "httpx",
]:
    try:
        print(pkg, md.version(pkg))
    except md.PackageNotFoundError:
        print(pkg, "not installed")

Minimal ZeroGPU test:

import gradio as gr
import spaces
import torch

@spaces.GPU(duration=30)
def test_gpu():
    return f"cuda={torch.cuda.is_available()} device={torch.cuda.get_device_name(0)}"

demo = gr.Interface(fn=test_gpu, inputs=None, outputs="text")
demo.launch()

Minimal file-output test:

import gradio as gr
import spaces
import tempfile
from pathlib import Path

@spaces.GPU(duration=30)
def test_file():
    p = Path(tempfile.gettempdir()) / "zerogpu_test_output.txt"
    p.write_text("hello from ZeroGPU\n")
    return str(p)

demo = gr.Interface(fn=test_file, inputs=None, outputs=gr.File())
demo.launch()

If the first test fails, the issue is probably closer to ZeroGPU itself. If 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. If both minimal tests work, the issue is probably in your app’s generation/postprocess/save/upload path.

Things I would check before changing tokens

If 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:

• Disk usage on Spaces

If 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.

Why 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)

Bottom line

I would not start by assuming your normal HF token is invalid.

I would treat this as:

A rare ZeroGPU failure/abort cleanup symptom,
where /release could not find the internal task/lease represented by allowToken.

The 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.