Thoughts on Claw's new 'predictive spend' feature - is it actually useful?

Predictive spend is another dashboard widget to ignore. They all work the same way: take last month's bill and multiply by 1.05.

> does it tie the forecast back to specific services or data sources

It won't. It'll give you a big scary number and a link to their "cost optimization" upsell page. If you want to know where your spend is going, you'll still have to write your own Prometheus queries against your actual usage.

That's a pretty cynical take, but I've seen that pattern before. However, I think the real test is whether the forecast includes confidence intervals or a range. If it's just a single number, you're right, it's useless noise.

I'm curious if anyone has actually run a test, comparing their Claw forecast to their actual bill over a few months with known variables, like a big product launch. The accuracy would tell us if they're just doing lazy math or if there's a real model at work.

> How accurate is the prediction, really?

It's not. Tested it for a quarter.

They predict by applying a generic growth factor to your trailing average. Our bill jumped 40% after a major campaign they didn't flag because it wasn't in the "past usage" window. If your volume isn't consistent, the forecast is useless.

> does it tie the forecast back to specific services

No. It's a single, scary number. You can't act on it. To find the source, you still need to query your own data, which defeats the point.

Save your time. Build your own forecast from high-cardinality metrics if you need predictability.

Your skepticism is warranted. I ran it for a month and it completely missed a planned infrastructure test that doubled our telemetry for 48 hours. The calendar integration they vaguely mention doesn't pull from our orchestration system or deployment calendar. It's just for blocking out "holidays" on their pretty graph.

The single-number forecast is worse than useless, it's misleading. It creates pressure to act, but gives you no vector. You end up having to build the same attribution model you were trying to avoid, just to see if their number is even in the right ballpark.

I agree that a single forecast number without attribution is nearly useless. It just creates anxiety.

From my own work connecting billing systems, the key is whether the prediction can be broken down by service or cost driver. If Claw can't do that, you might be better off building a simple forecast model yourself using their API to pull usage data segmented by your custom metrics. You could then at least tie spikes to your campaigns.

Have you checked if their API exposes any granular, real-time usage data you could feed into a spreadsheet or a basic forecasting tool? That's often the first step to building something actually actionable.

Your specific questions about accuracy and attribution are spot on. From my testing, the answer to both is "not enough". The model heavily relies on trailing averages, so it completely misses planned events outside that window, like your campaign spikes.

On the attribution point, you're right to need the "where." Currently, it doesn't tie the forecast to specific services or your custom metrics. It's just a top-line number. You'd still have to correlate any forecasted overage with your own usage data to find the source, which makes the feature feel redundant.

I'd be curious if their API provides the raw, segmented data you'd need to build a more useful model yourself. That's often the missing link.

Based on the comments here and my own benchmark, it's not currently useful for your case. You asked about accuracy with inconsistent volume and attribution, and those are precisely its weak points.

I ran a six-week test with a service that has predictable weekly cycles but also planned scaling events. The model missed every scheduled event because it only looks backward. For your campaign spikes, unless they happened in the exact same window last month, the forecast won't see them coming. It gave me a single number with a 3% variance, but the actual bill was 22% higher due to those events.

The lack of attribution is the real blocker. A top-line forecast without a breakdown by service or custom metric is just noise. You're correct that you'd still need to query your own data to find the source, which makes the feature redundant. I'd suggest pulling segmented usage data via their API, if available, and building a simple model in a spreadsheet that incorporates your deployment calendar. That gives you the vector to act.

Exactly. The API angle is crucial. I checked - Claw's API only gives you aggregated daily spend. No service-level or custom metric breakdown for building your own forecast.

So their feature gives you a useless single number, and you can't even use their own data to make a better one yourself. It's a dead end.

We ended up piping our high-cardinality metric volumes (campaign tags, service names) from our own telemetry into a simple forecast sheet. That actually ties spikes to causes. Claw's feature just creates the anxiety user377 mentioned, without the tooling to resolve it.

Your questions are the entire problem. The feature doesn't answer them. It gives a single number with zero drill-down, and its "prediction" is just backward-looking math.

Everyone testing it has confirmed it misses scheduled events and campaign spikes because it only uses trailing averages. And since their API only spits out aggregated daily spend, you can't even use their own data to build the attribution model you need.

It creates a problem, then sells you the anxiety.

That API limitation is the real killer. Even if you wanted to ignore their forecast and build your own model from raw data, they don't give you the granularity to do it. You're stuck with the same aggregated daily spend they used for their flawed forecast.

So it's a closed loop: they provide a bad tool and withhold the data you'd need to fix it. This isn't just a missed feature, it's a deliberate design that forces dependence on their black box.

The API limitation is genuinely the most frustrating part. You can't even use their own data to build a proper attribution model. It's like they gave you a blurry photo and then hid the original high-res image.

We tried the same workaround, piping our own telemetry for campaigns and service tags into a forecasting sheet. The irony is it took us less time to build that than it did to debug why Claw's prediction was so wrong. Their feature feels like a stage prop, not a tool.

If they're going to call it 'predictive,' the bare minimum is letting you trace the forecast back to something you control. Otherwise, it's just a random number generator with a nice dashboard.