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

Spaces
1

Hello

After your most recent update, Spaces tokens no longer work, and none of the generated files are being saved.

The files generate successfully, but once the process reaches 100% and attempts to save them, I receive a token error.

INFO:httpx:HTTP Request: POST http://device-api.zero/release?allowToken=78848034476f0a9a13e88d5fddb3bd7df8df6e0888c7de2b16c14f6b399b0f&fail=true “HTTP/1.1 404 Not Found”
INFO | HTTP Request: POST http://device-api.zero/release?allowToken=78848034476f0a9a13e88d5fddb3bd7df8df6e0888c7de2b16c14f6b399b0f&fail=true “HTTP/1.1 404 Not Found”

This issue started after the recent update on the Hugging Face side yesterday. It only consumes my ZeroGPU credits without saving any files and gives token errors every time.

Could you please help? Thank you

2

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 full allowToken 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 around schedule, 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

Check Why
Does a normal huggingface_hub upload still work? Separates normal HF token auth from ZeroGPU allowToken
Does the error happen without saving files? Separates generation from save/output
Does it happen outside @spaces.GPU? Separates app logic from ZeroGPU lifecycle
Does it happen on CPU or standard GPU? Separates storage/output code from ZeroGPU
Does it happen after duplicate or factory rebuild? Separates Space state/cache from code
Are dependencies pinned? Rebuilds can pick up new package versions

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:

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

I am not HF staff, so I cannot see the backend state. This is only an outside reading of the log shape.

The posted line is:

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

That points toward ZeroGPU’s internal scheduling / lease / release path.

HF’s ZeroGPU docs describe ZeroGPU as shared infrastructure where GPU allocation is requested dynamically by the @spaces.GPU decorator and released when the function completes:

So I would read the components this way:

Part Likely meaning
device-api.zero Internal ZeroGPU device/scheduler API path
/release Cleanup/release of a GPU task or lease
allowToken Internal ZeroGPU task/lease token, not necessarily normal HF_TOKEN
fail=true The task is being released through a failure path
404 Not Found The release target was not found, already gone, expired, already released, or backend state did not match

Similar public ZeroGPU failure reports often show a lifecycle shape like:

schedule -> allow -> release?allowToken=...&fail=true -> ZeroGPU worker error

For example:

The difference is that many public examples show /release returning 200 OK, while your log shows 404 Not Found. That makes your case more interesting and probably rarer.

However, the current spaces Python package is also relevant. The ZeroGPU client-side code is installed in the Space, and the current PyPI package information is here:

At the time of writing, the latest spaces release shown on PyPI is 0.50.4, released on June 4, 2026. That is not a last-hour or last-day client package update. So if this were a broad new spaces client regression, I would expect more reports fairly quickly.

Also, the client-side ZeroGPU wrapper appears to handle /release returning 404 as a cleanup edge case rather than as an impossible state. That makes me more interested in what happened before /release, not only the /release line itself.

My current guess is:

1. A ZeroGPU task started.
2. It received an internal allowToken.
3. Generation reached or appeared to reach 100%.
4. Something failed during save/postprocess/output delivery/queue completion.
5. The task entered a failure or abort cleanup path.
6. The wrapper tried to release the task with fail=true.
7. The backend could not find the corresponding lease/task anymore.
8. /release returned 404.

That would make the 404 an important clue, but probably not the first failure.

Possible causes, ranked from outside

This is how I would rank the possibilities from the outside:

Likelihood Hypothesis Why
High Earlier exception during save/postprocess/output delivery, followed by ZeroGPU cleanup Fits “100% then saving fails” and fail=true
High ZeroGPU worker abort / missing lease / task already cleaned up Fits /release 404 as a cleanup edge case
Medium-high Gradio queue/browser connection/file-output boundary issue The failure appears at the final output stage
Medium Dependency drift after rebuild Common if packages are not pinned
Medium Temporary ZeroGPU backend state mismatch Possible, but only HF can confirm
Low-medium Storage path or persistence issue alone Worth checking, but does not fully explain /release 404
Low Normal HF personal access token expired The visible token is probably not that token
Low Brand-new spaces client regression Latest spaces release is not from the last day

The strongest clue is the combination:

device-api.zero
/release
allowToken
fail=true
404 Not Found

That combination points to ZeroGPU task lifecycle cleanup. It does not look like a normal Hub upload token error.

A more detailed isolation plan

Step 1: Get the nearby logs

The most useful log window is probably 20 to 50 lines before this:

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

Look for:

device-api.zero/schedule
device-api.zero/allow
ZeroGPU worker error
GPU task aborted
Python traceback
Connection closed
Gradio queue error
FileNotFoundError
PermissionError
HTTPError
RepositoryNotFoundError
401
403
404

Step 2: Separate normal Hub auth from ZeroGPU lifecycle

If your app uploads generated files to a dataset/model repo, test that separately with a tiny upload.

For example, use a tiny text file and the same token/secret your Space uses. If that fails with 401/403, then you also have a normal Hub token problem. If it succeeds, the posted allowToken error is probably unrelated to your normal HF token.

Step 3: Separate generation from saving

Temporarily test:

A. Generate but do not save.
B. Save a tiny dummy file without running the real model.
C. Return a file from a minimal ZeroGPU function.
D. Upload a tiny dummy file to the target repo/storage.

This tells you whether the failure is in:

generation
postprocess
local file writing
Gradio file return
Hub upload
ZeroGPU cleanup

Step 4: Check @spaces.GPU(duration=...)

If the save/postprocess/upload work happens inside the GPU-decorated function, make sure the duration covers the whole function, not only model inference.

Docs:

Step 5: Pin versions

If the Space recently rebuilt and your dependencies are floating, package drift is possible.

At minimum, record current versions before changing anything.

Potentially relevant packages:

spaces
gradio
huggingface_hub
torch
diffusers
transformers
accelerate
pydantic
fastapi
httpx

If you know the last working versions, pin those and rebuild.

Step 6: Compare environments

Useful comparisons:

Test What it tells you
Duplicate the Space Whether current Space state/cache is involved
Factory rebuild Whether cached dependencies/runtime state are involved
CPU hardware Whether save/output logic works without ZeroGPU
Standard GPU Whether the app works without ZeroGPU lifecycle
Minimal ZeroGPU app Whether ZeroGPU works at all for the Space/account

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.

3

I have similer issue (;