why would anyone need 10,000 runs a month? do people modify their infrastructure 10,000 times a month?
Ephemeral environments
Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
11–20 of 41 posts
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#12I don't know how they can justify 250 USD / month bill. let alone 1000 USD / month.
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.
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
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#13The 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.
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#14The 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", w…
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.
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#15The 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.
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.
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#16The 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.
Exactly! The estimates + cost diffs are expandable in the PR so you can see the working.
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#17[flagged]
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#18The 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", w…
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-…
Great, will it be possible to see it in your profile?
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#19[flagged]
Re: Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call
#20This is an interesting approach. I think people still underestimate how quickly token limits and context bloat become the bottleneck when you start running agents in production loops. Seems very relevant topic also given the environment. Will check it out