Good question. The chart's starting point (#23) is the July-September 2024 average, so it sits on the old counter.

But the switch shows up in hub-stats on a precise day: on 2024-10-22 the 30-day counts were recomputed in one step. Question answering fell from 37.7M to 1.5M overnight, and robotics nearly doubled, from 42K to 77K.

Measured only after that, robotics was still #23 in October 2024 (single month; the chart uses 3-month averages), then #20 in November, #19 in December, #9 in February 2025, #4 in April and #2 in July. So the climb from #23 to #2 happens entirely on the new counter, from about 80K downloads a month to 13.7M.

One caveat: the snapshots have no all-time counter before 2025-02-27, so monthly figures from July 2024 to February 2025 are estimated from the 30-day counts (the shaded band in the chart).

Your QA reading checks out. The drop is almost all one repo: hails/mmlu_no_train, the MMLU copy lm-evaluation-harness loads, went from 28.7M to 163K on the 30-day count overnight. Robotics got both effects at once: lerobot/pusht fell from 29.9K to 4.5K, while LeRobot repos that load_dataset never touched went from 0 to counted (charlesxu0124/functional-manipulation-benchmark: 0 to 26K).

On the window: the docs only say "within a 5-minute window", not whether it is fixed or extends with each request. snapshot_download requests each file as it starts it, 8 at a time, so a long snapshot keeps hitting the Hub for its whole duration. Unless the window extends, that counts more than once; only HF can confirm. For the largest repos the count clearly isn't full copies: genrobot2025/Gen-HumanEgo is 62 TB and logged 363K downloads in 30 days.

On size: yes, but robotics isn't the outlier on slope. Regressing log downloads on log size (controlling for likes and age), above 4 GB the elasticity is 0.35 for robotics, 0.36 for text classification and 0.29 for text generation. Doubling a repo adds about a quarter more counted downloads, not twice as many.

What is specific is concentration. Since April 2025, about half of robotics' monthly downloads come from repos over 40 GB. Drop every repo of 4 GB or more and the climb is still there, from #21 (Jul–Sep 2024) to #14, #5 and #4 (Jul–Sep 2026), but it stops at #4. So the #2 carries a size tilt, while the rise itself doesn't depend on it.

(Sizes are today's mainSize from hub-stats, so a repo that grew is binned by its current size.)

Swapped. Robotics doesn't move away from text classification. If anything it sits slightly lower.

I pulled file counts from the API for all 12,395 datasets of 4 GB or more in these categories, plus a sample of 1,339 below that. Same model: log dl30, controls for likes and age.

• 4 GB and up, log files in place of log size: robotics 0.31 (±0.02), text classification 0.35 (±0.04), text generation 0.33, QA 0.29. In a pooled fit of robotics and text classification, the robotics interaction is −0.04 ± 0.04.
• Below 4 GB: robotics 0.28, text classification 0.36, text generation 0.38. The intervals are wide there.
• With both in the model, files carry more of it: robotics 0.26 for files vs 0.17 for bytes, text generation 0.32 vs 0.05.

Per file, the count falls steeply as file count grows. For robotics repos of 4 GB and up, median dl30 per file is 2.25 with up to 100 files, 0.21 at 1–5K files and 0.04 above 20K. So it isn't counting per file either. Gen-HumanEgo's 8.1 per file is high but not unusual: it ranks 273rd of about 5,100.

One API detail: siblings stop at 100,000 files, and 195 repos hit that cap (75 in robotics). Dropping them moves the slopes by at most 0.015.

Where I'd still hedge: equal slopes rule out per-window recounting only if big text-classification repos are fetched differently from robotics ones, and we can't see how either is fetched. These are also cross-sections, so the ~0.3 mixes the counting rule with who pulls big repos.

Good point on the clock: bytes are where it would hide, and files soaking most of it up points away from it.

Running it now. None of my datasets is quiet enough, so I made five empty ones (tardellirs/hub-download-count-test-a to -e) with 4 KB files. All pulls come from one IP, without a token, starting 15:34 UTC today:

• A: 8 files in under a minute, the control.
• B: 8 files, one every 2.5 minutes, 17.5 minutes in all.
• C: 2 files, 12 minutes apart.
• D: a single HEAD, no GET.
• E: never pulled, a baseline for crawlers.

Fixed 5-minute windows would give B about 4 and C 2. A window that extends while requests keep coming would give B 1 and C 2. I'll post the counts here once they update.

Agreed on E: it's the offset, not noise. The viewer did look at all five and found "No (supported) data files", since they're .bin, so I expect 0 there. E will show it.

One correction on A. hf_xet was installed, so for each file hf_hub_download sent a HEAD to /resolve/, then a call for a Xet read token, and fetched the bytes from the Xet CAS. No GET ever hit /resolve/. So A reads 1 if merged per repo and 8 if per file, with no 16. D is the HEAD alone, without the token call.

Timestamps, UTC: A 15:34:30 to 15:35:17. B 15:34:30 to 15:52:12, 2.5 minutes apart. C 15:34:31 and 15:46:32. D 15:34:28.

On the next run: yes, but bracketed instead of one gap. Counts are per repo, so I can run several pairs at once: two pulls 4, 6, 8 and 10 minutes apart, one repo each. C already caps it at 12. If C reads 1 too, it isn't a 5-minute window at all, and the gaps move to 30 minutes, 2 hours and a day.

Thanks for keeping your IPs off them. And thank you for all these questions: I published the Model Pulse write-up today and thanked you in it, since your questions fixed three data issues and led to the size analysis. Article: https://huggingface.co/blog/tardellirs/model-pulse

Thank you, and the credit is earned.

Counters still read 0 on all five, 17 hours after the pulls (last check 08:51 UTC). The poll keeps running every 15 minutes until Wednesday.

Your read of the Xet path matches the code. In huggingface_hub 2.2 with hf_xet, each hf_hub_download sends a HEAD to /resolve/, follows the xet-auth link to /api/datasets/{repo}/xet-read-token/main, and fetches the bytes from CAS. No GET reaches /resolve/.

F is up, and I didn't wait for D. hub-download-count-test-f got one xet-read-token call at 09:04:00 UTC today, from the same IP as A to D, with no HEAD and no CAS fetch. If D reads 0, F tells us whether the token call is the counted one. If D reads 1, F still tells us whether the token call counts on its own.

One correction on E: it isn't clean. At 16:33 UTC yesterday I sent a single HEAD to E's part-0.bin from a different IP, to check that the file sits on Xet. So E is a second D from another IP, not a baseline. The viewer never read any of the five: the datasets server reports no supported data files, so the offset you expected from it isn't there.

And you're right that A, B and C give the per-repo check for free: they started within a second of each other.

Today's batch landed at our 10:37Z tick, again cut at about 08:00Z.

A to E, which nobody pulled again: 28, 31, 28, 35, 31. That's +11, +11, +10, +14, +11 in a day. So the floor isn't a first-day burst. It keeps coming at about 11 a day per repo, and the 1,830 public datasets created on 10-12 moved the same way (median 31 to 46).

F reads 0. Of the 80 public datasets created in its hour (09Z on 10-13), it's the only one: the other 79 have counts, median 34. So two things at once: the token call alone doesn't count, and whatever feeds the floor never touched F.

The second part I can't explain yet. F has the same owner, layout and card as A to E. The one difference I can see: each of A to E took at least one request to /resolve/ (the GETs, or the HEADs on D and E), and F took none.

That makes F the first quiet repo we have, and suggests the next run: leave F alone as the control, and make two fresh repos, G with a single HEAD and H with a single hf_hub_download. If F stays at 0, G and H read clean against it. And if the floor only starts after a /resolve/ hit, G and H will keep climbing past 1 in the days after.

A correction first, and it changes the picture. I read F too early. The batch doesn't land all at once: A to E moved between 10:22Z and 10:37Z, F only between 11:25Z and 11:34Z, and F now reads 19. So two lines in my last reply are wrong: that the token call alone doesn't count, and that the floor never touched F. Sorry for that.

F took no /resolve/ request at all, only one xet-read-token call, and it reads 19, between A (17 after eight pulls) and D (21 after one HEAD) on their first batch. That answers the F2 question before F2 exists: a repo climbs with no request from us. The floor isn't switched on by a /resolve/ hit, and it doesn't wait for age either. F got its 19 inside its first day, like 99% of the datasets created that day.

So on a public repo, one counted request is +1 under about 20 on day one and about 11 a day after. G and H can't show the count or the switch. I'll still read them tomorrow, but I don't expect them to say more than F did.

What could still work is a repo nothing else can read: a private dataset. Private repos do keep a counter: mine show 927 all-time downloads across 56 of them, small numbers that fit my own use. With no crawler able to reach one, every count on it would be ours. The open question is whether an authenticated pull counts the same as an anonymous one, and the private run would answer that too.

Would a private run answer what you were after, or does the token change too much?

No need to touch the VPS. The Mac's home line already holds two addresses in one /64: the stable one and the temporary privacy one. Both work as a source, so I ran it just now on a fresh private repo, t1: one HEAD from each, same token, at 16:41:00 and 16:41:05 UTC, inside one 5-min bucket. It reads tomorrow with s1 and s2.

If t1 reads 2, one host counts once per address it holds. If it reads 1, HF merges on a prefix, and the next question is how wide. The VPS has a /48, so two addresses in different /64s under it would tell /64 from something wider.

q1's VPS pull went out over IPv6: the VPS resolves huggingface.co to its AAAA first, and the tunnel left from its v6 address. So q1 was already v6 to v6, across two networks. t1 is the first pair inside one /64.

Fair point on the token. I've just run u1 on a fresh private repo: two HEADs 5 s apart from one IPv6 address, each with a different read token on my account. It reads tomorrow with s1, s2 and t1. I have no second account, so token vs user stays open unless that one splits.

Today's batch moved all four at once.

s1 (40 s apart, across 10:25:00) read 2, and s2 (4 min 30 s apart, inside 10:30–10:35) read 1. So it's 5-minute clock buckets, not a window anchored on the first pull.

t1 (two addresses in the same /64, 5 s apart) read 2, so the key takes the full address, not the prefix. u1 (one address, two tokens of the same account, 5 s apart) read 1, so a different token doesn't split the count. What's left is whether the account is in the key at all, or only the address.

On a fresh public repo: it won't stay quiet. F took no request from us and read 19 on its first day, G and H 17 each, so a +1 would disappear under that. Instead I made two private repos public for about 10 seconds this morning. v1 got one anonymous HEAD and one token HEAD 5 s later, from the same address and inside one bucket. v0 got the same flip and no requests, as a control for anything that reaches it in those seconds. If v0 reads 0, then v1 at 1 means the key is the address alone, and v1 at 2 means it also sees who is asking. Those read tomorrow.

Yes, both are logged: the anonymous HEAD and the token HEAD each got a 302, the redirect to storage, not a 200. That's the same code the pulls that counted got: both s1 HEADs were 302s and s1 read 2. A denial looks different. An anonymous HEAD on a private repo (I just tried p0) gets a 401. So the anonymous pull saw the repo as public.

On a cached denial: /resolve/ doesn't look cached at the edge. Two HEADs in a row on a public LFS file both came back with cache-control: no-store and "Miss from cloudfront". So each request reaches the origin.

Side effect: p0 now has exactly one anonymous 401, from this afternoon (UTC). Tomorrow it also tells us whether a denied request counts.

On 288: yes, but per repo per address. A CI job pulling every 30 s across three repos reads up to 864.

Not with one account, as far as I can see. The owner and org members skip the gate, so my token never sees its 403.

Two things I can do alone:

1. A fresh public repo, gated with manual approval and nobody approved. The ~20/day that public repos pick up from outside would now land on the gate. If refusals count, it reads about what F did on its first day. If they don't, it stays near 0. That tests the anonymous refusal at the gate itself, at volume, not just p0's single 401 on a private repo. It's up: tardellirs/hub-download-count-gated-a, public and gated since 17:36 UTC today, no requests from us. Tomorrow's read covers about 14 hours, the 20th a full day.
2. A fine-grained token scoped to one repo, used on another private repo: logged in and refused. That's the token-scope check, though, not the gate, so it doesn't fill the 403 cell.

For the real gate 403, the cleanest is your account. I gate a fresh repo and don't approve you. You send one HEAD with your token at a time we agree, and nothing else touches it. Would you be up for that?

Today's batch is in.

v0: 0. Public for ten seconds, no requests.
v1: 1. An anonymous HEAD and a token HEAD from one address, 5 s apart. The key is the address and the bucket. Who you are doesn't enter it, logged in or not.
p0: 0. One anonymous 401 on a private repo didn't count.
gated-a: 13 in its first ~14 hours, all from refused requests, since nobody is approved. Yours is one of them.

So the gate doesn't stop the counter. You were right that a flat 0 wouldn't have meant much, but it rose: knocks at a gate count, while the same 401 on a private repo doesn't. My guess is that to a stranger a private repo looks the same as a missing one, so there's nothing to count against.

It also means one HEAD on gated-b would sink under that ~1 an hour of crawl. Two changes, if you're still in:

• gated-b went back to private at 17:42 UTC today and will be public only from 14:58 to 16:02 UTC tomorrow, Oct 20.
• Send 12 HEADs to data/part-0.bin instead of one, one per 5-minute bucket, around :01, :06 … :56 between 15:00 and 16:00 UTC tomorrow. Requests in the same bucket merge, so twelve buckets give up to +12 against a floor of maybe 1 or 2.

Cookie is fine, since v1 says identity doesn't enter the key. What fills the cell is the code: if it's 403, it's the cell. If it's anything else, tell me and we'll name it.

Yes, tardellirs/hub-download-count-gated-b. It opens at 14:58:00 UTC.

One change, if you want the API call to be a finding: move it out of the first HEAD's bucket. 15:00:15 and 15:01:30 both fall in 15:00–15:05, so they'd merge and a counted GET couldn't show. At 14:59:00 it gets its own bucket. +12 means metadata is free, +13 means it counted. Our own xet-read-token call read 0 on its own, so I expect +12.

On your question: not quite, there are still untested knocks. A logged-in 404 on a private repo, a 404 for a file that doesn't exist in a public repo, and anything outside /resolve/. Your receipt says the first should read like p0. The second is the open one: the repo exists but the file doesn't. If the counter keys on the repo, a 404 there could count like a knock at the gate.

Got it: the GET at 14:59:00 alone in the 14:55 bucket, HEADs 15:01:30 to 15:56:30. Agreed on whoami-v2: it names no repo, so it can't land on gated-b. The script here opens gated-b at 14:58Z and closes it at 16:02Z.

On the 404: a public repo can't show it. Every public repo here gets its own floor (gated-a: 13 in 14 h with nobody approved), so a +1 drowns. So it's running on a fresh private repo instead, with our token: the repo resolves for us, the file doesn't. Six HEADs to data/missing.bin, 09:01:30 to 09:26:30Z today, one per bucket. The first came back 404, X-Error-Code: EntryNotFound. Read tomorrow with gated-b: 0 or 6, nothing between.

On your question: partly yes already. A HEAD moves no bytes and counts. gated-a climbed on refusals: a request without a session gets 401 there, as your anonymous HEAD did. p0's anonymous 401 didn't count, but on a private repo that 401 is the Hub hiding that the repo exists. So far the line isn't the status code, it's whether the request reached a repo it could see. If the 404 counts too, then yes: a per-address, per-5-minute tally of /resolve/ hits on a repo, whatever came back. If it doesn't, the file has to exist for a hit to count, refusals included.

Thanks, a clean run: 0.39 s worst skew, every HEAD in its own bucket.

My bet is +12 and 6. Refusals already count (gated-a's 401s did), so whatever does the counting doesn't wait for a file to be served. p0's 401 is the one that didn't, and on a private repo that 401 stands in for "no such repo": nothing for the count to attach to. missing.bin is the other way round: the repo resolves, only the file is absent. If the tally hangs off the repo id, it should see all six.

One caveat on +13: gated-a added 4 on its second day, so a crawler inside the 64-minute window is unlikely but not impossible. +13 would point at the GET, not prove it. The baseline is in: gated-b read 7 after this morning's batch (its 8 hours public on the 19th), so tomorrow's number minus 7 is the cell.

Fair, your odds are better than mine. And the clean test turns out to be in our logs already.

Every test repo here got a metadata GET from our side: the setup script reads dataset_info right after creating it. q0, the control from the 16th, got exactly that and nothing else: private, our token, read 0. v0 got two plain GET /api/datasets/… calls on the 18th (one in the ~10 s it was public), no HEAD, read 0. Floor 0 both times: the GET doesn't count. That's with a token, not a cookie; if you think the cookie path could differ, that one's worth a run.

Which means I owe you two of ours on gated-b: the window script read dataset_info right after opening it (14:58:02) and right after closing it (16:02:02), from our address. Same call, same 0.

So tomorrow, gated-b minus 7: +12 means your 403s counted and nobody else came, anything above that is visitors, 0 means a logged-in 403 is skipped. w1 still decides the 404.

0 and 6. gated-b stayed at 7 (the 10-21 batch moved gated-a and w1 at 10:44–10:49Z; gated-b unchanged through 13:04Z), w1 read exactly 6.

So the 404 counts: a hit on a repo you can see, file or no file, is a download. And on gated-b nothing counted: not your 12 HEADs, not the cookie GET, and no visitor either. Your odd cell.

I don't trust it yet, though, for the same reason it's odd. A missing file counts, an anonymous 401 at a gate counts (gated-a, +4 again today), and a logged-in 403 doesn't? That's possible, but there's a plainer reading: none of your requests has ever been shown to count. Everything we've proven counted came from our addresses, on a token. Yours differ in three ways at once: cookie, address, client.

Two controls would split it:

1. Ours: a browser-cookie HEAD from us on a fresh private repo. If it reads 1, cookie auth isn't the issue.
2. Yours: a gated repo where we approve you, one HEAD in its own bucket. 302 instead of 403, everything else the same. 1 → your traffic counts and the 403 was skipped. 0 → it's you, not the gate.

x1, the cookie GET you asked for, went out this morning (08:43:27Z, 200, bare URL, nothing else) and reads tomorrow.

Both. Most of ours went out through curl: w1, the q/r/s/t/u/v pairs. The p-series single pull was hf_hub_download, huggingface_hub's own agent. Both counted. y1, today's control 1, came from a browser tab, so Chrome's. A counter that only tallies clients it recognises would have to know curl and not node. Possible, if the rule is "anything but a bare runtime". Worth the split.

gated-c is up: tardellirs/hub-download-count-gated-c, gated manual, private, and you're approved from our end (grant_access). It goes public tomorrow, 2026-10-22, 14:58–16:02Z, like gated-b. Your 12 at 15:01:30 … 15:56:30 to data/part-0.bin, 8 on node's default user-agent and 4 on huggingface_hub's, alternating. Read on the 23rd. Post the schedule and I'll set the window.

One addition to your grid: x1 and y1 read tomorrow morning, before your run. If y1 reads 1, the cookie is out before we start, and a 0 on gated-c points at the address.

Set on our side too: the window script is up, opens gated-c at 14:58:00Z and closes it at 16:02:00Z. Your approval is in place.

Yes to the extra cut if it reads 4: node's fetch with curl's agent string, same setup, its own window. If that counts, the counter reads the string; if not, it keys on something below it.

One header is already covered: y1 went out as a fetch from a page, so it carried sec-fetch-mode: cors like yours. If y1 reads 1, that header isn't what's skipped.

x1 and y1 read after this morning's batch; I'll post them here before 14:58.

gated-c read 8. Not one of the three cells.

8 is exactly your node count. The window was 64 minutes on a gated repo that gets a few a day from outside (gated-a: +1 today), so I read it as: the 8 node HEADs counted, the 4 on the hub string didn't.

That settles two things and opens one. Your address and node's client both count, so gated-b's 0 was the 403: a logged-in, unapproved refusal is skipped. And the curl-string cut isn't needed: node itself counts.

What it opens is the hub string. Our one hf_hub_download pull (p-series) counted 1, and hf_hub_download sends a HEAD before its GET. A counter that skips HEADs from huggingface_hub and counts its GET would count each real download once. That fits everything so far.

We can test it from our side with zero floor: two fresh private repos, your exact string, one gets HEADs, the other GETs, one per bucket, today. HEADs 0 and GETs 4 would be the rule. Read tomorrow.

Yes, private. All of ours were: p0–p7, q, r, s, t, u, v, w1, y1, private repos on our account, pulled by the owner. And they count: w1 read 6 for six curl HEADs (404s, even) sent on the 20th, y1 read 1 for one browser HEAD on the 21st. So the venue already has its floor, measured more than once: private, owner, token or cookie, HEAD. If z2 reads 0 as well, it's the hub string, not the venue.

The p-series pull was hf_hub_download with its own agent string, not yours byte for byte, and it counted 1. That's the one GET on the hub string we have so far, which is why z2 is the useful half.

All 8 went out on schedule, 302 each: z1 HEAD and z2 GET in the same buckets, 14:11:30 to 14:26:30Z, your string exactly. Read tomorrow.

Fair point, and the owner never passes through the gate. The stranger's pull is the one I care about, since that's what people read the count as. The owner run was the cheap control.

k1 4, k2 4. A gated repo with the owner sending loses nothing, on either string. That leaves your two: approved non-owner plus hub string, or something in the run.

Your cell, then. gated-d, set up like gated-c: gated with manual approval, you approved, private except 14:58–15:22Z on Monday 10-26. 4 HEADs to data/part-0.bin on the hub string, at 15:01:30, 15:06:30, 15:11:30 and 15:16:30, on the session cookie like last time. Nothing else touches the repo. 0 pins gated-c's missing 4 on approved non-owner plus hub string; 4 puts them elsewhere.

No harm, and thanks for saying so before the read. gated-d read 0 this morning, which fits nobody sending, and it means nothing carried over: 24 minutes public, no floor count, no approved traffic. So I'd reuse it rather than make gated-e.

Same cell, Wednesday 10-28: gated-d public 14:58–15:22Z, you still approved. 4 HEADs to data/part-0.bin on the hub string at 15:01:30, 15:06:30, 15:11:30 and 15:16:30, on the session cookie. Booking first, log after, as you said.

Right id. Thursday 10-29 after the daily batch, usually in by 11:35Z. I'll post the number here.

gated-d read 4. Approved non-owner plus hub string counts in full, so that's not where gated-c lost 4. Your caveat about the 302 is why it needed a read, and the read says all 4 were filed.

On the next cell, I'd replay gated-c before splitting it. Fresh gated-e, same setup, same 12 HEADs on the same clock: node at :01, :06, :16, :21, :31, :36, :46 and :51, hub string at :11, :26, :41 and :56, from 15:01:30 to 15:56:30Z. 12 makes gated-c a one-off and we stop there. 8 makes the loss real, and then volume and spread is the right split, along with the one thing only gated-c had: two clients from one address in one window.

Friday 10-30, 14:58–16:02Z, if that suits you.

Both right: tardellirs/hub-download-count-gated-e, and the grant is in. You're the only accepted account.

Good catch on the 7.5-minute buckets: 3 on gated-d's clock, and it read 4. That one's gone for your traffic too.

Yes to all-node 12 on the same clock, if gated-e reads 8. 12 there pins it on the mix; 8 leaves volume or span. A 12 on gated-e ends it before that.

Thanks for the codes, and for the whole run.

gated-e is private and goes away with the other test repos, so a note there would reach no one. People read these numbers on Model Pulse, so the three bullets are now in the Methodology section of its data card, next to the Hub's own counting rules, with this thread linked and you credited: https://huggingface.co/datasets/modelpulse/model-pulse-data#how-the-hub-counts-a-download

Glad it reads right, but I owe it one correction, and it touches your question. Every cell was a dataset repo. The Hub counts models differently: only requests to query files count (config.json by default, every .gguf, some library-specific files), and the docs say every request to them counts, with no 5-minute merge. I've scoped the section to datasets and said so.

For datasets your reading holds: dl30 is addresses that touched /resolve/, in 5-minute buckets, whether they got bytes or not. Model Pulse can't show the no-files case today, since it keeps counts, not file lists. For models, a probe for a missing weight file wouldn't count at all. A probe for a missing config.json might, but we never tested a model repo.

Yes, and we can run it from here, no gate involved.

Two private model repos, m1 and m2, each holding only a config.json and no library tag, so config.json is the query file. One fresh cache. Both get one first download in the same early bucket; that's the control, and if it reads 0, private models don't count and I redo it public. Then, inside one later 5-minute bucket, 10 hf_hub_download calls for config.json each: on main for m1, pinned to the commit hash for m2. Debug logging records every request that goes out.

m1 minus m2 is the answer. 10 means every cached load on main counts, with no merge. 1 means a 5-minute merge like datasets. 0 means the HEAD isn't counted. Read tomorrow.

Our log agrees on both points. I ran huggingface_hub 2.4.0 with a hook on every response. Each first download sent a HEAD and then a GET, both 200, at 08:25:30Z. On the 10 cached loads, m1 sent 10 HEADs between 08:35:30 and 08:36:10Z, one bucket, all 200. m2 sent nothing, so the subtraction holds.

If m2 reads 2 and m1 minus m2 reads 0, I'd say requests merge by method as well as by address and file, over more than 10 minutes. The HEAD and GET at 08:25 differ in method, so both count. The 10 HEADs at 08:35 repeat the 08:25 HEAD, so they'd fold into it even across buckets. That would make the merge window on models longer than the 5 minutes we saw on datasets, and keyed differently. One gap: I logged responses, not request headers, so I can't rule out the cached HEADs looking different to the counter.

One more possible reading: m1 and m2 are private. If both read 0, it's probably that, and I'd rerun the test with public repos.

Checked against the 2.4.0 install I ran, and you're right. get_hf_file_metadata is the only place either HEAD is built, with the same headers. No If-None-Match anywhere in the package, so the counter has nothing to tell them apart. The gap is closed.

I'm betting 1. On datasets the counter merged per address per 5-minute bucket, and I don't see a reason for the same pipeline to key models differently, whatever the docs say. If the docs are literal, it's 10. 0 would be the surprise.

Your Xet note made me look one step further. When the tree listing is cached, that path makes no /resolve request at all. It gets a token from /api/.../xet-read-token and fetches from Xet storage. If /api calls don't count on models either, a pinned .gguf fetched that way wouldn't be counted. That's from the source only, not tested.

Checked against the 2.4.0 install, and it holds: the hook sets the header on everything under the flag, write_tree_cache has the one writer, and the token GET goes through http_backoff.

One correction to m4. A lone hf_hub_download of a Xet file also fetches the token, so it sends the HEAD on /resolve plus the xet-read-token GET, both flagged.

I ran it at 16:37Z: two private repos with the same 12 MB Xet-stored model.gguf, a fresh process and empty cache for each, every request logged. All of them carried the header.

m3, snapshot_download: repo_info, the tree listing, HEAD and GET on /resolve for .gitattributes and README.md, and the token GET. 7 requests, none on /resolve for model.gguf, as you said.
m4, hf_hub_download: HEAD on /resolve/main/model.gguf (302), then the token GET. 2 requests.

My bet is m3 above 0. I can't see why the client would send that header unless something reads it. But my last bet was wrong, so take it lightly. Read tomorrow.

Line 575 checks out, and so does the split. A second snapshot_download in the same process sends only repo_info: the tree cache hits on the commit at line 282, and each file returns at the pointer check. If it lands on (1, 1), I'll run that.

On the card: it now says only requests to a library's query files count. (0, 1) leaves that true and adds one line: a GGUF fetched with snapshot_download counts zero, because its bytes never pass through /resolve. Every other row breaks that sentence, since what counted wasn't a request to a query file. The card would have to say the counter reads the client's X-HF-Download-Counter header, and which calls it counts. Under (1, 2), a snapshot would also count once per process however many GGUFs it pulls, since the token is cached per revision.

For Model Pulse that matters more than the card. Under (0, 1), a GGUF repo's counter misses everyone who uses snapshot_download. Under (1, 2), it counts them once per run, not per file. Either way it isn't a file count.