Rendered at 04:58:27 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
5701652400 8 hours ago [-]
I don't know how they can justify 250 USD / month bill. let alone 1000 USD / month.
akh 8 hours ago [-]
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.
hx8 7 hours ago [-]
Seems to be targeted at quickly reducing infa cost for small-human teams with high-compute costs. I can see some value, but it's something I'd want to review quarterly instead of per-commit. I might feel different if I was really trying to stretch some runway.
I can see why YC is interested in this issue, as I'm sure lots of startups are trying to stretch that runway.
hkh 6 hours ago [-]
When we started, we thought everyone could use it from startups to medium sized companies. What we learnt is that the most value comes for the enterprises. The reason is they have used Terraform to decentralize the infra provisioning, so now instead of a central platform team making all the IaC changes, you have hundreds or thousands of engineers making changes every month.
Each of them are making a lot of decisions on the infra. and that combines with the crazy pricing models from the cloud providers was saving companies a lot of money.
Then, we saw how much time is saved when you catch it at this point vs after the fact. Basically avoiding a bunch of tech debt
5701652400 8 hours ago [-]
why would anyone need 10,000 runs a month? do people modify their infrastructure 10,000 times a month?
akh 8 hours ago [-]
CI/CD pipelines needs 1 CLI run per commit (like any other code scanning tool), we regularly see enterprises with 100K+ runs/month.
esafak 6 hours ago [-]
Ephemeral environments
zuzululu 10 hours ago [-]
Not really seeing the point I just use openrouter if I'm penny pinching
akh 9 hours ago [-]
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.
jing09928 3 hours ago [-]
The interesting bit is making cloud cost a first-class constraint for the agent loop, not just a post-hoc report. I'd be curious how you handle confidence/uncertainty in estimates, since a wrong cheap-looking recommendation can be worse than no estimate in infra PRs.
glenngillen 2 hours ago [-]
We've a lot of experience doing this! Also while this feeds into and supports LLMs and non-deterministic systems, our recommendations are entirely deterministic. So it's pretty rare to have a "wrong" recommendation given they've essentially been implemented + reviewed by actual people.
What can definitely happen though is you get one that is inappropriate in a given context. An example here might be a recommendation from an m5.2xlarge to an m6g.2xlarge instance. Same vCPUs and memory, lower cost, but... also a switch from Intel -> ARM architectures. For a lot of companies their build pipelines make it easy enough to make that change. For others there may be some specific dependency on Intel for that workload which means changing the architecture isn't viable. In that case you can simply dismiss the recommendation and we'll stop suggesting it.
zane_shu 7 hours ago [-]
The useful split here seems to be: let the CLI do price lookup and validation, and let the agent decide which diff to make. The thing I’d watch is how visible the source of the estimate is in review — if a PR says “saved $X”, reviewers need to see which prices/rules produced that number.
glenngillen 2 hours ago [-]
Exactly! The estimates + cost diffs are expandable in the PR so you can see the working.
eugeneonai 16 hours ago [-]
The 79% / 67% reduction generalizes broader than IaC. Any CLI agents shell out to (curl, jq, grep, kubectl, gh, psql) burns the same token tax — verbose JSON, free-form text output, agent-composed pipelines. A predicate-flag + compact-output redesign would land on all of those.
Direct answer to your question: agents-writing-IaC-in-prod is rare today but not zero. I see more "agent reviews the IaC PR a human wrote", which Cost.dev sounds well-suited to since verification runs locally and the agent only consumes the result. Even if the prod-IaC path takes another year, the design pattern earns its keep on every agent-shellout you already do. One question: does the CLI surface its cache state to the agent, or does each invocation start fresh Repeated price-fetches across a single agent run would be the obvious next-tier savings.
glenngillen 2 hours ago [-]
We do cache the results locally so that we're not repeatedly hitting our pricing API. The LLM doesn't access that cache directly though as it'd suffer the token tax you mention. Instead we optimised our CLI to return agent optimised results. We're constantly iterating and improving on it, but it already reduces the tokens usage very significantly. I wrote about it here: https://www.infracost.io/resources/blog/we-cut-claude-s-toke...
We've found even more improvements since that post so those will be shipping soon too.
I can see why YC is interested in this issue, as I'm sure lots of startups are trying to stretch that runway.
Each of them are making a lot of decisions on the infra. and that combines with the crazy pricing models from the cloud providers was saving companies a lot of money.
Then, we saw how much time is saved when you catch it at this point vs after the fact. Basically avoiding a bunch of tech debt
What can definitely happen though is you get one that is inappropriate in a given context. An example here might be a recommendation from an m5.2xlarge to an m6g.2xlarge instance. Same vCPUs and memory, lower cost, but... also a switch from Intel -> ARM architectures. For a lot of companies their build pipelines make it easy enough to make that change. For others there may be some specific dependency on Intel for that workload which means changing the architecture isn't viable. In that case you can simply dismiss the recommendation and we'll stop suggesting it.
We've found even more improvements since that post so those will be shipping soon too.