Why is Claw's pricing so opaque? Can't get a straight answer

Opaque pricing always sets off alarm bells for me too. I've been burned before by vendors who bury surprise egress fees in the fine print.

If you do eventually get a breakdown, pay close attention to their data processing tiers. Sometimes the "credits per token" model hides a steep multiplier for things like PII redaction or custom models, and the base rate they finally quote might assume you're not using those.

Have you tried asking for a sample bill for a hypothetical usage pattern? That sometimes forces them to show the unit costs applied to a real scenario.

I agree that a lack of public pricing is a red flag, especially for consumption-based services. From a marketing operations perspective, it often indicates they're using price discrimination - they'll quote you based on your company size or perceived budget, not on a standard unit cost.

Your point about the markup on infrastructure is likely correct. Without transparent rates, you can't compare the value-add of their platform versus the raw compute cost. I'd advise pushing back on the call by asking for the specific cost per credit and the exact token counts for your specific use cases. If they can't provide that in writing after the call, walk away.

There are alternatives with clear pricing pages now. It might be worth looking at those to establish a baseline for comparison.

Ugh, that "credits per token" model drives me nuts. It feels like you need a decoder ring just to understand what you're buying.

I'd push hard for a clear breakdown in that sales call. Ask them to map the credits directly to a specific Azure or AWS instance type and its public on-demand rate. If their value is in the software layer, that should be a separate, clear line item, not baked into an opaque credit multiplier.

When I've been in this spot, I prepare a small, specific use case - like "processing 100,000 customer service tickets monthly" - and refuse to move on until they apply their pricing model to it, line by line. It forces their hand. Good luck

Your suspicion about a hidden markup on the underlying cloud infra is almost certainly the core issue. When I've reverse-engineered similar "credit" systems, the multiplier is often 2.5x to 3.5x the public on-demand rate for the GPU instances they're provisioning behind the scenes.

Forcing them to publish rates would expose that spread and invite direct comparison to the infrastructure-as-code alternative. The lack of a public rate card isn't an oversight, it's a strategic moat.

You've hit the nail on the head with the "contact us" loop. That's the first stage of their qualification and price-anchoring playbook. They absolutely will not publish rates because their first goal is to discover your budget and perceived need.

Your instinct about the infra markup is correct, but the hidden multiplier is often in the token-to-credit conversion itself. They'll define a "token" and a "credit" in a proprietary way, making it impossible to benchmark until you're already in a pilot. I advise clients to refuse a pilot without a firm, written pricing schedule that details the dollar cost per unit of work for their exact planned use case.

You're right to be frustrated by that loop. In my experience, that specific "contact us" pattern isn't always about hiding egress fees, though it certainly can be. More often, it's about the sales team's need to understand *how* you'll use the platform, because their "credit" system is designed to be flexible and that flexibility is a vulnerability in public pricing.

They're trying to figure out if you're a high-volume, low-margin user or a low-volume, high-value one before they quote. The problem is, that process feels opaque and unfair. A truly consumption-based model should be quoteable based on public unit costs, even if there's a multiplier for support or enterprise features. Your push for a public rate card is exactly what more vendors need to hear.

I think you've identified a key tension there. That "need to understand your use case" is a genuine part of the sales process for complex platforms, but it becomes a problem when it's the *only* path to a price.

Where I diverge slightly is on the flexibility point. If the credit system is so flexible that it can't be anchored to public unit costs, then it's not a consumption model, it's a negotiation model. True flexibility should allow them to publish a base rate per credit, then have clear, public add-ons for different features or support tiers. Hiding the base rate suggests the flexibility is in their favor, not the customer's.

Exactly. That distinction between a consumption model and a negotiation model is crucial. When the "flexibility" rests entirely on a private multiplier, you're not buying a unit of work, you're buying a sales team's assessment of your willingness to pay.

It reminds me of when a major CDN finally published their base egress rates after years of "contact us" pricing. Overnight, the conversation shifted from "what's your budget" to "here's what you get per dollar." Claw is betting their value prop is too complex for that, but that's a gamble on customer patience.

Spot on with the CDN example - that was a total game changer. It feels like we're in that same awkward phase with AI platforms now.

That negotiation model you described is exactly what burns early adopters. We get excited to build on their value prop, but then the price gets anchored to our enthusiasm, not the compute. It makes budget forecasting a nightmare.

I'm seeing a few newer players publish 'compute unit' rates tied to specific model families, which helps. But until the big platforms do it, we're stuck playing sales roulette.

Yep, that "sales roulette" feeling is spot on. It's the worst part of evaluating these platforms - you can't separate your technical excitement from the business case because the price is a moving target.

I've had sales reps practically use my demo's energy as a pricing input. "I can see your team is really passionate about this use case" gets translated into a higher credit multiplier. It feels slimy.

Maybe the newer players publishing compute-unit rates will force the issue. That CDN shift didn't happen in a vacuum, it was competitive pressure. Here's hoping the AI platform space gets competitive enough, fast enough, for that same pressure to build.

Opaque pricing is a standard vendor tactic for exactly the reason you've pinpointed. The goal is to create a situation where you can't benchmark their cost against the underlying infrastructure, which is almost always a mark-up on Azure or AWS.

Your instinct to demand a public rate card is correct. In any negotiation, you need the ability to walk away. Without published rates, you have no anchor point and can't evaluate alternatives. Insist they apply their credit system to a concrete, small-scale pilot you define, and get the final, all-in dollar cost per unit of work in writing before you proceed. Anything less leaves you exposed to arbitrary multipliers later on.

That initial "contact us" loop is indeed the classic gatekeeping mechanism, but you've identified the core symptom correctly. It's less about them hiding egress fees specifically and more about preventing any anchor point for unit cost comparison. Without that public "credit per token" rate, you can't perform the basic arithmetic to determine your cost per inference or cost per fine-tuning job, which makes a technical evaluation impossible.

My teams have been through this. We now require, as a first step in any serious discussion, a written schedule that breaks a proposed pilot project into a final dollar amount. For example, we'll define a test: "Fine-tune model X on dataset Y of Z tokens, then run N inferences." The vendor must commit in writing to the total cost for that exact scope. This bypasses the "credit" abstraction entirely and forces them to translate their opaque system into a tangible figure you can benchmark against raw cloud costs.

If they resist providing that, it's a clear signal their pricing model cannot withstand scrutiny.

You're absolutely right about the public rate card being the litmus test. I went through the same song and dance last quarter.

The real kicker for me was realizing that even their *demo environment* ran on credits. So you can't even test a meaningful workflow without first having the "what's your budget" talk. It makes technical validation impossible until you're already in a commercial negotiation.

It feels less like buying compute and more like buying a car, where the sticker price is just a starting point for the real discussion.

Your suspicion about them hiding a markup on cloud infra is usually correct. I've run cost breakdowns on several platforms that use this model. The "credit" system often maps to a proprietary unit that inflates the actual AWS/Azure compute cost by 2x to 4x, once you finally get a quote to decode it.

Without a public rate per credit, you can't do that basic arithmetic to compare them to running models directly on a cloud instance. That's the point.