How the deletion history is built

Why deletion history matters

A catalog of what exists tells you the state of the market today. A catalog of what has disappeared tells you something about the market's turnover, its author retention, its exposure to platform enforcement, and the shape of its long tail. In a niche this specific, watching models leave is as informative as watching them arrive.

Nowhere else in public tracks this. HuggingFace itself does not maintain a public record of deleted models - the API returns a 404 for the ID, and that is that. Third-party archives snapshot specific popular models sometimes, but no one keeps a systematic monthly record of the abliterated niche specifically. This page and the underlying pipeline are, as far as we know, the only source.

How a model becomes classified as deleted

A model is marked deleted if it appeared in at least one earlier monthly HuggingFace snapshot but is absent from the latest snapshot. That is the entire operational definition.

Two consequences follow:

• A model that was renamed (moved to a new author/name) will look deleted from its old ID and appear fresh at its new one. We do not currently detect these renamings. So a small share of "deletions" are really relocations.
• A model that briefly went offline (maintenance, private-then-public toggle) between two monthly snapshots and returned before the next one is never marked deleted. The monthly cadence is coarse enough to smooth over short-term outages.

The tradeoff is deliberate. Monthly cadence is what makes the pipeline cheap to run and easy to audit - one snapshot per month, one recompute per night, no continuous API polling. A daily or hourly cadence would catch briefer outages but would introduce noise from platform hiccups. Monthly is the honest resolution the data supports.

How the timeline is reconstructed

The pipeline needs to answer three questions for each deleted model: when did it first appear, when was it last seen alive, and how popular was it at its peak. All three come from the monthly snapshots.

Every month, one full snapshot of the HuggingFace model registry is captured from the cfahlgren1/hub-stats dataset - a public, maintained dump of the whole registry with download counts. Twenty-four consecutive monthly snapshots covering October 2024 through the current month sit on our server (roughly 19 GB of Parquet). For every model that ever appeared in any of those 24 snapshots, we now have month-by-month presence and download counts.

From that data, for each model:

• First seen - the earliest month that snapshot contains the model ID
• Last seen - the most recent month that snapshot contains the model ID
• Peak downloads - the maximum downloads_all_time value observed across all snapshots where the model appeared
• Months alive - months between first seen and last seen, inclusive
• Deleted - true if last seen < latest snapshot; false otherwise

The nightly automation rebuilds this table (historical_deletions) from scratch from the current 24 snapshots. As new monthly snapshots are added, the window shifts forward and older data outside the window falls off. Nothing is manually curated.

Why peak downloads is the right measure of significance

Two models can be deleted on the same day. If one had 1.5 million lifetime downloads and the other had 3, the loss to the ecosystem is nothing alike. The full deletion history table therefore sorts by peak downloads by default rather than by deletion date - because the size of what disappeared usually matters more than exactly when.

For context, the three most significant deletions currently on record: LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V12-GGUF (1,005,078 peak downloads before disappearing), LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Wasserstein-GGUF (462,887), and LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-Final-GGUF (444,251). Each of these had a real audience before deletion. Losing them from the catalog is a genuine loss of accessibility for that audience.

The table remains sortable by other columns - deletion date, months alive, first-seen date - because different questions want different sort orders. But the default is set to what best represents the ecosystem's memory of what was there.

Lifespan distribution

The average lifespan before deletion is around 8 months. That is a headline number but a coarse one; the distribution matters more. Roughly:

• 0 models lived over a year
• 0 models lived 6 to 12 months
• 0 models lived 3 to 6 months
• 3,156 models lived under 3 months

The long-lived cases are notable. A model that stayed available for over a year and then disappeared usually indicates a policy takedown, an author account removal, or a deliberate withdrawal - not a soon-after-release regret. The short-lived cases (under three months) are more likely to be experiments the author decided against, models that were quickly superseded, or content that ran into moderation issues right after appearing.

The distribution shape says something about the niche's editorial rhythm. In a niche where most work is polished and stays available, the lifespan distribution would be dominated by long tails. In a niche where experimentation dominates, short lifespans would rule. This niche shows both - a base of long-lived work with a steady turnover of shorter experiments.

What the data does NOT reveal

Reasons for deletion. The pipeline records that a model was present at time T and absent at time T+N. Why it disappeared - author choice, platform takedown, legal action, quiet withdrawal - is not visible from a HuggingFace snapshot alone. We do not speculate. The page shows what disappeared and when, not why.

Renamings. A model that was moved to a new author or new name looks like a deletion of the old ID plus a fresh arrival at the new one. We do not currently detect this pattern. If we did, some "deletions" would be reclassified as renamings. That reclassification is future work.

Copies and forks. A model that was deleted from its original location but had been forked to another location before deletion may still be effectively available. The deletion of the original ID is real; the loss of access to the weights is not always. The deletion history tracks the original ID, not accessibility.

Everything before October 2024. Our snapshot window starts there. Any model that appeared and disappeared before that date is invisible to this pipeline. Some early abliteration work is likely missing from the deletion record for this reason.

What the summary block on Signals shows

On the market page, under the Signals tab, a compressed block summarizes the deletion history: total count of deletions, month-by-month bar chart of disappearances, and the top few by lifetime downloads. That block is a preview. The full sortable and searchable table sits at /market/deletion-history.

Both are generated from the same underlying historical_deletions table rebuilt nightly. The Signals block is what you glance at; the full page is what you dig into.

Where to read more

• /market/deletion-history - the full sortable and searchable table of every deletion on record
• How market metrics work - the master guide to all three tabs
• How the Signals tab works - the companion article covering the block where deletion appears
• The fork graph - how family relationships are tracked (relevant to the renaming question above)