One slightly uncomfortable data point from inside Airspeed: most of our customers have healthy gross margins, but a small number currently cost us more to serve than they pay us.

We know this because we track inference and related costs customer by customer.

Ben Thompson described the underlying shift in a recent Stratechery post: “COGS is real for AI in a way it hasn’t been for software for a very long time.”

For a long time, software companies could treat the marginal cost of serving another customer as effectively zero. There were hosting and support costs, of course, but they were rarely tightly coupled to how much useful work the product did. Once the software had been built, another user clicking another button was almost free.

AI changes that relationship. Every model call consumes compute. Longer context windows cost more. Reasoning costs more. Agents that run repeatedly or take multiple steps cost more. In a product like Airspeed, which works across calls, CRM data, account history, and live deals, the amount of work can vary substantially from one customer to another.

Revenue and cost can therefore become disconnected. Two customers on similar contracts can generate very different inference bills because their data volumes, workflows, product usage, and agent activity are different.

That makes aggregate gross margin necessary but insufficient. The aggregate number tells us whether the business works. The customer-level distribution tells us what needs to change.

A Negative Margin Is a Diagnostic Signal

It is tempting to look at a loss-making customer and conclude that they are outside the ideal customer profile. That conclusion is too fast.

A customer can have negative gross margin for at least three different reasons.

First, the customer may be receiving a lot of value while our pricing fails to reflect the work the product is doing. This is a pricing problem. Seat-based pricing is simple and predictable, but usage can vary dramatically between customers with similar seat counts. If one customer runs far more workflows, processes much more context, or gets much more value from the system, the same price may no longer make sense.

The answer is not automatically pure consumption pricing. Customers generally value predictability, and we want usage to grow when the product is useful. But the pricing model still needs some relationship to the underlying value and cost. That could mean different packaging, included usage, minimum contract sizes, or a consumption component for unusually intensive workloads.

Second, the workload may be more expensive than it needs to be. This is an engineering problem.

Not every token creates value. An agent may load more context than it needs, call a frontier model for work a smaller model can handle, repeat an analysis that could have been cached, or take too many steps to reach the same outcome. A high cost can be evidence of strong usage, but it can also expose an inefficient architecture.

The engineering goal is not simply to minimize tokens. The goal is to minimize the cost of producing a correct and useful outcome. A cheaper model that requires more attempts, produces worse work, or needs more supervision may be more expensive in practice. The relevant unit is not the token. It is the completed job.

This makes customer-level cost data useful to the product team. It shows which workflows deserve model routing, caching, context reduction, architectural changes, or a closer look at whether the work should run at all. Gross margin becomes another form of observability.

Third, the customer may not receive enough value to justify either the current price or the structural cost of serving them. Only then have we learned something about our ICP.

This distinction matters. Cost alone does not define an ideal customer. An expensive customer with high willingness to pay can be a very good customer. A cheap customer who gets little value may be a poor one. ICP is a relationship among the problem, the value created, the willingness to pay, and the cost of delivering the outcome.

The Outliers Are Where the Learning Is

The overall economics at Airspeed are working. The interesting part of looking customer by customer is seeing the exceptions that an aggregate number can hide.

Each outlier forces a concrete diagnosis:

  • Are we creating enough value but charging the wrong way?
  • Are we doing unnecessary computational work?
  • Is this a workload our product should serve?
  • Is this a customer segment we should pursue again?

Those are pricing, engineering, product, and go-to-market questions emerging from the same underlying data.

Traditional SaaS companies monitored usage primarily to understand adoption and retention. AI companies need to add cost to that picture. A heavily engaged customer may be a success story, a margin problem, or both. A lightly engaged customer may look profitable while actually being at risk of churn. Neither signal is meaningful in isolation.

The useful view combines usage, value, retention, willingness to pay, and cost to serve. Together, they show not only whether a customer is profitable today, but why.

AI is bringing real marginal costs back to software. That creates a constraint, but it also creates a new source of product signal. If we can see the economics of every customer, we can identify whether an exception points to pricing, engineering, or customer fit.

Aggregate gross margin tells us whether the company is working. Customer-level gross margin helps us make it work better.