akh

Thanks - indeed, it's also difficult to estimate how much the agents will cost in advance, and how much changes could reduce or increase costs.

yep, the ROI for cloud and AI spend tools is fairly easy to measure: it has to save multiples of what it costs.

We prevent way more than that from being added to the cloud bill by showing engineers cost estimates that enables them to make better decisions pre-deploy - e.g. when an engineer knows the IOPS option on their EC2 instance is costing them a lot, they're more likely to reduce that or not use that in dev envs vs just copy/paste what's on production. There's an ROI report on infracost.io that shows how we measure the cost prevention between the first and last commit on merged PRs.

CI/CD pipelines needs 1 CLI run per commit (like any other code scanning tool), we regularly see enterprises with 100K+ runs/month.

OpenRouter is great for keeping your LLM API bill down, Infracost is about the AWS/Azure/GCP bill your IaC creates. When an agent writes IaC that creates a NAT gateway or an RDS instance, that's $50-5000/mo in cloud spend, so the agent knowing that estimate and the best practices as it's generating the code can optimize it pre-deploy.

co-founder of Infracost here, we launched Infracost on HN five years ago, when the CLI just generated cost estimates for Terraform. Earlier this year we were scoping a 1.0 release: the CLI would stop being just a cost-estimation tool and start surfacing the issues behind the costs: previous-generation instances, policy violations, the kinds of issues a thorough PR review would catch.

Then agent traffic started showing up, and it became clear the 1.0 scope was the right idea aimed at the wrong caller. A human reviewer reads a PR comment; an agent runs `infracost inspect --filter` ... and gets the same insight as a tabular row it can pipe into the next step. So we decided to skip our planned 1.0 release and go for 2.0, where we treated agents as a first-class citizen user of the CLI.

Along the way we picked up some interesting lessons on optimizing user token usage when designing a CLI, and we want to share them with the HN community since other CLI builders might benefit.

and the vast majority of times you don't need those 2 recommendations in non-prod envs... Infracost only makes recommendations if they reduce your costs, not increase them.

We started out with the Infracost CLI showing engineers cost estimates in the terminal before they deployed their code. The learning was that it also makes sense to check for other things like tagging policy issues and best practices not being followed as these things are more actionable than showing engineers a cost estimate. The cost estimate is actually more useful to trigger notifications on, e.g. if an engineer is adding $10K worth of databases, let the engineering management or FinOps teams know so they're not surprised by the spike in the bill and can adjust budgets if needed.

Thanks! Yep, we're partners with HashiCorp and worked on that integration early on :)

I suppose the difference between flaky tests and typos in tags/missing tags is that the latter is less about flaky-ness, and more about the engineer deciding not to fix the tagging issue and merging anyway. In Terraform, tags are fairly easy to fix and don't require the resource to be recreated so it feels like it should be a quicker fix then fixing/refactoring tests.

I think the easier we make it for engineers to fix tagging issues, the more likely it'll be for engineers to take action. Send me an email asking me to read the company's wiki page on tagging policy and I'll delete the email; tell me I have a typo on line 8 as soon as I open my pull request, I'll fix it and move on.

Interesting idea! The pull request authors are shown out of the box but we hadn't thought of using git to find the user for each resource on the main branch. Most organizations end-up tagging the resources with some sort of owner or team so they can group the costs using that and track it per team/service/product over time. That's often how FinOps teams start to create a sense of ownership for cloud costs amongst teams.

Great point - indeed FinOps teams consistently rank "empowering engineers to take action" as their number 1 challenge (https://data.finops.org) - and by that they mean the human and organization dynamics of the culture change they want to create across the org.

The testing analogy is a good one as this feature also shows the engineers the current "failing policies" on the main branch too, so whilst they could merge the pull request without fixing the tagging issue, it'll just get added to the list. And maybe like tests, they group them into one task and go through to fix them all every so often to get the main branch back to green!

I'm co-founder of Infracost, happy to chat more about how we can make it great :) feel free to join the community chat if you want to DM me: https://www.infracost.io/community-chat

Great examples - thanks!

Very cool idea! Some created a prototype with Terragrunt (https://github.com/infracost/infracost/issues/463#issuecomme...). With Infracost parsing HCL directly, we might be able to introduce annotations for estimates -> alerts

Not yet but users are asking for it, feel free to add a list of the resources you think would be useful to here: https://github.com/infracost/infracost/discussions/985#discu...