Report overall Git LFS usage is higher that detailed Git LFS usage

[mwestphal]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Discussion Details

I'm a maintainer over at f3d-app and we use extensively actions and git lfs for our open source repositories.
We do not have any kind of paid plan with github.

It looks like the overall Git LFS usage is higher than the detailed Git LFS usage.

When looking at our overall Git LFS budget it says:

But when looking at the detailed usage, its only:

Interestingly, when looking in more details I see a definitive drop in usage in our main repo:

There is no reason for this drop, we still have many users and contributors and did not change anything.

We also have another repo with the same drop, but we did change our setup around that time, but it should not drop to zero, it should just be reduced:

My theory is that detailed usage stop being properly reported in github system while overall usage keep being reported properly, however we need the detailed information in order to be able to adress that and reduce our usage in place where it matters.

(in all screenshots, you can ignore the gross amounts, only billed amounts matter)

[Mehrab-Javadzadeh]

That is actually really weird.
If your overall git LFS use is going up, but the detailed one suddenly dropped to 0 with no changes on your part, I would say its a reporting issue and you are most likely not using more.
Since you said this is happening across multiple repos I am leaning more towards its a general issue.
I hope someone from github gets back to us confirming that there was an issue with the git LFS counting. Thank you for providing the screenshots they will most likely help alot.

[jrb00013]

yeah your theory lines up with what i'm seeing too — overall climbing while detailed cratered (even toward zero on a repo that still has traffic) with no real change on your side smells like GitHub's detailed LFS reporting desynced, not you magically stopping downloads. overall is probably closer to truth; detailed is what you need to act on, which is the painful part.

i poked around f3d-app a bit. you've already done the big smart CI move (lfs: false + lfs-data-cache-action) so you're not blindly paying LFS bandwidth for every matrix job. good. the remaining burn is almost always who is pulling the actual LFS objects (cloners, forks, PR checkouts that still smudge, mirrors, people who git lfs pull for testing/data).

where your bandwidth actually lives

from .gitattributes on f3d-app/f3d you're LFS-tracking:

• testing/data/**
• testing/baselines/**
• examples/**/*/data|public|baselines/**
• .github/baselines/**
• doc/user/images/**

so when overall spikes, it's usually those fat test assets / baselines / example media getting cloned by humans or bots — not "mystery CI," assuming every workflow still uses your producer/consumer cache path.

advanced stuff i'd do to cut usage (and see which files)

1. inventory the heavy hitters locally (don't trust broken detailed UI)

git lfs ls-files -s | sort -k2 -h | tail -50
git lfs status
# bandwidth-ish view of what's actually in LFS history:
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
  | awk '/^blob/ {print $3, $4}' | sort -n | tail

also hit the LFS API / endpoint for pointer paths if you can, and keep your own daily meter (small cron that records git lfs ls-files sizes + Actions minutes). if github detailed is lying, your meter becomes source of truth.

2. compress / shrink datasets before they ever hit LFS
LFS stores whatever you give it — gzip/zstd/mesh-simplify/re-encode baselines before git lfs track. for testing data:

• downscale / requantize baselines where visual diff still works
• prefer compact formats (e.g. compressed meshes / smaller PNG/WebP where tests allow)
• drop unused fixtures instead of "keep forever in LFS history" (history still costs on fresh clones that fetch all)

3. stop paying for history you don't need

• GIT_LFS_SKIP_SMUDGE=1 in contributor docs for people who aren't running tests
• make sure no workflow accidentally flips lfs: true on checkout
• watch forks / external PRs — their CI on their fork can still pull your LFS objects depending on setup
• consider a separate data repo or Release assets / CDN for the biggest fixtures so day-to-day git clone isn't an LFS tax

4. cache discipline
you already produce/consume LFS via Actions cache — verify cache hit rates, bump cache_postfix when data changes intentionally, and make sure preheating (cache-preheating.yml) isn't the only job still doing expensive recovers on a cold cache.

5. on the reporting bug itself
open a GitHub Support ticket with your screenshots (overall vs detailed vs the cliff to zero). this exact "aggregate up, per-repo detailed flat/zero" pattern has bitten other orgs — you need them to fix metering, because you can't optimize what you can't see. free-plan LFS quotas make that especially brutal.

practical cut order: (1) find top 20 LFS blobs by size → (2) compress or relocate the monsters → (3) confirm every CI path is lfs: false + your cache action → (4) tell casual cloners to skip smudge → (5) lean on support for the broken detailed graph.

happy to sanity-check a specific workflow YAML if you paste one that's still suspicious.

[mwestphal]

please keep your slop to yourself.