Quick answer
GitHub documents maximum git lfs object as Free/Pro: 2 GB; Team: 4 GB; Enterprise Cloud: 5 GB. Storage and download bandwidth are metered separately from the per-file ceiling.
Verified Aug 22, 2026Official source
Current limits
| Constraint | Current value | Scope | Verified source |
|---|---|---|---|
| maximum Git LFS objectStorage and download bandwidth are metered separately from the per-file ceiling. | Free/Pro: 2 GB; Team: 4 GB; Enterprise Cloud: 5 GB | Git LFS | GitHubAug 22, 2026 |
Why does this limit matter?
A large binary may fit Git LFS technically but consume significant owner storage and collaborator bandwidth.
This value is scoped to Git LFS; a different plan, runtime, model, endpoint, region, or account can produce a different effective constraint.
What should you check?
- Confirm repository owner plan, object size, monthly storage, and download traffic.
- Confirm the exact plan, model, runtime, endpoint, region, and account that serve the failing workload.
- Record the observed value, response headers or configuration, timestamp, and source without logging secrets.
Important caveats
- Each changed version of an LFS file counts as a new full object for storage.
- Treat the official source and live account configuration as authoritative if they differ from this verified snapshot.
HyperObserve reports the documented platform constraint. Your application, SDK, gateway, provider, region, or account can impose a lower effective limit.
Related