Build1 distinct publisher3 min readUpdated
A measured run published on dev.to shows three If-None-Match requests returning 304 with empty bodies each took one off the 60/hour bucket. The discount is documented only for authorized calls.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A developer sat down to write a post about polling GitHub for free with ETags and published the opposite result: with no Authorization header, three consecutive If-None-Match requests came back 304 Not Modified with zero bytes of body, and each one still decremented the unauthenticated bucket of 60 requests per hour [2][3]. If you sized a poller on the bare sentence that 304 responses do not count against your rate limit, your budget is wrong by exactly the number of polls you make.
The run, dated July 29, 2026 from a single IP with no token, is small and legible [1]. A plain GET on /repos/python/cpython returned 200 with a 5,996-byte body and moved x-ratelimit-remaining from 32 to 31 [1]. Three conditional requests followed, all 304, all zero bytes: 31 to 30, 30 to 29, 29 to 28 [2]. Four requests, four decrements, no discount for the empty ones [1]. The ETag saved the bytes and none of the quota [3].
The interesting part is not that the documentation is wrong. According to the writeup, it is not [8]. On GitHub's "Best practices for using the REST API" page the claim appears five times, and two of those five attach the condition [4]. The strict one spells the header out: "Making a conditional request does not count against your primary rate limit if a 304 response is returned and the request was made while correctly authorized with an Authorization header" [5]. A bullet in the "Avoid polling" list carries the same condition in one word, "authenticated", and never mentions 304 at all [6]. The other three drop the clause, including "each 304 Not Modified response is fast and does not use your rate limit" and, further down under "Make requests that can be cached", "A conditional request only saves you time and rate limit if the endpoint returns 304 Not Modified" [7]. Three of five mentions omit the condition [3]. All four curl examples on the page send Authorization: Bearer YOUR-TOKEN, so the page is written for a reader who already has one [8]. Read whole, it holds; quoted a sentence at a time, it produces a poller that dies at the top of the hour.
The author is careful about what the measurement proves, and the caveat is worth repeating: a null result on the unauthenticated branch does not verify the authenticated one [9]. The numbers are equally consistent with the clause being load-bearing and the discount working with a token, and with the discount being dead for everybody and the docs being stale, and separating those needs a token he did not have [9]. He says he chose the generous reading and labels that a choice rather than a finding [10].
The operational arithmetic is unforgiving either way. Unauthenticated, a conditional poll once a minute consumes the entire 60-per-hour allowance whether or not anything changed [2]; the three 304s in this run cost 5 percent of an hour's budget for nothing [4].
Two things to watch. First, whether the authenticated branch still discounts at all: that is one token, one 304, and a logged delta on x-ratelimit-remaining, and nobody should assume it until someone posts the header trace. Second, the docs source file in github/docs, which the author read on July 29 and again on August 19, 2026 without change [11]. Until then, instrument the counter rather than the sentence.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Without an Authorization header, an If-None-Match request that returns 304 still decrements x-ratelimit-remaining; the unauthenticated bucket is 60 requests per hour, and the ETag saves bytes but not quota.
On July 29, 2026, from one IP with no token, a GET to /repos/python/cpython returned 200 with a 5,996-byte body and x-ratelimit-remaining moved from 32 to 31.
Three subsequent If-None-Match requests sent without an Authorization header each returned 304 Not Modified with zero bytes of body, and x-ratelimit-remaining fell 31 to 30, 30 to 29, and 29 to 28.
The author notes a null result on the unauthenticated branch does not verify the authenticated one: the numbers are equally consistent with the clause being load-bearing and with the discount no longer working for anybody and the docs being stale, and distinguishing them requires a token he did not have.
The author says he picked the generous reading throughout the post and calls that a choice, not a finding.
On GitHub's page "Best practices for using the REST API" the claim that 304 responses do not count against the rate limit appears five times; two of the five carry the authorization condition and three do not.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Directly instrumented, narrowly scoped, no control arm
The central unauthenticated claim rests on primary observation any reader can rerun: response codes, body sizes, and successive x-ratelimit-remaining values across four requests, with the docs wording quoted verbatim and pinned to a named source file and commit. Strength is limited by scope rather than rigour — one IP, one endpoint, one run, and no authenticated control, which the author states leaves the token-bearing branch untested.
No uptake or prevalence data in the cluster
The sources contain measurement events, not adoption facts. Nothing in the supplied material quantifies how many clients poll GitHub unauthenticated, how much quota is lost in practice, or how widely the unconditional phrasing is relied upon — the author explicitly declines to count how often the short version travels. Inferring prevalence from a single run would be a guess.
Claims sit at or just under the evidence
The framing is tighter than the material would allow: the author refuses 'GitHub's docs are wrong', credits the page for being written for an authenticated reader, names the two worlds his data cannot separate, and labels his interpretation a choice rather than a finding. The headline generalisation about ETag polling budgets is supported by the measured decrements, so the small negative reflects understatement, not overreach.
Mild attention incentive, no vendor stake disclosed or visible
A developer-platform post on a community publishing site carries a routine engagement incentive, and a counterintuitive reversal is more shareable than the tidy 'poll GitHub for free' piece originally planned. Countervailing signals are strong: the author publicly abandons his own prior belief, discloses the interpretive choice he made, and takes the vendor's side on whether the docs are wrong. No commercial relationship, sponsorship, or competing product appears in the material.
Credible single-source self-report, unreplicated
Confidence is moderate: the mechanism is simple, the observation is well specified, and the docs quotes are checkable, but the cluster has one publisher, one run, no authenticated comparison, and no GitHub confirmation. Adoption is unmeasurable from the supplied material, which further limits how much weight the story can carry.
build
AI-written code fails the same four ways, and every gate you own reports green1 distinct publisher
build
Grok 4.6 lands in Copilot two days after launch, and the model picker becomes a procurement problem1 distinct publisher
security
Akrites switches on in September with 20-odd members and a one-to-10 engineer donation band1 distinct publisher
product
The AI-wrote-it claim died in eight hours. The Actions injection pattern did not.1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 19, 2026