I have pushed files of size 876MB to git lfs, which showed me total 0.9 of free storage and bandwidth respectively, but, then I made few changes like deleted the old repo and uninstalled git lfs, since I reduced image size from 900MB to 800MB and then pushed back to my newly created git repo. When I saw the billing of lfs it showed 0/1GB (which was to be updated to 0.8) of storage but 1.7/1GB bandwidth and after Github disabled my 'git lfs' account. I actually want to remove the bandwidth storage i.e reset it to previous state. Is there any solution? Any suggestion highly appreciated
-
1Wait until the bandwidth limit resets - I think in 30 days. Or pay for Github Pro. – Dai Dec 07 '19 at 06:11
-
1https://help.github.com/en/github/managing-large-files/about-storage-and-bandwidth-usage – Saurabh P Bhandari Dec 07 '19 at 06:30
-
Ok so I need to wait for 1 month? – Pranav Dec 07 '19 at 06:31
-
@Pranav, Probably not, based on the image you have provided, ```Bandwidth quota resets in 0 days``` – Saurabh P Bhandari Dec 07 '19 at 06:38
-
@SaurabhPBhandari did you mean 30 days? – Pranav Dec 07 '19 at 08:15
-
2@Pranav, I contacted the GitHub support team and they refreshed my account to reset the limits as the quota limits didn't automatically reset after a month – Saurabh P Bhandari Dec 11 '19 at 18:08
-
OK was there any condition? – Pranav Dec 12 '19 at 05:30
-
@SaurabhPBhandari Same situation here, the bandwidth won't reset automatically. Who did you contact exactly, and how long did the reset take for you? – Nico Schlömer Oct 12 '21 at 08:51
1 Answers
Update Sept. 2021, on the radmap (not yet delivered):
"Git LFS moves to metered billing"
LFS billing will switch from prepaid data packs to metered (pay for what you use).
The free entitlements (for example, 1GB storage and 1GB bandwidth) will be unchanged.
Customers will not be billed for LFS storage that occurred prior to the start of metering.
Intended Outcome
This change brings LFS billing in line with how Packages and Actions bill.
Instead of prepaying for a quota, you'll only be charged for what your repositories use.How will it work?
We'll calculate how much storage is used and measure how much outbound bandwidth is used.
Each month, you'll be charged per-unit for each of these resources.
Original answer: Dec. 20219:
"About storage and bandwidth usage" from GitHub does mention:
When you download a file tracked with Git LFS, the total file size is counted against the repository owner's bandwidth limit.
Git LFS uploads do not count against the bandwidth limit.
So you can not remove or reset a bandwidth: it is already taken by your past downloads.
For example:
- If you push a 500 MB file to Git LFS, you'll use 500 MB of your allotted storage and none of your bandwidth. If you make a 1 byte change and push the file again, you'll use another 500 MB of storage and no bandwidth, bringing your total usage for these two pushes to 1 GB of storage and zero bandwidth.
- If you download a 500 MB file that's tracked with LFS, you'll use 500 MB of the repository owner's allotted bandwidth. If a collaborator pushes a change to the file and you pull the new version to your local repository, you'll use another 500 MB of bandwidth, bringing the total usage for these two downloads to 1 GB of bandwidth.
Plus:
Forking and pulling a repository counts against the parent repository's bandwidth limit.
So if your repository was forked, you don't even have to do anything for your bandwidth to be used.

- 1,262,500
- 529
- 4,410
- 5,250
-
1So can I upload images to newly created repo or I have to wait 30 days for auto reset? – Pranav Dec 07 '19 at 08:20
-
@Pranav upload yes, but not much. Download no: the limits are per GitHub account, not per repository. – VonC Dec 07 '19 at 08:22
-
What is download about? Well if I upload it what about bandwidth? As github has disabled my git lfs account – Pranav Dec 07 '19 at 08:25
-
1@Pranav as I mention in the answer, bandwidth is only about download. But I suspect since one of the two Git LFS limits was reached, that might affect your account for the month indeed. – VonC Dec 07 '19 at 08:30
-
-
1 GB bandwidth is like saying don't edit and push any file that is over 1KB. I mean even their 5GB bandwidth is nothing. How the hell they came up with such a low limits. Imagine you edit 500 MB file in 10 commits and boom you are out of bandwidth. This is literally saying we created LFS just for fun – Farid Jul 13 '22 at 16:36
-
@Farid I suspect this was initially to avoid DDoS and service abuse. The [billing](https://docs.github.com/en/billing/managing-billing-for-git-large-file-storage/about-billing-for-git-large-file-storage) would limit the use of LFS to motivated users only. You also [have releases](https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-large-files-on-github#distributing-large-binaries=) – VonC Jul 13 '22 at 18:33
-
@VonC That is great that they have it. But what if you want to use LFS for, let's say, screenshot testing? We have lots of screenshots on different screen resolutions and we are trying to keep source screenshots outside the repository. Since we are talking about large files, this can be use case example for LFS too. I have been trying to work around these limits with `git annex` but CI fails because major git services doesn't support it, anyway this was outside scope – Farid Jul 14 '22 at 06:02
-
@Farid You need to store those screenshot in another external referential (like an S3 bucket, like the [addpowerpoint screenshot service does](https://www.addpowerpoint.com/save-screenshots-to-aws-s3-bucket). And your pipeline would need to connect to that external referential to retrieve them (no native integration with a Git repository in that case, but a good workaround nonetheless). – VonC Jul 14 '22 at 06:05
-
Sorry I missed one word and it changed gist of my question :) . I meant screenshots for screenshot testing (Android). Since screens can change from one commit to other we need them to be stored in VCS backed storage – Farid Jul 14 '22 at 06:18
-
@Farid The gist of my comment remains. You need to control your external referential yourself. You can store those screenshots in a folder named after a Git commit, allowing you to retrieve the right version of those screenshots based on your Git commit. That would essentially emulate what Git LFS does for you. – VonC Jul 14 '22 at 09:31
-
1@VonC Thank you. This is what I had in mind and ended up doing this way. There will be problems when rebasing due to commit hashes but anyway. Nothing else comes to my mind as a temporary solution. I was just trying to find an "error-proof" out-of-box solution – Farid Jul 14 '22 at 13:51
-
@Farid True, rebase need to be addressed: a rebase could generate new commits entry to S3, but with as "content" the reference of the old commit rebased. That way, by indirection, you can retrieve the artifacts. – VonC Jul 14 '22 at 14:39