Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call

Posted by akh 5 days ago

Counter44Comment23OpenOriginal

We launched Infracost on HN five years ago (https://news.ycombinator.com/item?id=26064588) where our CLI generated cost estimates for infra-as-code, e.g. "this Terraform PR adds $400/mo". The idea was to shift cloud costs (FinOps) left, so engineers get visibility of costs before deployment and make better decisions.

Earlier this year we started seeing agent traffic in our logs and it looked like coding agents were calling our CLI. But that CLI wasn't designed with coding agents in mind. We went down a philosophical rabbit hole to see if a CLI is even needed anymore given that Claude, Copilot et al. already follow best practices. Ultimately we decided to create a new CLI from the ground up with coding agents in mind for two reasons:

1. We optimized the CLI for agent callers and cut Claude's output token usage by up to 79% and API cost by up to 67% versus a bare-Claude baseline. We wrote a blog documenting our lessons on optimizing user token usage when designing a CLI, e.g. using predicate flags so the agent doesn't compose jq | python | wc pipelines, output format that strips JSON's redundant field names. The blog is here: https://www.infracost.io/resources/blog/we-cut-claude-s-toke...

2. With cloud costs, precision matters. Telling a coding agent "make this Terraform cost-optimized" can be expensive and lossy. You burn tokens loading code and policy context into every conversation. Your agent could make up a price and you wouldn't know because it's difficult to verify that across the ~10M price points that AWS, Azure and Google have. The CLI runs static analysis on the code, uses the latest prices from cloud vendors, and passes that context to the coding agent.

So that's what we're launching today - Cost.dev: https://cost.dev/.

- It runs locally. Your code never leaves your machine, you get a fast feedback loop, and you're not burning API calls per character when you want to fetch prices.

- The CLI does the deterministic work. Fetching price points, scanning the code, validating fixes. The coding agent does the natural-language part. You don't have to trust the LLM to remember the rules, and can verify it called the right CLI command.

- It provides a consistent rule layer across every tool you use. Get cost estimates in your IDE and your coding agent with a single install. We support Claude Code, GitHub Copilot, Cursor, Windsurf, OpenAI Codex, Gemini CLI, as well as IDEs like VS Code and JetBrains

Before we keep building more in that direction, I want to sanity-check with HN: is "agents writing IaC in prod" actually a thing yet, or am I betting on a future that's still a year out? I know software developers are using coding agents heavily, but are platform/infra folks doing that for prod too? Also, if you have any feedback on Cost.dev, I'd love to hear it!

Comments

Comment by lavaman131 4 days ago

This 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

Comment by akh 4 days ago

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.

Comment by photonair 4 days ago

Tokens can get expended very quickly driving costs up substantially since there is no clarity in its usage If your service can cut the use substantially, for a large company with a huge AI bill, the savings could make up for the cost of the service which I think is pricey in my opinion. But I can see how it could work out.

Comment by akh 4 days ago

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

Comment by 5701652400 5 days ago

I don't know how they can justify 250 USD / month bill. let alone 1000 USD / month.

Comment by akh 5 days 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.

Comment by 5701652400 2 days ago

[dead]

Comment by hx8 5 days 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.

Comment by hkh 4 days 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

Comment by hx8 4 days ago

If you're primarily serving enterprise then the $250/mo foot in the door price makes sense. No reason to make too aggressive of a play for the small market/mid market.

Comment by tuo-lei 2 hours ago

how are you handling errors? when an agent gets a flag wrong, cli help text is usually massive. could eat a lot of the savings on retries.

Comment by 5701652400 5 days ago

why would anyone need 10,000 runs a month? do people modify their infrastructure 10,000 times a month?

Comment by akh 5 days ago

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

Comment by esafak 5 days ago

Ephemeral environments

Comment by zuzululu 5 days ago

Not really seeing the point I just use openrouter if I'm penny pinching

Comment by akh 5 days 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.

Comment by winphoto 4 days ago

[flagged]

Comment by songting591 4 days ago

[flagged]

Comment by sid_ships 4 days ago

[flagged]

Comment by sanreds 4 days ago

[dead]

Comment by zane_shu 5 days 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.

Comment by glenngillen 4 days ago

Exactly! The estimates + cost diffs are expandable in the PR so you can see the working.

Comment by jing09928 4 days 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.

Comment by glenngillen 4 days 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.

Comment by arxiv101 3 days ago

[flagged]

Comment by ismrhao 4 days ago

[flagged]

Comment by eugeneonai 5 days 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.

Comment by glenngillen 4 days 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.

Comment by eugeneonai 4 days ago

Great, will it be possible to see it in your profile?

Comment by glenngillen 4 days ago

I'm not sure I follow, which profile do you mean? My profile on HN?

I don't know if we'll keep dissecting every incremental improvement we make as (so far) the general approach is the same as documented in the existing blog post: document common use cases -> benchmark them -> identify bottlenecks/expensive hot spots -> fix them -> repeat

The main thing changing right now is observing new more frequent use cases (either because we're adding new capabilities, or users are doing things we didn't entirely predict) and adding them to the test cases.

Comment by dezsirazvan 4 days ago

[flagged]