Project Git LFS storage and bandwidth usage from large binary file tracking.
Git LFS bills storage and bandwidth separately from repository size. Formula: storage = lfs_objects × avg_size; monthly_bandwidth = monthly_pulls × avg_size. Every clone, fetch or checkout that touches an LFS-tracked file re-downloads it (unless cached), so bandwidth usage scales with team size and CI activity, not just repository growth.
LFS storage
storage_GB = lfs_objects × avg_size_MB / 1024
Monthly bandwidth
bandwidth_GB = monthly_pulls × avg_size_MB / 1024
Every CI job that clones the repo re-downloads all LFS objects referenced by the checked-out commit unless you cache the LFS store between runs — this is the most common cause of runaway bandwidth usage.
Cache `.git/lfs` between CI runs, use `git lfs fetch --recent` to skip old history, and consider `GIT_LFS_SKIP_SMUDGE=1` for CI jobs that don't need the actual file content.
No — like regular Git objects, LFS objects remain in history until you rewrite it (e.g. `git lfs prune` for local caches, or provider-specific history rewriting for the remote store).
Binary or large files that change often and don't diff well as text — images, videos, datasets, compiled models, design files — so history doesn't balloon with full copies of every version.