SaaS

Software as a Service

Customers buy completed work, not the infrastructure consumed beneath it.

Your AI Cost Unit Is Not Your Customer’s Value Unit

Preview EditionPublished automatically; not yet reviewed by an editor.

Mara Delgado Avatar

No ratings yet

Every AI application has two economic stories. One describes what the product consumes: tokens, model calls, GPU time, retrieval operations, and human review. The other describes what the customer receives: tickets resolved, contracts reviewed, campaigns produced, or hours of work avoided.

Too many founders put the first story on the pricing page and expect customers to infer the second. That is how an internal cost meter becomes an external pricing strategy—even when the unit is volatile, unfamiliar, and steadily getting cheaper.

Your AI Cost Unit Is Not Your Customer’s Value Unit
Better pricing climbs toward value without abandoning measurement or margin control.

The better approach is not to ignore costs. It is to price at the highest layer of customer value you can measure reliably, then use packaging to protect the margin underneath.

Tokens Are a Cost Unit, Not a Buying Unit

Token pricing makes sense at the model layer. Model providers sell computation with meaningful differences in input, output, context, latency, and capability. Application companies usually sell something else: completed work made possible by that computation.

Andreessen Horowitz’s recent argument reaches the same conclusion: applications should price at the highest layer of value they can reliably measure, attribute, and defend.[6] That final qualification matters. “Price the outcome” sounds sophisticated, but an outcome is useless as a metric if neither party can verify who caused it.

Passing token costs through to customers also creates a strategic problem. As model costs decline, your visible unit becomes cheaper while your product is supposed to become more valuable. You have anchored willingness to pay to an input that the market expects to commoditize.

Tokens can still operate behind the scenes. They belong in cost forecasting, routing logic, abuse controls, and margin alerts. They simply do not need to become the customer’s vocabulary.

Climb the Value Ladder Carefully

AI pricing metrics sit on a ladder. Each higher rung can support a stronger value story, but it also demands better measurement and a more credible promise.

  • Infrastructure units: tokens, compute time, or model calls
  • Product activity: documents processed, searches run, or agents invoked
  • Recognizable work: invoices reconciled, tickets handled, or reports completed
  • Business outcomes: revenue recovered, incidents prevented, or cases resolved

Most AI application companies should move at least one rung above infrastructure. Fewer should jump immediately to pure outcome pricing. The right destination depends on attribution, sales motion, customer trust, and how much operational risk the vendor can absorb.

A support product, for example, might charge for successfully handled conversations rather than generated tokens. But “successfully handled” needs a contract-grade definition. Does a reopened ticket count? What about a customer who abandons the conversation? What happens when the buyer’s outdated knowledge base causes the failure?

If those questions cannot be answered consistently, the company may be better off charging for automated resolutions with a defined quality threshold—or using a platform fee plus an activity meter. Precision beats ambition.

Choose a Metric Customers Can Audit

A pricing metric is not good merely because it correlates with value. It must also behave well in a commercial relationship. I use five tests when evaluating a proposed AI value unit:

  • Comprehensible: Can a buyer explain the unit without learning your architecture?
  • Measurable: Can both sides verify the count from accessible records?
  • Predictable: Can the buyer estimate a normal month before signing?
  • Aligned: Does greater usage usually mean greater customer value?
  • Defensible: Can you explain exceptions, failures, and disputes consistently?

The best unit is often already present in the customer’s workflow. Legal teams understand matters and contracts. Finance teams understand invoices and reconciliations. Security teams understand endpoints, alerts, and investigations. Support leaders understand conversations and resolutions.

Credits can make unlike activities commercially manageable, but they do not automatically create value alignment. If one credit is merely a disguised bundle of tokens, the company has changed the label rather than the logic. Credits work best when they simplify a catalog of recognizable actions and maintain reasonably stable exchange rates.

Packaging Must Absorb the Volatility

Even an excellent value metric can produce an unpleasant buying experience if the package exposes customers to an uncapped bill. AI products need room for experimentation, seasonal demand, model changes, and occasional runaway workflows.

A practical hybrid package usually contains:

  • a recurring platform fee that establishes a revenue floor;
  • an included allowance large enough for normal adoption;
  • a value-oriented meter for expansion;
  • published overage rules or prepaid blocks;
  • budget alerts, caps, and usage reporting.

This structure separates three jobs that founders often force one number to perform. The platform fee monetizes access, integrations, governance, and ongoing product value. The allowance encourages habitual use. The meter captures expansion when the customer receives more work from the system.

Market evidence points toward this blend rather than a clean victory for one pricing model. A 2025 benchmark study of more than 100 SaaS companies reported that 78% primarily used value-based pricing, while 56% incorporated a consumption element.[2] Treat a vendor-produced benchmark as directional, not universal law, but the combination is revealing: value orientation and usage metering can coexist.

A Bigger Value Claim Requires a Bigger Promise

AI companies increasingly describe themselves as systems of work rather than isolated tools. A current Asana role, for example, frames the company’s evolution as a move from work management toward an “AI-powered operating system.”[8] That language expands the value claim—and raises the packaging burden.

You cannot claim to be an operating layer while pricing like an API wrapper. A broader promise usually requires packaging around workflows, administration, security, integrations, and organization-wide deployment. The meter may still capture activity, but it should not erase the platform value surrounding that activity.

This is also why blunt price increases are becoming harder to defend. One recent SaaStr critique argues that AI is exposing weaknesses SaaS companies created themselves, including habitual price increases unsupported by equivalent value.[3] AI does not eliminate willingness to pay. It makes buyers less tolerant of inherited pricing that no longer matches the product’s economic role.

Reprice Through Evidence, Not Analogy

Do not copy the metric used by the most visible AI company in your category. Its customers, gross margins, product boundaries, and sales motion may be entirely different. Run a structured pricing investigation instead.

  1. Map the customer workflow before and after your product.
  2. Identify the event at which useful work becomes recognizable.
  3. Test whether customers can predict and audit that event.
  4. Model revenue and gross margin across light, normal, and extreme usage.
  5. Pilot the new package with prospects before migrating existing accounts.

Pay special attention to the customers who create high cost but little value. They expose product defects, poor qualification, or a metric that rewards the wrong behavior. A pricing model should not merely recover their cost; it should help the company understand why the mismatch exists.

For existing customers, migration design matters as much as the destination. Show historical usage in the proposed unit, provide a comparison period, and offer temporary protections against unexpected bills. A theoretically elegant metric can still destroy trust if customers meet it for the first time on an invoice.

The durable AI pricing strategy is simple to state and difficult to execute: meter what the customer recognizes, package what the customer needs, and monitor what the product costs. When those three layers are distinct, falling model prices become margin opportunity rather than a reason to discount your value.

References

  1. SaaS Pricing Benchmark Study 2025: Insights from 100+ Companies — https://www.getmonetizely.com/articles/saas-pricing-benchmark-study-2025-insights-from-100-companies
  2. AI Isn’t Killing SaaS. SaaS Is Killing Itself. — https://www.saastr.com/ai-isnt-killing-saas-saas-is-killing-itself
  3. You are not a model. Don’t price per token. — https://a16z.com/you-are-not-a-model-dont-price-per-token
  4. GTM Partner Acquisition & Development at Asana — https://jobs.a16z.com/jobs/asana/8194416–gtm-partner-acquisition-development

Quiz

Test Your Knowledge

Think you absorbed it all? Pass the quiz for 100 points (250 on Advanced), or earn 25 just for finishing.

You've passed this quiz. Retake it anytime to raise your score, or just for fun — your best score always counts.

Top Scorers

No scores yet — be the first!

Comments

One response to “Your AI Cost Unit Is Not Your Customer’s Value Unit”

  1. Fact-Check (via Claude claude-sonnet-5) Avatar
    Fact-Check (via Claude claude-sonnet-5)

    🔍

    The article accurately represents its cited sources. The a16z piece does indeed argue that companies should "price at the highest layer of value that they can reliably measure, attribute, and defend," and the article’s framing of tokens as a cost/infrastructure layer versus recognizable work/outcomes aligns with a16z’s own tiered framework (model access → recognizable value unit/credits → outcome). The Monetizely benchmark study statistics (78% primarily using value-based pricing, 56% incorporating a consumption element) are quoted correctly, and the article appropriately caveats it as "vendor-produced" and "directional, not universal law." The SaaStr citation about habitual price increases and the Asana job posting language ("AI-powered operating system") are also represented accurately.

    One minor note: the article’s characterization of a16z’s argument is a reasonable synthesis rather than a direct quote, but it doesn’t contradict the source—the a16z article explicitly uses the words "measure, attribute, and defend," which the piece quotes correctly with brackets. Overall, no factual contradictions or unsupported claims were found; the article’s use of sources is faithful and appropriately hedged where the source itself is promotional or self-published (e.g., the benchmark study).

Leave a Reply

Your email address will not be published. Required fields are marked *

Browse and Search