What AI usage brakes mean for your SaaS plan

A pricing consultant told SaaStr that AI products have a cost problem flat plans hide: a small group of heavy users can run up most of the bill. His first fix is often not a price increase. It is a set of brakes, limits that slow the product at a threshold and are moved in slowly, starting at a level that touches 0.01% of users. According to SaaStr, by the time around 4% of users are affected, a company might have addressed 60-80% of its cost problem. If your AI tool says unlimited on the plan page, that mechanism decides whether your plan quietly changes.

The background you need

The consultant is Ulrik Lehrskov-Schmidt, founder and CEO of Willingness to Pay. According to SaaStr, he has worked on pricing full time for about ten years, and his team has run hundreds of pricing projects. He walked through his model with Amelia at SaaStr, using Higgsfield, Figma, and Clay as examples. A few terms make his argument easier to follow.

Gross margin is the share of revenue a company keeps after paying what it costs to deliver the product. Classic software has had high margins because serving one more customer costs very little. Ulrik says he has seen client margins drop from 85-90% to 55% as AI features arrive.

Inference is the work an AI model does each time it answers a request. The vendor pays for that compute, usually measured in tokens, small chunks of text or data. So unlike a classic app, every click on an AI feature costs the vendor something. Heavy use is no longer nearly free to serve.

A power law is a distribution where a few cases at the top account for most of the total. SaaStr reports that Willingness to Pay sees this in customer value: the top 20% of customers get 80% of the value, the top 20% of that group get 80% of their share, and so on. One customer can get 1,000x the value another gets.

The double hockey stick is Ulrik’s name for two curves side by side: value per customer and cost per customer. Each can be flat or spiky. A spiky curve looks like a hockey stick, flat for most users and then rising steeply at the top. His point is that these two curves are independent. A heavy user might create huge value, or might burn tokens on work that is worth very little. He also says the ratio between them shifts as model capabilities improve, model prices move, and customers find new uses. He calls this “the sticks dance”.

Why did flat pricing work before? Per SaaStr, every customer cost about the same to serve, so the extra value top customers got was missed revenue that never showed up as a loss. AI changes that. SaaStr reports one client whose least profitable customer was spending 380x more in tokens than it paid in revenue.

A useful analogy is an all-you-can-eat buffet. A flat price works because most diners eat a normal amount. The analogy breaks in one place. A diner has a stomach. An automated script or AI agent does not, so one account can consume without a natural limit.

Fair usage limits are the vendor’s answer: rules that cap or slow consumption. Ulrik breaks them into a kill point, the usage level where the product stops, and brakes, which reduce utility at a threshold, such as halving speed after a set number of edits a minute, capping concurrent sessions, or adding a short wait before the next job starts.

Credits are prepaid units you spend on actions. MCP (Model Context Protocol) is a standard that lets AI assistants and agents connect to a product’s data and actions, either read-only or with write access.

What actually changed

This is not a single vendor announcing new prices. What is new is a framework Ulrik says he arrived at in April, plus his account of how specific companies have handled AI costs.

His brake playbook, as SaaStr describes it, has five steps. Segment users, so new users get more headroom in their first month and fraudulent users are handled separately. Set a kill point for each segment. Set one or more brakes. Decide how users hear about it, by email, in-product message, or a notice through the MCP. Then move the brake in slowly. The first brake sits at the kill point and might touch 0.01% of users, then moves to 0.1%. Once the cost problem is largely handled, a second, stronger brake goes in behind the first until margins reach the target.

He calls the slow approach boiling the frog. According to SaaStr, his team has worked with companies that recovered up to 22 points of gross margin within weeks, using throttles that affected a few percent of users and no new pricing.

The company examples show what came after limits:

• Figma built fair usage limits before launching AI for everyone. After launch, it turned on credit counting, then enforcement, then monetization, in that order. By Ulrik’s account, gross margins fell from 92% to 82%, but revenue grew faster than costs.
• Clay added action credits as a second credit pool alongside its data credits. Its heaviest users now pay several times what they paid before. Ulrik’s reading of Clay’s pricing memo is that cost was a factor but not the main one; capturing more value was.
• Higgsfield showed tiers at $19, $49, and $99 a few days before the session, with several features listed as unlimited. Ulrik said he did not know whether it has fair usage limits today, and that it should if it does not.

What it means for you

If you are a typical user, brakes are designed to miss you. The first ones touch a tiny fraction of accounts, and SaaStr describes the goal as charging a broad base flat prices while controlling what the heaviest users cost.

If you are a heavy user, especially one running automations or agents, you are the target. Ulrik says users who hit a brake do one of four things: keep going, use less, churn, or upgrade. Vendors track that mix to decide whether to tighten further. Your reaction is data they act on.

The Figma and Clay examples point to a second effect. Ulrik says established B2B companies often add pricing meant to cover AI costs and end up charging for value customers were already getting for free. If your heavy use delivers real value to you, some vendors will try to price closer to it.

On agents, Ulrik says pricing them like human seats does not hold up, because one agent can run vastly more activity than another. He argues for pricing on what agents do. If you plan to run agents against a tool, expect usage-based terms.

On MCP, he described one former client launching read-only access now, with write access in about six weeks, worried it would cannibalize add-ons it sells. He frames the first phase as an experiment the company pays for, with monetization after it learns what customers use. That is one company’s plan, not a general rule.

What we don’t know yet

• Which vendors use brakes, and where. Thresholds are rarely published. SaaStr does not say whether Higgsfield has limits; Ulrik did not know.
• How the headline figure fits the text. SaaStr’s title says 1% of users drive 75% of AI costs. The text refers to a list of cases that is not in the published article, then says the last case means 1,000 people in a 1-million-user product generate three quarters of the bill, which is 0.1%. The two figures do not match, and the article does not explain the difference.
• How general the numbers are. The 4% and 60-80% figures are framed as what a company might achieve. The 22-point recovery comes from his team’s clients.
• How MCP access will be priced once vendors finish experimenting.