Why model access is a weak unit of value
When several providers use comparable models, access to an application programming interface (API) alone does little to explain the price. An incumbent software provider can incorporate a similar capability, while a buyer can switch models without changing the underlying task. [1 · Andreessen Horowitz]
a16z’s thesis about systems of record reinforces this problem: a new product is protected by ownership of a workflow, correction data and an outcome that the existing system does not yet deliver, rather than by its interface or chosen model. [1 · Andreessen Horowitz]
How to link price to outcomes
An understandable unit could be correctly processed documents, updated records, prepared claims, prevented errors or hours of verified work. Such pricing is closer to the buyer’s benefit and forces the provider to measure task completion, rather than model calls. [1 · Andreessen Horowitz]
At the initial stage, it is safer to operate in a recommendation mode and separately measure the share of results accepted without corrections. Permission for automatic action should be expanded only after the system demonstrates its error bounds and retains the option of human review. [1 · Andreessen Horowitz]
Sources
- Andreessen Horowitz — The Incumbents Are Coming — September 3, 2026
Expert commentary
Outcome-based pricing is dangerous if the calculation omits reruns, manual review, rare exceptions and integration support. In that case, active usage increases costs faster than revenue. Before launching a pricing plan, the full cost of a successful outcome must be measured, rather than the average cost of a single model call. [1 · Andreessen Horowitz]