
Cheaper AI tasks do not tell you how to price the product
An inference saving is only one input to a product decision. Model usage, paid value and the expensive tail before choosing a bundle, allowance or action price.
Fortune reported that Canva cut its growth forecast while reducing AI cost per task by nearly 90%. The report is here.
I would not turn that combination into proof that infrastructure costs caused the forecast change. I would not turn it into proof that a particular pricing model caused it either. A company-wide outlook and a unit-cost improvement do not isolate the commercial mechanism between them.
The useful question for a product team is closer to home: when the cost of one AI action falls, what happens to the number of actions, the distribution of users and the value customers will pay for?
My rule is to model all three before deciding whether to bundle the feature. Cheaper inference can create room for a better product. It cannot choose the revenue model on our behalf.
The average task hides the expensive customer
A flat subscription can work well when usage and costs are sufficiently predictable relative to the value delivered. It can also expose the supplier to a small group of very intensive users whose costs bear little resemblance to the average.
That is not an argument that every AI action needs a separate price. Metering everything can make a product harder to understand and discourage useful experimentation. A predictable bundle may be exactly what customers want. The business still needs to understand which behavior it is financing.
Imagine a hypothetical feature whose serving cost falls from ten cents to one cent per action. If the same customer performs three times as many actions, that portion of the bill falls from ten cents to three cents for the comparable activity. Cheaper tasks and higher usage can coexist with lower variable expense.
Now change the example. Some customers begin running hundreds of unattended actions, while others barely use the feature. The average saving no longer describes the distribution the subscription must cover. We need to examine the expensive tail and whether those users receive proportionate paid value.
The arithmetic is illustrative. It is not an estimate of Canva’s usage, costs or margins.
Keep revenue, cash flow and unit economics distinct
Figma’s Q2 2026 release reports revenue growth of 48% and a 14% free-cash-flow margin. Those can both be true. Neither number, standing alone, identifies the marginal cost of an AI feature or proves which factor changed the company’s economics.
A company can invest while growing. A feature can become cheaper while the product’s total costs rise. A new plan can improve monetization while temporarily changing cash timing. The statements answer different questions, so I would keep their accounting boundaries visible.
For a product decision, I would start with a narrower record: eligible users, actions attempted, actions successfully completed, serving cost and the customer outcome attached to those actions. Then connect that record to the paid plan and renewal behavior.
That gives us a way to distinguish more consumption from more value. A tool that generates many discarded outputs may be busy without being useful. A tool that completes a small number of consequential tasks may justify a premium despite low token volume.
Compare three offers on the same workload
For a hypothetical design assistant, I would compare a flat bundle, a bundle with a clear allowance and a separately priced outcome or action. Use the same observed workload distribution in all three scenarios rather than changing usage assumptions to favor the preferred offer.
The comparison should show what customers can predict, what the supplier absorbs and what happens when a user reaches the limit. An allowance that unexpectedly blocks an important task may save inference expense while damaging the product’s value. Unlimited usage that cannot be sustainably delivered creates a different failure.
rendering diagram…
I would pay particular attention to the moment usage stops being human-paced. An agent can continue working after the customer leaves the screen. The pricing and budget controls should reflect that operating mode before the feature makes unattended activity easy.
Make the trade legible to the customer
Customers should be able to understand what is included, what is charged separately and what happens when a limit is reached. The explanation belongs in the product at the decision point, not only in a billing document discovered afterward.
For the design example, I would test whether a customer can estimate the cost of completing a typical project. If they cannot, a technically precise token meter may still be a poor product price. Conversely, a simple action price needs a clear definition of a completed action, especially when retries or failures occur.
The decision should be revisited as the workload changes. Falling model prices may justify a larger allowance. Better quality may reduce retries. New autonomous behavior may increase volume. Each can alter the economics without proving the previous pricing philosophy was universally wrong.
A product team should be able to explain which change moved its decision. That is more useful than treating every company’s growth revision as another verdict on the same AI business model.
Price the distribution of useful work, not just the falling cost of an average model call.


