Whatever the reason for the flag, if you haven’t contacted Hugging Face Support by email yet, I’d recommend doing that first:
From what you posted, I would treat the explicit runtime state as the main signal here:
stage: PAUSED
errorMessage: "Flagged as abusive"
The 401 from restart_space() and the 503 from the web restart action are useful supporting symptoms, but they are less specific. Since the runtime itself says the Space has been flagged, this looks like something that needs review on the Hugging Face side rather than a normal Streamlit/Docker startup problem.
Hugging Face’s current Content Policy explicitly says that content can be flagged through reports, internal signals, or automatic detection, and that flagged content is then reviewed by the Hugging Face Team. It also says they prefer collaborative solutions with repository owners where possible—for example, asking for a modification or additional guardrail rather than simply disabling something permanently.
So I think the most useful request is essentially:
If this is a false positive, could you please clear the flag and re-enable the Space?
If it is not a false positive, could you tell me what content, behavior, or configuration triggered the flag and what I need to change?
That avoids having to guess the detector from outside.
For moderation-related communication, the current Content Policy lists feedback@huggingface.co as the contact address for users. website@huggingface.co is also an established Hugging Face support address used in the official documentation, and HF staff have directed users there in account/storage review cases. If you have already opened a support thread through one of those addresses, I would keep replying to the same thread rather than sending several independent copies.
I would include the useful evidence you already collected in that first message:
- your username and Space URL;
- the two model repository URLs;
- the complete runtime response showing
PAUSED / Flagged as abusive;
- both Root Request IDs from the failed restart attempts;
- a short timeline: model upload → Space creation → flag observed → restart attempts;
- the fact that repository writes still work while the runtime is blocked;
- a two- or three-sentence description of what the Space actually does;
- the August 8 course presentation deadline;
- your PRO status as ordinary account context;
- the approximately 3.5 GB upload immediately before creating the Space.
I would describe that last item as timeline information, not as the established cause.
Your rapid-upload hypothesis is possible, but I don’t think the public evidence is strong enough to say that it is probably what happened. Hugging Face normally supports repositories much larger than 3.5 GB—the current storage documentation gives PRO accounts substantially larger storage allowances—and the current huggingface_hub upload stack is explicitly designed for parallel/high-throughput large-file transfers through Xet. The upload documentation even provides a high-performance mode intended to saturate available bandwidth.
That does not prove that upload timing or some combination of account/resource events cannot feed an internal abuse signal. It just means that “3.5 GB in two minutes” by itself is not enough for us to identify the root cause.
One small clarification may also help whoever reviews it: in this project, “inversiones” means public-sector investment records, not personal investment/trading advice. Something as short as this would remove that possible ambiguity:
The application answers questions about public-sector infrastructure
investment records published by Peru's Ministry of Economy and Finance.
It does not provide personal investment, securities, trading,
or financial-planning advice.
I would not claim that the name caused the flag; this is just useful context for a human reviewer.
A compact decision tree
I would separate the next steps like this:
| Current state |
Practical next step |
| You have not emailed HF yet |
Send the evidence bundle first |
| You already emailed |
Add the runtime output, Request IDs, timeline, and presentation deadline to the same thread |
| HF says it was a false positive |
They need to clear/unpause the platform-side flag |
| HF identifies something that must change |
Make the specified change, then confirm whether the existing flag also needs manual clearing |
| HF formally maintains a moderation decision you disagree with |
The Content Policy documents legal@huggingface.co as the route to contest a moderation decision |
| The flag is removed but the Space still fails |
Only then switch back to normal Docker/Streamlit/build/runtime debugging |
I would not start with the formal legal@ appeal route unless HF has actually made or maintained a moderation decision. At this stage, a normal review request seems much more appropriate.
Why I would not spend much time debugging the 401/503 yet
There are several public Space cases where the visible symptom was a failed restart, factory rebuild, hardware change, or generic 503, while the more informative runtime response showed a moderation-side flag.
For example, one recent Space reported:
errorMessage:
"Flagged as abusive, reason trojan proxy on :7860"
even though its Build and Container logs did not show a normal application failure:
Space flagged as “abusive, reason trojan proxy” need help unblocking
HF staff’s response there was to continue through the support email channel.
Another case explicitly showed:
Detector: RepoScanner
Category: huggingface:tunnel
File: API_DOCUMENTATION.md
Pattern: Cloudflare
The repository owner removed the flagged file, but the existing flag remained and restart/resume/factory rebuild continued returning errors:
Space flagged as abusive (false positive) - cannot restart after removing flagged file
And another research Space had almost the same high-level state you have:
{
"stage": "PAUSED",
"hardware": {
"current": null,
"requested": "zero-a10g"
},
"errorMessage": "Flagged as abusive"
}
with restart, Factory rebuild, hardware changes, and new commits all failing to get it running:
“Flagged as abusive” false positive on ZeroGPU Space — cannot restart
These examples are useful mainly because they show that the same surface symptom can come from different detection paths.
They do not establish that your Space was detected by RepoScanner, a proxy heuristic, Cloudflare-related rules, or any of those particular systems.
That is why I would not start deleting or renaming random files trying to match one of those cases.
Optional: save the complete runtime response before changing anything
Since you are already using huggingface_hub, one extra low-cost thing may be worth saving for the support message.
The official SpaceRuntime object has a raw field containing the raw server response, which can contain more information than the normalized stage/hardware fields.
For example:
from pprint import pprint
from huggingface_hub import HfApi
api = HfApi()
runtime = api.get_space_runtime(
"AdrianG29/asistente-inversiones"
)
pprint(runtime.raw)
In some public cases the backend response exposed additional details such as a detector, reason, category, file, rule, or timestamp. In other cases it only exposed the generic "Flagged as abusive" message, so I would not expect any particular field to be present.
If the output contains anything more specific, save it and send it privately to support.
I would also avoid pasting tokens, cookies, authorization headers, secrets, or other private account information into the public forum.
About the upload-pattern theory
There is a separate class of Hugging Face account/storage checks where users have received an explicit error such as:
Your storage patterns tripped our internal systems!
Please contact us at website@huggingface.co
so we can verify your account and unlock more storage for your use-case.
HF staff have publicly directed affected users to the same support address:
403 Forbidden: “Your storage patterns tripped our internal systems”
So it is reasonable to say that Hugging Face has internal systems which can react to account/storage patterns.
But I would keep an important boundary here:
storage/upload request
↓
"storage patterns tripped our internal systems" / 403
is not necessarily the same mechanism as:
Space runtime
↓
PAUSED
↓
"Flagged as abusive"
There is no public evidence I could find that lets us connect those two systems and conclude that your fast upload caused this Space flag.
Likewise, some other public Spaces have been flagged immediately after the first build or first push, even with much smaller repositories. For example:
Space flagged as abusive by Cloudflare rule (false positive) — requesting review
Again, that case had a specific Cloudflare-related reason, so it is not evidence that the same thing happened here. It mostly shows why chronological coincidence is not enough to identify the detector.
My wording to support would therefore be something like:
One possibly relevant part of the timeline is that I had just subscribed
to PRO, uploaded about 3.5 GB of my own model weights, and created the
Space immediately afterward. I do not know whether this is related to
the flag, but I am including it in case it is useful for reviewing the
automated detection.
That gives HF the information without asserting the diagnosis for them.
Things I would avoid doing while the review is pending
I would avoid repeatedly trying random “fixes” whose only purpose is to make the abuse flag disappear:
- repeated Factory rebuilds;
- repeated hardware changes;
- empty commits;
- deleting arbitrary files before preserving the current evidence;
- repeatedly cloning the same Space under new names;
- renaming strings or dependencies only because another user’s scanner happened to dislike them.
The reason is not that those actions are necessarily prohibited. It is simply that a platform-side flag may persist independently of repository changes, as several public cases show, while extra changes make the timeline harder for a reviewer to reconstruct.
If HF identifies a concrete file, package, command, network behavior, or configuration that needs modification, then there is something specific to fix.
Until then, preserving the state and giving support a concise evidence bundle seems higher-value than trying to reverse-engineer an unpublished detector from the outside.
For the course presentation itself, I would treat a local run, prerecorded demo, or another legitimate deployment environment as a presentation contingency, not as a method of bypassing the HF flag. The review and the presentation deadline are separate problems, and the latter unfortunately may need a backup plan even if the Space itself is completely legitimate.
So, in short, I think you have already collected most of the useful technical evidence.
The part we cannot infer from the outside is the important one: which Hugging Face-side detector/rule produced the flag, and whether it was a false positive.
That makes support review the shortest path here. Send them the Space, runtime output, Request IDs, timeline, and a very short explanation of the project; ask for an unflag if it was automated in error, or the exact remediation required if it was not.