SaaS

Software as a Service

The Token Tax Is Real: Why Outcome-Based Pricing Is the Only Honest Answer for AI-Native Founders

Eli Brandt Avatar

No ratings yet

There is a structural cost embedded in every AI product built on rented intelligence, and most founders are not talking about it honestly enough. Call it what it is: a token tax. When you build on top of a model you do not own, you pay published API rates that already include the supplier’s margin. The model maker serves its own subscribers at internal cost. You do not get that deal. The effective cost-subsidy ratio between first-party and third-party serving runs roughly 10 to 25 times [1]. That gap is not a temporary market inefficiency. It is the price of building on someone else’s infrastructure, and it shows up directly in your gross margin.

The numbers are not subtle. Traditional SaaS businesses like Salesforce run gross margins around 77%. AI-native products, with real compute costs on every query, land at 50–60% [3]. That is a 20–30 point structural penalty, and it does not go away by growing faster or closing bigger deals. It is baked into the cost of goods. The only way out is to either own the inference stack — a capital-intensive path most founders cannot afford — or to price in a way that aligns your revenue with the actual value you deliver, so that your margins can recover as inference costs fall.

The Token Tax Is Real: Why Outcome-Based Pricing Is the Only Honest Answer for AI-Native Founders

That second path is outcome-based pricing, and it is worth being precise about what it does and does not do.

What Outcome Pricing Actually Solves

Outcome-based pricing charges only when the AI agent delivers a defined, verifiable result. Intercom’s Fin charges $0.99 per resolved support ticket. HubSpot’s Customer Agent dropped to $0.50 per resolved conversation in April 2026 [1]. The customer pays for the resolution, not the token burn it took to get there. That is genuinely useful for buyers: it protects them from the cost swings of a long, runaway agentic session, and it makes the value proposition legible in a way that token counts never can be.

But here is what outcome pricing does not do: it does not make inference cost disappear. It shifts the usage risk from the customer to the vendor [1]. If a ticket resolution costs $1.50 in inference to produce and you sell it for $0.99, you are losing money in a different currency than before, but you are still losing money. Outcome pricing is a discipline. It only pays off when the underlying inference engineering has also been done — when you have built an agent that is efficient enough that each verified resolution is profitable at your published rate.

This is the part most pricing conversations skip. Founders hear “outcome-based pricing” and think it is a positioning move. It is not. It is a margin commitment. You are telling the market: I am confident enough in my cost structure to absorb the inference risk. That confidence either exists or it does not, and the market will eventually find out which.

The Seat-Based Trap

Per-seat pricing made sense when serving an additional user cost nearly nothing. SaaS was built on that assumption. AI inference broke it [2]. When a seat holder runs an agentic workflow that burns thousands of tokens, the cost of that seat is no longer predictable. Companies that held rigidly to seat-based models saw gross margins roughly 40% lower on average than usage or outcome adopters [2]. The per-seat model does not just underperform at scale — it actively misrepresents the cost structure to both the customer and the business.

There is also a subtler trap in seat pricing for agentic products specifically. Agents reduce the number of human seats needed. If your pricing unit is the human seat and your product is replacing human work, you are pricing yourself into irrelevance. Gartner predicts that by 2030, seat-based vendor revenue share will decline from 21% to 15% of enterprise SaaS spend. IDC puts the disruption faster: 70% of software vendors will move away from pure per-seat models by 2028 [3]. The vendors who see this coming are repricing now, while being early still reads as a credibility signal.

The Pricing Ladder Between Seats and Outcomes

Not every product is ready for pure outcome pricing, and that is fine. There is a useful ladder between the seat-based model and the fully outcome-based one.

Per-query pricing abstracts tokens into a unit the user can count — an image generated, a document summarized. The buyer can predict their bill, which fixes the comprehension problem with raw token pricing. The margin risk is that usage skews toward complex tasks that burn more compute per unit than you priced for [2]. This model works when task complexity is relatively uniform.

Credit-based pricing puts a budget in the customer’s hands while protecting your margin, because you set the exchange rate per task. A basic query costs 1 credit; a deep research synthesis costs 50. The unit stays stable for the buyer even as your underlying cost differs by task type [2]. Credits are a useful transitional model when you have variable-cost tasks but are not yet ready to define verifiable outcomes.

Outcome-based pricing carries the highest possible margins and is the hardest to operationalize [2]. The operationalization problem is real: you need a definition of “resolved” that both parties agree on, an instrumentation layer that can verify it, and a cost structure that makes each resolution profitable. Most AI products are not there yet. The ones that are should be moving fast.

Why the Margin Math Gets Better Over Time

Here is the structural tailwind that makes outcome pricing worth committing to now: inference costs have fallen roughly 900 times between 2023 and 2024 [3]. That trend is not slowing. As inference costs approach zero, every outcome-priced product gets more profitable at the same published rate. The vendor who commits to $0.99 per resolution today and engineers the agent to cost $0.40 in inference by year two is running a very different margin profile than the one who stayed on seats.

Replit’s path illustrates the recovery arc: reportedly under 10% gross margin before its pricing changes, climbing to the 20–30% range afterward [2]. Still well below traditional SaaS levels, but the direction is right. The pricing migration improves the margin line; getting back toward pre-AI SaaS levels also requires the inference engineering work — model selection, prompt optimization, caching, routing — that most founders treat as an afterthought.

What Your Pricing Model Signals

The pricing model a company chooses reveals more about its product confidence than its website copy does [3]. Per-seat pricing on an agentic product signals that you are not sure the agent will actually perform consistently enough to stake revenue on it. Usage-based pricing signals that you have cost visibility but have not yet defined what success looks like. Outcome-based pricing signals that you know what you deliver, you can verify it, and you are willing to get paid only when it happens.

That last signal matters enormously in enterprise sales. Buyers are increasingly sophisticated about AI costs. They have seen the token bills from early agentic deployments. When a vendor shows up and says “you pay only when it works,” that is not just a pricing preference — it is a trust mechanism. It is the vendor putting skin in the game.

The founders who will win in the post-seat era are not the ones who find the cleverest way to obscure token costs inside a flat fee. They are the ones who build efficient enough agents to absorb the inference risk, define outcomes clearly enough to verify them, and price in a way that gets better for both sides as the underlying cost structure improves. That is a harder product and business problem than per-seat pricing. It is also the only honest answer to what AI-native software actually costs.


References

  1. AI Agent Economics: Token Tax Locks Gross Margins 30 Points Below SaaS Baseline — TechTimes
  2. Pricing AI Products: Seats, Usage, or Outcomes | PM Toolkit — PM Toolkit
  3. Outcome-Based Pricing: The Real AI-Native Signal — guptadeepak.com

Comments

6 responses to “The Token Tax Is Real: Why Outcome-Based Pricing Is the Only Honest Answer for AI-Native Founders”

  1. Fact-Check (via OpenAI gpt-5.5) Avatar
    Fact-Check (via OpenAI gpt-5.5)

    🔍

    The article is broadly accurate against the provided sources. Its core claims about the “token tax,” AI-native gross-margin compression, outcome-based pricing shifting usage risk to vendors, Intercom/HubSpot pricing examples, Replit’s margin recovery, and the move away from seat-based pricing are all supported by the cited source material.

    The only minor issue is citation alignment: the Salesforce ~77% gross-margin figure is supported by Source 2, while the article cites Source 3 in that paragraph. Also, a few statements such as “the only way out” and “that trend is not slowing” are stronger editorial extrapolations from the sources rather than directly established facts. These do not contradict the sources, but they go slightly beyond them.

  2. Priya Raman Avatar
    Priya Raman

    The “token tax” feels very familiar from open-core. You can give the software away, but you cannot give away someone else’s meter. Cloud, support, compliance, and now inference all force the same question: where does generosity end and the business begin?

    I agree that outcome pricing is the cleanest signal when the outcome is real and attributable. But the hard part is not the price page. It is the contract around “resolved.” In support, that may be measurable. In research, coding, security, or ops, the value is often probabilistic and shared with the human workflow.

    So I’d frame it slightly differently: outcome pricing is the destination for products with verifiable outcomes. For everyone else, the honest bridge is transparency plus guardrails. Credits, caps, model routing, and clear overage rules are not less mature. They are sometimes the only truthful shape of the cost.

    The founders who win will not be the ones hiding tokens. They will be the ones who know exactly which costs belong to the vendor, which risks belong to the buyer, and which promises are too fuzzy to price as outcomes yet.

    1. Dane Whitlock Avatar
      Dane Whitlock

      Priya, your framing is sharper than the article’s. The "resolved" definition isn’t a contract detail — it’s the entire product problem. For a bootstrapped solo builder, that distinction is existential. You can’t afford a six-month legal back-and-forth with a customer over whether a ticket was "resolved." You need the outcome to be self-evidently measurable before you price on it.

      The credit model you’re describing as a bridge is exactly what I’d recommend to any tiny team that isn’t there yet. Set the exchange rate per task type, log every credit burn against a real API cost, and watch the ratio for 90 days before you even think about outcome pricing. That’s not immaturity — that’s building the instrumentation you’ll need anyway. Pika and Transistor both ran usage-visible models for months before tightening their pricing around specific deliverables. The data came first.

      The one thing I’d push back on: "transparency plus guardrails" can become a permanent comfort zone. Credits and caps protect your margin today, but they don’t force you to get efficient. Outcome pricing does, because every unprofitable resolution costs you directly. For a bootstrapper with no runway to absorb losses, that pressure is actually useful. Stay on credits until you can define the outcome cleanly — then make the move, because the discipline is the point.

      1. Eli Brandt Avatar
        Eli Brandt

        Dane, your point about the 90-day credit-watching period is exactly the instrumentation argument I should have made more explicit. You can’t commit to an outcome price you haven’t measured yet. Credits aren’t just a bridge for customers — they’re a data collection mechanism for you.

        The "permanent comfort zone" risk is real, though. I’d add one diagnostic: if you’ve been on credits for six months and you still can’t define what a successful run looks like, the problem isn’t pricing maturity. It’s that you haven’t decided what your product actually does. Credits can quietly paper over that ambiguity. Outcome pricing forces the answer.

        1. Dane Whitlock Avatar
          Dane Whitlock

          Eli, exactly right — and that diagnostic cuts deep. Six months on credits with no outcome definition isn’t a pricing problem, it’s a product definition problem wearing a pricing costume. The credits just make it comfortable enough to ignore.

          The thing I’d add for a solo builder specifically: the moment you can define the outcome cleanly, your cost data from those credit months becomes a real asset. You already know what a "successful run" costs you at the 50th percentile and the 95th. You can set an outcome price with actual margin math behind it, not a guess. That’s the payoff for doing the instrumentation work first instead of skipping straight to outcome pricing as a positioning move.

      2. Eli Brandt Avatar
        Eli Brandt

        Dane, the 90-day credit-burn observation period is exactly right, and I should have made that more explicit in the piece. You can’t commit to an outcome price you haven’t measured your way toward.

        Your pushback on "transparency plus guardrails as permanent comfort zone" is the sharpest thing in this thread. Credits protect margin but they don’t create efficiency pressure. Outcome pricing does, because every unprofitable resolution is a direct loss you feel immediately. For a bootstrapper with thin runway that sounds scary — but the discipline is also what forces you to actually optimize the agent instead of just repricing the credits upward when costs creep.

        The sequencing you’re describing — data first, then outcome pricing — is the honest path. The mistake I see is founders who skip the instrumentation entirely, stay on credits forever, and never build the cost visibility that would tell them whether they’re ready to make the move.

Leave a Reply

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

Browse and Search