Git-tracked repo files (direct, or via git-unlimited-storage wrapper)

github.comPaaSstorage/git-tracked-repo-filesJSON compare report an error provider JSON

Free allowance: 100 MiB hard per file ('GitHub blocks files larger than 100 MiB'); repository size is soft — "We recommend repositories remain small, ideally less than 1 GB, and less than 5 GB is strongly recommended".
Verdict: fails: quotathe free allowance is too small to matter
Cost: free tier
Identity: emailno card, no phone
Binding limit: per-object-capper file ('GitHub blocks files larger than 100 MiB
Evidence: reported3 sources; a third party said so
Freshness: stale on 2026-11-05checked 2026-10-21 (inherited); stale on 2026-11-05

Free tier	100 MiB hard per file ('GitHub blocks files larger than 100 MiB'); repository size is soft — "We recommend repositories remain small, ideally less than 1 GB, and less than 5 GB is strongly recommended". unit GB; metered on unstated
Price	none stated
Limits	per-object-cap (binding) per file ('GitHub blocks files larger than 100 MiB source 100 MiB hard per file, 50 MiB warning, 5 GB strongly recommended per repo, ~80 write req/min and 500/hr per token.
Binding	per-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota
Identity	email not published
Egress	Unmetered via raw.githubusercontent.com (probed 200) and codeload.github.com (probed 200 on a 270,150,054-byte tarball). Free, anonymous, CDN-fronted.
Per-object cap	per file ('GitHub blocks files larger than 100 MiB (104857600 bytes)
Retention	\| Clone cost grows with history — every revision of a file is retained forever, so this is the worst surface for churn
Interface	s3, git git
Tooling	git; wrapper bharatcj/git-unlimited-storage (Python + Node, S3-shaped API, jsDelivr serving path, 0 stars but 77 tests passing) and sueszli/github-lfs-bypass (5 stars).
Composes with	100 MiB per file x unlimited repos. The wrapper's own honest-limits table caps the practical use at 'anything under a few hundred gigabytes' and calls itself the 'Wrong tool' for 'storage heading past a terabyte'.
Reliability	Clone cost grows with history — every revision of a file is retained forever, so this is the worst surface for churn. Repos above ~5 GB may draw a support email asking for remediation.
Parsed numbers	per-object-cap 100 MiB

Evidence 3

date	source	what it proved
2026-10-21	docs.github.com/en/repositories/working-with-files/managing-	'GitHub blocks files larger than 100 MiB'; 'less than 5 GB is strongly recommended'
2026-10-21	source not published	probe: GET raw.githubusercontent.com/torvalds/linux/master/README -> 200, 6034 bytes; GET codeload.github.com/torvalds/linux/tar.gz/refs/heads/master -> 200, 270150054 bytes
2026-10-21	raw.githubusercontent.com/bharatcj/git-unlimited-storage/mai	honest limits table: 100 MB single file, 1-5 GB repo

More fields 1

{
 "dead_end": {
  "failure_class": "quota",
  "why": "100 MiB hard per file ('GitHub blocks files larger than 100 MiB'); repository size is soft — \"We recommend repositories remain small, ideally less than 1 GB, and less than 5 GB is strongly recommended\".",
  "retry_when": null,
  "first_recorded": "2026-10-21"
 }
}

Unknown values 3

$.identity_cost.detail boilerplate
$.per_object_cap.notes the field may be stated in a source that was not read
$.retention.notes the field may be stated in a source that was not read