You can try. A lot of platform and engineering teams already have.
They export a billing report. They paste it into an AI tool. They ask: where is this spend going, and what should we fix? The model reads the file, finds some patterns, and returns a list of suggestions. Rightsize some instances. Check your idle resources. Review your commitment coverage.
The suggestions are not wrong. They are just not yours. They describe the waste that is broadly true across most cloud environments, which is exactly what a model trained on publicly available documentation and forum discussions would produce. Your actual waste, specific to your environment, your usage patterns, your workload architecture, sits in the gap between the generic suggestion and what would actually move your bill. That gap is where the real money is, and closing it requires investigation, triage, and routing to the engineers who can act. By the time that loop completes, the spend has already happened.
The difference between knowing about cloud costs and knowing your cloud costs
There is a version of cloud cost expertise that comes from reading documentation, whitepapers, and engineering blogs. An AI tool has absorbed all of it. It knows the categories of waste.
That knowledge is not enough to build an end-to-end waste detection pipeline. AI knows what the common recommendations are. It will tell you the right things to look at, in roughly the right order, with appropriate confidence. What it cannot do is tell you which of those things is actually true in your environment, because that knowledge does not come from documentation. It comes from years of working inside production billing data across hundreds of real environments, seeing how the same service behaves differently at different scales, under different workload patterns, with different discount structures, and most importantly: handling endless pushbacks from system owners, claiming that your recommendation is not accurate enough. That is practitioner knowledge. It is not available online, because it was built by engineers doing the work. In PointFive, whenever a customer reaches out with feedback about an opportunity we surfaced, we don't stop at providing them the answer. We do our best to really understand their original concerns and make sure our detection algorithm is aware of them. It makes our waste detection codebase a layered cumulative corpus of not only inefficiencies, but also the concerns of engineers addressing them.
LLM data analysis is as good as its semantic layer. Ask an AI tool: "What was my EC2 spend in March?" Answering that correctly requires correctly interpreting more than 30 columns in the AWS Cost and Usage Report. Some are additive. Many are not. The number in the Cost and Usage Report is not the number on your bill once credits, EDP discounts, and savings plan drawdowns are applied. The semantic meaning of those fields is not in the file you export. It has to be built, and it has to be right, because a wrong answer here sends engineers chasing the wrong problem.
What proprietary research looks like in practice
PointFive Labs is a team of cloud, data, and AI researchers whose full-time work is finding new waste patterns, validating detection logic, and updating that library as cloud providers change their services, pricing models, and usage behavior. Our findings are specific, counterintuitive, and verified against real billing data, not against what the documentation says should happen.
The findings that matter most are the ones that do not appear in any whitepaper, because they only become visible after analyzing how real production systems actually behave. They emerge from looking at enough environments to recognize a pattern when it is hiding, and building detection logic precise enough to catch it reliably. The team adds dozens of new saving opportunities every week across cloud infrastructure, data platforms, and AI services.
That work is encoded in DeepWaste: 500+ validated detections across AWS, GCP, Azure, Kubernetes, Snowflake, Databricks, OpenAI, Bedrock, and more. Each one encodes a specific type of inefficiency: a resource sized for peak load running at 3% utilization, a Bedrock model handling classification tasks that could run on a model costing 15x less, a production AI workload routing requests to the most expensive tier when a cheaper one produces equivalent results. Every finding is verified against actual billing before it reaches you.
A team running AI workloads on Bedrock recently found they were on track to run 40-50% over their AI budget for the year. The issue was model selection: high-complexity tasks were being routed to frontier models by default, including tasks where a cheaper model performed identically. No billing dashboard surfaced it. No AI tool would have caught it from a cost export, because the signal is not in the billing file. It is in the relationship between invocation logs, model pricing tiers, task complexity, and output quality, cross-referenced against enough similar environments to know what the inefficiency looks like before it compounds.
These are the kinds of inefficiencies cataloged in the Cloud Efficiency Hub (hub.pointfive.co), an open-source library built with contributions from 70+ practitioners across the industry. We were confident enough to publish it openly and continuously contribute our entries because the community-level knowledge, the patterns experienced engineers have collectively observed and documented, is worth sharing. What sits underneath PointFive goes further: proprietary detection logic that only becomes possible after years of working inside real production environments, cross-referenced against actual billing data. The Hub is what the community can see. DeepWaste is what that depth of experience produces when you go beyond it.
The data problem, and what Brain does about it
PointFive is built as an AI Efficiency OS: a system that runs continuously across your cloud, data platforms, and AI services, surfacing inefficiencies, routing them to the right owners, and verifying every result against actual billing. Chat, Agents, and Apps are how your team interacts with it. Brain is what makes the answers correct.
Brain is the data and intelligence foundation underneath every module. InfraFabric connects to 40+ data sources across cloud providers, data platforms, and AI services and normalizes everything: different billing formats, different discount models, different cost allocation schemes. DeepWaste sits above that, where the 500+ validated detections run. And Brain also gives your team the ability to bring in their own context: budget files, capacity forecasts, headcount data, product tier mappings.
A customer wants to know what it actually costs to serve a free-tier user versus an enterprise user. The billing data is in the platform. The mapping from infrastructure to product tier lives in a Google Sheet. Brain joins them, makes the result queryable by Chat, actionable by Agents, and buildable into an App, all within the same platform, using data that stays where it already lives.
When your FinOps team asks why AI spend is trending 40% over forecast, the answer requires billing data, invocation logs, model pricing tiers, and the budget file someone maintains in a spreadsheet. Getting that answer from a general-purpose AI tool means exporting everything, assembling the context manually, and trusting that the joins are correct. Brain is built to do that work accurately, with the semantic layer already in place.
Finding it is only half the problem
Even with perfect detection, most cloud and AI waste does not get fixed on its own. The finding lands in a dashboard. The engineer who owns the resource is in a sprint. The ticket gets deprioritized. The bill keeps running.
PointFive's Agents module closes that gap. It continuously routes findings to the right owners with the context they need: root cause, risk level, business impact, and suggested fix, through Jira, Slack, ServiceNow, or whatever tools the team already uses. Low-risk improvements are applied automatically. Anything consequential requires human-in-the-loop approval before it runs. Every completed action is verified against actual billing data, so savings are confirmed, not estimated.
The operational work that takes a FinOps engineer hours each week runs continuously. Nothing waits for someone to pull a report or chase an engineer for an update.
The honest answer
It's all about trust. You need to trust the engine producing recommendations, and you need to trust your fellow colleagues that act on them.
Days will tell the impact of AI-generated artifacts on the work culture. But it's already clear that AI slop is a major threat to professional trust. One AI slop recommendation can be enough to ruin a whole FinOps program.
PointFive helps you with both. We commit to deliver credible, trustworthy recommendations. We allow our FinOps users to effectively escalate those to engineers using built-in workflows, and it helps both sides to trust each other.
Asking Claude what is driving your cloud and AI bill will get you a solid starting point. It will tell you what usually matters, in the terms any experienced engineer would recognize. What it will not tell you is what is actually happening in your environment, because that requires detection logic built from real production data, not public documentation. One is a well-read generalist. The other is someone who has seen this specific problem before and knows exactly where to look.
PointFive finds what generic tools miss, gets it to the right owners automatically, and measures every outcome against your actual bill, drawing on 500+ validated detections and dozens of new saving opportunities added every week.