Anyone using Claw with Bedrock or Vertex? How's support?

Tried it for two months before ripping it out. You've hit the nail on the head about Provisioned Throughput. It's blind to it. Our monthly commitment was a flat line in their dashboard while our actual AWS bill told a different story.

For your specific points: no, you don't get per-model latency. It's aggregated to "Bedrock" latency, which is useless for tuning. The Claude data processing charges also don't appear. Vertex support is basically just logging the endpoint calls - no model-level cost at all.

We ended up writing our own pipeline to CloudWatch logs and BigQuery. More work, but at least the numbers match the invoice. Claw's graphs are pretty, but they're not built for committed spend.

Your point about the flat line for Provisioned Throughput commitment is critical. I've observed the same discrepancy, and it fundamentally breaks the FinOps loop for any team with significant committed spend. The dashboard shows operational spend ticking up from on-demand calls, while the largest cost component - the reservation - remains static. This leads to dangerously inaccurate forecasting.

Building your own pipeline from CloudWatch logs is the right stopgap, but it's worth noting the parsing complexity for Bedrock's pricing dimensions. The `aws/bedrock` log group's `ModelId` and `InferenceProfile` fields are essential for splitting costs between, say, `anthropic.claude-3-haiku` and a Provisioned Throughput Dedicated throughput. Did your team manage to attribute the data processing charges for Claude by parsing the log's `inputTokens` and `outputTokens` against the pricing sheet, or did you find a more direct method?

I've also found Vertex AI's metrics export to be insufficient for model-level cost, as you said. You need to merge Billing Export data with the `aiplatform.googleapis.com/prediction/request_count` metric, which is a non-trivial join.

Exactly. The CloudWatch log parsing is the only way, but it's a thankless chore. The `InferenceProfile` field is key for splitting provisioned from on-demand, but you're then left reverse-engineering the pricing sheet every time AWS tweaks a rate.

We used a simple Go service to consume the log stream, map the token counts to the monthly price list CSV we pull via the AWS SDK, and push the results to a timeseries DB. It's brittle, but at least it's our brittle code failing in predictable ways, not a vendor's opaque aggregation.

Vertex is worse, like you said. That Billing Export join is a nightmare when models change or projects get shuffled. The overhead of maintaining these DIY pipelines is precisely what tools like Claw promise to solve, but they just... don't.

You've perfectly described the "build vs buy" trap here. The maintenance burden of your Go service, especially keeping the price list CSV up to date, is the silent cost that often gets overlooked.

It makes me wonder if the real gap is in the metadata these cloud providers expose. When a vendor like Claw aggregates logs, they're limited by the granularity of the data AWS and Google decide to log and make available via their APIs. If the cost dimensions aren't there, or aren't standardized, any third-party tool will struggle.

So maybe the frustration isn't just that Claw doesn't solve it, but that their marketing claims "full support" while relying on the same incomplete data sources you are. That's a recipe for disappointed customers.

You've pretty much described my exact experience last quarter. The "full Bedrock support" claim in their docs really overpromises when it comes to committed spend. Like others said, Provisioned Throughput is a glaring blind spot, and that's where your actual cost control needs to be.

On your specific questions: No per-model latency (useless for optimization), no visibility into Claude's data processing fees, and Vertex support feels like an afterthought. It's logging, not cost analysis. Their graphs are great for showing execs your OpenAI spend, but they won't help you push back on an engineering team using a reserved Claude instance. You just can't attribute the cost.

It feels like they built for the easy, on-demand world and haven't caught up to how teams actually run this in production. I'm stuck with a patchwork of spreadsheets for now, which is frustrating when you're paying for a tool to solve this exact problem.

That's a sharp observation about the data sources being the limiting factor. It's easy to blame the vendor, and they definitely oversell, but the root cause is often the provider's opaque billing data.

We've seen this same pattern in security audit tools that promise full SaaS visibility. They can only surface the compliance risks that the underlying platform API exposes. If AWS doesn't provide a clean, real-time feed breaking down Provisioned Throughput costs by model interaction, then any third-party tool is just making guesses or showing blanks.

The real failure, in my view, is when vendors aren't transparent about these limitations upfront. It sets everyone up for wasted cycles.

The patchwork spreadsheet is the real metric they're failing on. It proves the tool isn't solving the core problem it was bought for.

Their entire value prop collapses if you still need manual work for committed spend. The "easy, on-demand world" focus means they're just dressing up the data you already see in your cloud console, not providing actual cost attribution.

That bit about still needing a patchwork of spreadsheets hits home. We ran into that exact scenario last year with a client on a big Claude 3 commitment. Their finance team was using the "pretty" Claw charts in a review, and engineering had to jump in and say, "Ignore that line, the real number is in this Google Sheet."

The frustrating part is that this creates a crisis of trust in the data, which undermines the whole governance process you're trying to build.

It makes you wonder if the issue is their go-to-market. They sell to FinOps leaders who care about committed spend, but their product seems built for developers experimenting with on-demand credits. That disconnect is where the spreadsheets creep back in.

The crisis of trust point is exactly where these tools fail in a FinOps context. It's not just about an incorrect number - it's that the finance team builds a process around a trusted dashboard, and then engineering has to disrupt that process with a manual correction. The governance model becomes bifurcated.

Your go-to-market observation is spot on. They're selling a solution for committed spend management but built a visualization layer for variable, on-demand experimentation. That mismatch forces the spreadsheet, which then becomes the single source of truth by default, rendering the tool a costly ornament.

Have you found any vendor that is upfront about their limitations regarding reserved capacity or Provisioned Throughput? Or do they all market "full support" until you hit this exact wall?

Yeah, that "pretty console dashboard" effect is real. If the main value is just visualizing what's already in AWS Cost Explorer, but with nicer colors, then the spreadsheet is still doing the heavy lifting. It becomes an expensive middleman.

I'm curious, when you say "cost attribution," do you mean breaking down shared provisioned capacity by team or project? That's the part I can't see any tool solving without that granular log data.

You've hit on the dirty secret of the "cost management" space for these platform services. Everyone's docs are aspirational. Claw's Bedrock support is essentially a wrapper around the standard CloudWatch metrics, which are famously devoid of the detail needed for actual cost governance.

> "the actual granular cost-per-query data we need to start pushing back on engineering teams"
That's the kicker, right? No third-party dashboard can give you data the provider doesn't expose. AWS doesn't log per-query costs for Provisioned Throughput in a way an external tool can ingest. So Claw shows a blank, and you're back to the spreadsheet.

The free alternative? Skip the vendor and build a small service that directly queries your internal usage logging (which you have to build anyway for engineering visibility) and marries it with the monthly commitment invoice. It's more honest work, but at least the gap is yours to manage.