{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihmqsdkarqkuk5tqn6v6sbsyxcqisjuj6ripuqxsqum4dtlu4ebye",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mokfgyvkboy2"
  },
  "path": "/t/downloadsalltime-decreasing-day-over-day-for-multiple-public-models-expected-behavior/176918#post_2",
  "publishedAt": "2026-06-18T07:59:26.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "@Wauplin",
    "Models Download Stats",
    "Query files for different libraries",
    "GGUF handling",
    "Diffusers handling",
    "huggingface_hub HfApi docs",
    "Monthly / Total downloads not updated",
    "Request for time-series model download stats",
    "downloadsAllTime requires expand",
    "Daily stats confusion: downloads vs all-time",
    "Downloads data not updating",
    "Dataset download stats still not updated",
    "Models stuck at zero downloads",
    "Dataset count not updating",
    "dataset card / Data Studio issue",
    "another dataset count issue",
    "mflux models showing 0 downloads",
    "Private dataset unexpected downloads",
    "This downloadsAllTime decrease report",
    "Publisher Analytics",
    "(click for more details)"
  ],
  "textContent": "Hmm… reports of `downloadsAllTime` actually _decreasing_ seem quite rare. I think this may be the first clear example I’ve personally seen.\n\nI tried to collect as many related past cases as I could, and the rough picture is: there is too much here that external users just cannot know unless Hugging Face staff clarifies it. Without that, I don’t think we can reliably say what caused this, or what the correct downstream handling should be. In particular, I don’t know whether `downloadsAllTime` is meant to have a monotonicity guarantee or not @Wauplin :\n\n* * *\n\n## My current read\n\nThis does **not** look like the usual “30-day rolling window went down” case, because the report explicitly uses `downloadsAllTime`, not just `downloads`.\n\nFrom the public API/docs wording, `downloads_all_time` naturally reads like a cumulative value. But I could not find an explicit official statement saying that `downloadsAllTime` is guaranteed to be monotonic, append-only, or never revised downward.\n\nSo I would separate the question into two layers:\n\nQuestion | External-user answer\n---|---\nDid the visible counter decrease? | The examples here seem to show that, yes.\nIs that expected behavior? | I cannot know without HF clarification.\nIs it a bug? | Also cannot know from public counters alone.\nCould it be a correction / backfill / filtering / rollup issue? | Possible, but not provable externally.\nHow should downstream users handle it? | Treat negative deltas as counter revisions, not negative downloads.\n\nThe most useful clarification would be:\n\n> Is `downloadsAllTime` intended to be a monotonic cumulative counter, or a corrected aggregate that can be revised downward?\n\n* * *\n\n## Why this is ambiguous from the outside\n\nThe public docs describe model download counts as server-side counts based on selected query files. `GET` and `HEAD` requests count, default query files such as `config.json` are used, and libraries can define their own `countDownloads` filters. GGUF and Diffusers also have special handling.\n\nRelevant docs:\n\n  * Models Download Stats\n  * Query files for different libraries\n  * GGUF handling\n  * Diffusers handling\n  * huggingface_hub HfApi docs\n\n\n\nThat means the public counter is not simply “number of times a human clicked a download button”. It is a request-derived metric that passes through several counting and aggregation rules.\n\nThat does **not** mean the decrease is expected. It only means external users cannot infer the cause from the final public number alone.\n\nPossible explanations include, without claiming any of them is the actual cause:\n\n  * historical correction / backfill\n  * bot or crawler filtering\n  * internal-traffic filtering\n  * query-file rule changes\n  * library-specific `countDownloads` changes\n  * cache / rollup behavior\n  * stats-pipeline bug\n  * some combination of the above\n\n\n\nOnly HF can distinguish these reliably.\n\n* * *\n\n## Related cases I found\n\nI am **not** claiming these share a root cause. They may be unrelated. I’m listing them only because they affect how users interpret Hub download statistics.\n\nDate | Case | Why relevant\n---|---|---\n2024-06 | Monthly / Total downloads not updated | Prior visible issue around monthly/total counters.\n2024-07 | Request for time-series model download stats | Public API users generally do not have stable historical time-series access for arbitrary repos.\n2024-09 | downloadsAllTime requires expand | Helps separate `downloads` from `downloadsAllTime`.\n2025-03 | Daily stats confusion: downloads vs all-time | Useful counterexample: this was likely 30-day `downloads`, not all-time. The current report is different.\n2025-06 | Downloads data not updating | HF staff said there had been a bug affecting “downloads last month” and “downloads all time” updates. Not proof of the same issue, but highly relevant context.\n2025-07 | Dataset download stats still not updated | Adjacent dataset-side update issue. Dataset stats have different rules, so this is context only.\n2025-11 | Models stuck at zero downloads | Example of counters depending on query-file / metadata / library-rule behavior.\n2026-03 | Dataset count not updating, dataset card / Data Studio issue, another dataset count issue | Small adjacent reports around dataset stats/card behavior. Context only.\n2026-04 | mflux models showing 0 downloads | Concrete example that library metadata / `countDownloads` rules can affect download counting.\n2026-06 | Private dataset unexpected downloads | Not the same issue, but useful reminder that public-facing download counters are not always intuitive human-download counters.\n2026-06 | This downloadsAllTime decrease report | Core case. This looks rarer than ordinary 30-day download movement.\n\nThe main pattern I see is not “these are one incident”. The safer pattern is:\n\n> Hub download statistics are public aggregates over a fairly complex counting system, and downstream users need to know whether `downloadsAllTime` has a monotonicity guarantee.\n\n* * *\n\n## Downstream handling\n\nIf I were storing daily snapshots, I would avoid treating all-time deltas as guaranteed daily download estimates.\n\nI would use something like:\n\n\n    delta = current_downloads_all_time - previous_downloads_all_time\n\n    if delta >= 0:\n        daily_downloads_estimate = delta\n        counter_revision = 0\n    else:\n        daily_downloads_estimate = None\n        counter_revision = delta\n\n\nInterpretation:\n\nObservation | Safer interpretation\n---|---\nall-time value increased | normal positive delta\nall-time value stayed flat | no observed increase, delayed update, or no new counted downloads\nall-time value decreased | counter revision / metric correction / aggregate change\n\nI would store the raw values and the raw negative delta. I would not silently clamp to zero unless the dataset or dashboard clearly documents that policy.\n\n* * *\n\n## Enterprise / organization-owned repos\n\nFor organization-owned repos, there may be better options than public API snapshots.\n\nHF documents Publisher Analytics, including All Time / Last Month views, per-repo graphs, and CSV exports with daily download records. The same docs mention Enterprise Plus request-level access logs for models and datasets published by the organization.\n\nBut that does not solve the general third-party public-model case. For arbitrary public repos, external users generally do not have equivalent historical or request-level visibility.\n\n* * *\n\n## What I would ask HF to clarify\n\nThe most useful questions seem to be:\n\n  1. Is `downloadsAllTime` intended to be monotonic?\n\n  2. If not, should downstream users treat decreases as historical counter revisions?\n\n  3. Can `downloadsAllTime` be revised downward after backfills, bot filtering, internal-traffic filtering, deduplication, or counting-rule changes?\n\n  4. Was there any recent backfill, filtering change, counting-rule change, cache/rollup correction, or stats-pipeline issue around early/mid June 2026?\n\n  5. For arbitrary public models, is there a recommended way to compute daily download trends more safely than differencing `downloadsAllTime` snapshots?\n\n\n\n\nUntil then, my conservative interpretation would be:\n\n  * this is not ordinary 30-day rolling-window behavior;\n  * the public docs make `downloads_all_time` sound cumulative;\n  * I could not find an explicit monotonicity guarantee;\n  * I cannot infer the cause from public counters alone;\n  * negative `downloadsAllTime` deltas should be handled as revisions/corrections, not negative daily downloads.\n\nAdditional context / extra links (click for more details)",
  "title": "downloadsAllTime decreasing day-over-day for multiple public models — expected behavior?"
}