Hi Infracost team, We use

infracost-diff

(GitHub Action) on PRs to post the cost-diff comment ("Monthly estimate increased by $X..."). We're on the free tier (1,000 runs/month) and have two questions: 1. What exactly happens once we exceed the 1,000 free runs/month? Does the action stop posting the cost-diff comment entirely for the rest of the billing period, or does it degrade gracefully (e.g. only losing the FinOps/tagging-policy and guardrail sections while the basic "Monthly estimate increased/decreased by $X" table still posts)? 2. For our use case, the plain cost-diff comment is what matters most day-to-day — the FinOps policies, tagging checks, guardrails, and Cloud dashboard/leaderboard are nice extras but not essential for us right now. Is there a supported, uncapped way to get just that cost-diff PR comment without it counting against the 1,000 runs/month (or without requiring an Infracost Cloud org/connection at all)? We noticed the CLI was restructured in v2.x —

infracost breakdown

,

infracost diff

, and

infracost comment github

no longer exist, and `infracost scan`/`infracost ci setup` now seem to require an Infracost Cloud org connection. Is there still a standalone, open-source-only path (no Cloud account, no run cap) to compare two Terraform plans and get a cost delta, or has that capability been fully retired ?

Hi Yash, Thanks for trying Infracost! I'll clarify a few things to help explain what the "runs" are and what they count for • The free tier 1000 IS ONLY for the pricing estimates.   Those 1000 runs do NOT include cloud or dashboard functionality at all (finops/tagging/guardrails). • You're currently getting cloud/dashboard functionality as a trial for your new signup.  But that will stop automatically in 2 weeks and leave you with just the pricing results in the comments (so yes, that will degrade gracefully) • If you exceed 1000 runs per month, then the pricing will stop as well. (keep in mind that a PR utilizes 2 runs - one for the PR branch and one for the base branch in order to calculate a difference in price) • Yes, you can purchase more runs - that is our "Starter" plan - $250/mo for 10,000 runs per month • The standalone, no cloud product will continue to be the v1.x CLI.  You should use that version - you're correct the 2.x version will not work for you.   It always has had and always will have a run-cap.  The pricing data is proprietary and comes from our hosted price API server (which is what you're paying for). Please let me know if you have any other questions!!! Cheers, Drew

Hi @swift-furniture-85673, Thanks, that's really helpful! One line left me a bit unsure and I want to make sure I get the follow-up right before we change our setup:

"...you're correct the 2.x version will not work for you. It always has had and always will have a run-cap."

Does "it" refer to the 2.x version specifically (i.e. v1.x does NOT have this same run-cap since it's not cloud-connected), or does the run-cap apply to pricing lookups in general regardless of CLI version ? Concretely: 1. If we switch our CI to the standalone v1.x CLI instead of the v2.x-based, can we run it uncapped (no 1,000/month ceiling), since it's not connected to Infracost Cloud? 2. Just to confirm the math on the current setup: since each PR run uses 2 runs (base + head), the 1,000/month free cap effectively means ~500 PR diffs/month, right? Thanks again!

Hi Yash, The "it" is both our CLIs, including v1 - v1 also has the run cap (always has) and uses our pricing data api (that's what gets you the price cost estimate) 1. Switching will not change the caps on pricing data usage 2. The math does not cleanly map to PRs.   Here's an example: a. Open PR - 2 runs consumed b. Add new commit to that open PR - 2 more runs consumed to recalculate and update the comment c. Merge PR - main branch has now changed - 1 new run to update main branch (unless you remove the

infracost:default-branch-update

 trigger) d. So that would be 5 runs for that PR e. If you do exactly one commit for every PR and remove the default branch runs, then yes you can get 500 PRs.   But most PRs we see have several followup commits with recalculations, so you're closer to 100-300 PRs per month. Cheers! Drew

Hi Drew, Separate issue from the run-cap question — think we've hit a real bug and wanted to flag it with what we've tested so far. (Our repo is private, so I can't share direct links, but happy to share specific file/config snippets if useful.) We use a dynamically-templated

infracost.yml.tmpl

(using

matchPaths

to auto-discover projects) with

terraform_var_files

pointing at generated

.tfvars

files for each project. This was working correctly before — we saw real cost-diff comments on PRs reflecting our actual resource configs. But for a while now, every scan/diff — regardless of which PR or how large the underlying change is — returns the exact same result, as if none of our

.tfvars

changes are being read at all. What we've tried, to rule out anything on our end: • Confirmed on multiple different PRs, with meaningfully different (and large) infra changes each time — same "no cost change" result every time. • Reran locally with`infracost scan`(not just the hosted GitHub Action) — same stale result. • Fully uninstalled and reinstalled the CLI (previously v2.5.2, now clean install of v2.9.1), wiped local config/cache (

~/.config/infracost

,

~/Library/Caches/infracost

,

infracost cache clear

) — same result, unchanged. • Verified the actual`.tfvars`files being pointed to by`terraform_var_files`exist on disk with real, current, non-stale content matching the change we made. Every project in our config that relies on

terraform_var_files

shows the same symptom: it's not picking up the values from the file at all. For projects whose variable has a default, it silently falls back to that default (e.g. a Kubernetes module renders its built-in default single node pool instead of our actual node pool list). Given this reproduces identically across a full reinstall and a completely separate account, it doesn't look like anything on our end (cache, stale files, account/org config) — seems like a genuine bug in how `terraform_var_files`/`terraform_vars` are applied when the config is a

.tmpl

(dynamically templated) file. Could you take a look, or let us know if this is a known issue? Also, just to rule it out on the safer side — could you check if my account has hit its monthly run limit? Since every scan is showing the exact same output regardless of what we change, I want to confirm that's not what's actually happening element here. (mail attached to the account :- yash.r@aftershoot.com)

Thanks for all the info yash: • Your account has definitely not hit the monthly limit, not even close • I've tried to reproduce based on what you described, but I don't see this behavior happening.  Everything you described sounds very much like our typical operations (multiple tfvars files, etc) so I would expect it to be working. • No, there's no known issue related to this Would it help to maybe email us (support@infracost.io) so you can privately share the code and template you have and we can look to debug some more?