GitHub Stargazers Now 404s. Its Replacement Is a Reconciled Series, Not an Event Log.

GitHub announced on 30 June 2026 that the stargazers listing endpoint would be closed to anyone who is not an admin or collaborator; the reference dates the restriction itself to July 2026. On 4 September GitHub shipped the replacement: an aggregate star history series with no user identities in it. Both moves are defensible. Neither changelog says what the replacement can still reconstruct, which is measurable, so this post measures it.

What the GitHub stargazers endpoints return today

Three endpoints sit under the stargazers path in the REST reference at API version 2026-03-10: the identity listing at /repos/{owner}/{repo}/stargazers, an integer at /stargazers/count, and the new series at /stargazers/history.

June's changelog said callers who lose access may see empty responses or a 403 Forbidden. That is not what comes back. Against pytorch/pytorch, cli/cli and kubernetes/kubernetes this morning, my token — not a collaborator on any of them — got 404 Not Found from the listing endpoint. The same three requests with no token at all returned 401 Requires authentication. Neither status is 403.

If your integration separates lost permission from a deleted repository by status code, 404 no longer tells you which one you are looking at.

What the star history endpoint actually returns

The announcement names neither the path, the granularity, nor the limits. The reference and the endpoint itself do.

Each element carries week, total and days. The per_page parameter caps at 30 and defaults to 30 — ask for 50 and 30 come back. The page parameter caps at 100, and page 101 returns HTTP 422 with a message that pagination is limited to 100 pages. That ceiling is 3,000 weeks, so it will not bind on anything. The reference calls week a calendar week; what arrives is Unix epoch seconds for Sunday 00:00 UTC, and days is seven integers starting at that Sunday, summing to total.

Two behaviours the docs page does not settle. The endpoint answers unauthenticated: a plain curl with no token returns 200, and the response header naming the selected API version comes back as 2022-11-28, so a client does not have to opt into a newer API version to reach it. And the newest bucket is the current, partly elapsed week — on all three repositories checked this morning the seventh day is 0. A tool that diffs the head bucket against the one before it will report a collapse in stars every week it runs.

The series reconciles to the live count

This is the part to know before building on it.

I pulled the complete history for vllm-project/vllm (187 weeks), pytorch/pytorch (526) and cli/cli (362): 7,525 day buckets. None is negative. And for each repository the sum of every daily value equals, exactly, the integer from the count endpoint — 90,993, 102,764 and 46,155.

Those two facts together are not what an event log looks like. A log of star events would record a removal somewhere — as a negative bucket, or as a total sitting above the live count. Across all three repositories it does neither, so what comes back is best read as the surviving stars, attributed to the day each was added.

The consequence is sharp. A star that was later removed is not anonymised in this series; it is absent. A campaign that added ten thousand stars in a week and was then cleaned up leaves a flat line, not a spike with the names filed off.

That claim is cheap to break. Find one repository where the daily values sum to something other than /stargazers/count, or a single negative bucket, and this reading is wrong. Here is the check, which returned 46155 against a count endpoint reporting 46155:

gh api --paginate /repos/cli/cli/stargazers/history | jq -s 'add | [.[].days[]] | add'

What aggregation costs

The one published measurement of manufactured stars at scale is built on the input that just closed. The arXiv preprint 2412.13459, submitted December 2024 and revised September 2025, reports roughly six million suspected fake stars across GitHub between 2019 and 2024, and its detector works by analysing account and repository activity behaviour — near-empty accounts, coordinated patterns across repositories. Those are account signals. None of them survives aggregation into a weekly integer.

So the published method for finding bought stars cannot be run against the endpoint that replaced its input. The paper also finds that inflated stars stop helping after roughly two months, which is shorter than the quarter most dependency reviews run on.

What to do about it this quarter

• Fix the error branch. Treat 404 from the stargazers listing as lost access rather than a deleted repository, and 401 as a missing token. Do not wait for 403.
• Drop the head bucket before any week-over-week comparison.
• Budget the backfill at ceil(weeks / 30) requests: 7 for vLLM, 13 for the GitHub CLI, 18 for PyTorch. Unauthenticated you get 60 requests an hour, so three PyTorch-sized backfills exhaust it; the authenticated core limit is 5,000.
• Stop treating the star count as a maturity input. Largest single day over median single day across full history is 11.7 for vLLM, 31.6 for PyTorch and 83.7 for the GitHub CLI. Three ordinary repositories spread that ratio over more than sevenfold, so a fixed spike threshold separates release weeks from each other before it separates a campaign from anything. The signals that still resolve to individual accounts — commit recency, release cadence, time to first response on issues — are the ones worth wiring into a review.

The privacy change was the right call, and the replacement is labelled an aggregate and behaves like one. What went away is the ability to audit the number. Picking a dependency on a star count is now the same mistake as choosing between buy, build, or fine-tune by which option sounds most advanced: a decision resting on a proxy no outside reviewer can verify. The endpoint that could verify it is admin-only, and the series that replaced it reconciles away precisely the evidence you would have gone looking for.