AI Applications Should Price for Recognizable Work and Outcomes Instead of Tokens

AI Applications Should Price for Recognizable Work and Outcomes Instead of Tokens While token-based pricing suits raw inference at the model layer, using it for AI applications anchors software value to falling compute costs and forces customers to navigate unpredictable technical complexity. Token pricing ties an application's commercial value to falling compute costs and forces buyers to forecast complex infrastructure elements like retries and context length. In a survey of 50 technical AI buyers, 27 preferred credits tied to recognizable work, whereas only 14 favored token-based pricing. Strong credit models price recognizable units of effort rather than acting as a direct token markup, enabling vendors to protect margins and capture efficiency gains. Companies can employ hybrid structures that pass through volatile model costs while metering platform orchestration or directly pricing attributable business outcomes. The Pitfall of Token Pricing in the Application Layer Token metering originated as a practical way to charge for raw compute when model APIs launched. However, AI applications combine proprietary data, tools, orchestration, and workflow logic to deliver finished work. Pricing these products in tokens imports the model provider's cost structure into the customer relationship, anchors price to an asset with falling costs, and trains buyers to treat specialized applications as raw compute. Centering Pricing on Recognizable Units of Work Buyers seeking token pricing usually want comparability or control over budget allocation, but token metrics create friction by requiring finance teams to forecast context length, retrieval volume, and reasoning time. Applications should instead price at the highest reliably measurable layer of value by packaging work into units customers already understand, such as completed account briefs, resolved support conversations, or executed code changes. Using Credit Systems to Protect Gross Margins Unlike traditional software with minimal marginal costs per user, AI applications incur variable costs across inference, retrieval, tool calls, and failed runs. An effective credit system separates the commercial value of a credit pool from the internal cost of delivering each task. This separation prevents fast revenue growth from being eroded by third-party provider costs and allows vendors to retain the margin benefits of model routing, caching, and prompt optimization. Hybrid Models and the Transition to Outcomes When final results are clearly observable and attributable, vendors can price directly on business outcomes, such as booked meetings or processed claims. For more variable environments, hybrid models can combine seats, work credits, and token pass-through for unusually expensive or volatile reasoning models. For instance, Clay adopted a structure that meters orchestration through action credits while passing through unpredictable model token costs without markup.

应用层AI不应按Token计价：建立在可识别工作与结果之上的定价逻辑 随着生成式AI从模型层延伸至复杂应用层，直接套用底层Token计价会将产品价值锚定在不断下降的算力成本上，且让客户难以预测预算。AI企业应当根据客户可理解的价值单元、积分模式或直接按业务结果进行定价，以保障毛利率并体现自身工作流价值。 根据对50位技术AI采购者的调查，27人倾向于与可识别工作绑定的积分机制，仅14人偏好Token计价。 定价原则应位于能够可靠衡量、归因和防御的最高价值层：模型层卖Token，应用层卖可识别工作（积分），明确结果则直接按结果定价。 好的积分体系应抽象底层基建复杂性、体现相对工作量等级，并提供商业灵活性，同时隔离产品价值与交付成本以保护毛利。 Clay在2026年定价备忘录中展示了混合计费模式：区分第三方数据的Data Credits与编排价值的Actions，并对高成本推理模型采用无加价的Token透传。 避免将应用层锚定在不断降价的底层算力 Token定价起源于OpenAI在2020年推出的API，对原始推理按计算量收费是合理的。但AI应用层结合了专有数据、工具编排与业务逻辑，若按Token计价，会迫使客户将应用与裸算力对比，削弱数据和工作流价值，且算力成本不断下降会拉低整体商业价值。采购方虽常要求Token计费以便横向比较或分配预算，但这往往带来虚假的精确度，因为各应用的模型和自动化程度截然不同。企业应向客户提供底层透明度与报表，但无需让计费单元与成本单元完全等同。 以可识别工作为核心的积分机制与毛利保护 处于中间层的应用大多在交付具体工作，如完成的代码修改、账户简报或查询管线。弱积分系统仅将Token机械转译为内部代币，而强积分系统则映射到客户熟知的工作负荷，并依据难度分级收费。AI应用每位新用户都会引发检索、工具调用等边际成本，合理定价需将‘这项工作值多少’与‘交付成本是多少’两个决策分离，使企业能通过提示词优化、模型路由和缓存来留存降本带来的利润红利。 从工作单元走向业务结果定价的演变路径 当产品成效能够被清晰观测、归因并具有足够价值时，计费单元应从积分进一步转向商业结果，例如按成功解决的客服对话、合格销售线索或处理的索赔计费。许多现代AI应用正在采用混合模式：席位费覆盖访问权限、积分包覆盖可变工作量、Token透传应对昂贵不稳定的推理模型，并在归因明确的场景收取成效费，确保不同层级采用相匹配的计费标尺。

[America](https://www.a16z.news/t/america) | [Tech](https://www.a16z.news/t/technology) | [Opinion](https://www.a16z.news/t/opinion) | [Culture](https://www.a16z.news/t/culture) | [Charts](https://www.a16z.news/t/charts) Token pricing began in the right place: the model layer. When OpenAI launched its API in 2020, charging for the computation a model consumed was a sensible way to meter raw inference. However, ChatGPT’s debut two years later helped spark a wave of applications built on that infrastructure that do much more. These new products combine proprietary data, tools, orchestration, integrations, and workflow logic to complete work on a customer’s behalf. When an application prices that work in tokens, it imports the model provider’s cost structure into the relationship with the customer and anchors the product’s value to a unit whose cost keeps falling. Based on our work, it’s often a mistake to carry the model layer’s pricing logic into the application layer. Instead, we believe companies should price at the highest layer of value that they can reliably measure, attribute, and defend. If you sell model access, price tokens. If you turn models into useful work, price the recognizable value unit, often through credits. If you deliver a clear and attributable business result, price the outcome. Getting this wrong is difficult to undo. A token-based price trains customers to compare an application with raw compute. It gives away the value of data, workflow, and orchestration; exposes customers to technical complexity they cannot forecast; and can lock the vendor into weak margins. Credits do not solve that problem on their own if they are merely cost-plus tokens; they still meter infrastructure as opposed to value. Pricing around the recognizable work does the opposite. It makes value legible, spend forecastable, and product improvements economically valuable to both sides. In our survey of 50 technical AI buyers, 27 preferred credits tied to recognizable work, while only 14 preferred tokens. The two ends of the stack are relatively straightforward. Model providers sell inference, which can be metered in tokens. Some applications deliver outcomes that are observable and attributable enough to price directly. The middle is harder. That’s where most AI applications live. For example, an account-research agent is not selling searches and model calls. It is selling a completed account brief. A coding agent is selling an implemented change. A data platform might sell a completed query, pipeline, or agent run. The application’s job is to abstract the complexity beneath that unit of work. Because every category packages value differently, there is no universal AI application metric. Voice AI may begin with minutes, then move toward conversations resolved. Copilots may begin with seats, then add usage-based pricing as agentic work creates greater variation in cost and value. The right question is not, “What is the AI pricing metric?” It is: “**What unit of value does the customer already understand, and can we measure it consistently?”** Customers will still ask about tokens. Usually, they are asking for one of two things: comparability or control. First, buyers want a common benchmark. Tokens appear to let them compare a specialized application with a general-purpose model API or an internal build. But the comparison is usually false precision. Each application combines different models, data, tools, and levels of automation. A token flowing through one product does not produce the same work as a token flowing through another. Second, buyers want to allocate spend. Finance and IT teams need to trace AI spend to a department, project, client, or invoice, often across a growing portfolio of applications. Requiring them to forecast tokens separately for every product recreates the complexity those products are meant to hide. Both needs are reasonable. Nonetheless, token pricing often creates more friction than clarity. A support leader can estimate how many conversations the company handles. It is much harder to predict context length, retrieval volume, retries, reasoning time, or output tokens. What should be a straightforward ROI calculation becomes a separate compute-forecasting exercise for every AI application the company deploys. The better answer is to expose enough underlying usage detail to build trust without turning that usage into the commercial unit. Show customers what work was completed, where capacity went, and why certain tasks consumed more than others. Give finance and IT the reporting they need for budgets and chargebacks. **Transparency does not require the billing meter and the underlying cost meter to be the same.** In highly competitive or technically sophisticated markets, companies may still need to offer token pass-through, particularly for unusually expensive or volatile model usage. But this should be an explicit component of a hybrid model, not the default expression of the product’s value. For the broad middle of the AI stack, credits can be an effective way to package variable work. But a credit is a currency, not a value metric. *What matters is what the credit buys*. A weak credit system converts token counts into an opaque internal currency. It hides the meter without improving it. A strong credit system maps to work the customer recognizes. It might use a few intuitive effort bands: a small bug fix costs less than a multi-file feature; summarizing one contract clause costs less than reviewing the full agreement; enriching one record costs less than running a multi-step account research workflow. The best credit systems do three things: **Abstract infrastructure complexity.** Customers buy the work, not the ingredients. **Explain relative effort.** Simple work consumes a little; standard work consumes a predictable amount; complex work consumes more. **Create commercial flexibility.** One pool can cover several workloads, agents, or automations while procurement manages one contract. The test is comprehension. Buyers usually know their workload before they know their compute load. If customers cannot understand the credit system in a few sentences, it is too complicated. Credits do more than just make usage understandable. Designed well, they also protect your gross margins. In traditional SaaS, an additional user often adds little marginal cost. In AI applications, every user can generate inference, retrieval, search, tool calls, third-party data, media generation, retries, and failed runs. Fast growth can hide a weak business if each new dollar of revenue is quickly paid back to model, cloud, or data providers. The pricing system needs to separate two decisions: **What is the work worth?** Customer value, willingness to pay, and competition determine the price of the credit pool **What does the work cost to deliver?** Relative cost and complexity determine how many credits each task consumes This separation enables the vendor to protect margin while preserving the margin upside from model routing, caching, prompt optimization, better infrastructure, and a more diverse (and changing!) mix of proprietary and open-source models. In fact, if underlying model costs fall, the application may even be able to retain part of the benefit because customers are paying for work, not just reimbursing the company for compute. Clay offers a helpful example and has often been ahead of the curve in how they think about pricing. In a 2026 pricing memo, the company wrote that it had mispriced credits in its Pro segment back in 2022 and operated that segment at a loss for years. Its new model separates Data Credits for third-party data from Actions for orchestration work. Clay keeps fixed pricing for models with predictable costs while passing through the actual token cost of more volatile and expensive reasoning models without a markup. In other words, Clay uses different meters for different layers: Actions for platform value and token pass-through for unpredictable model costs.[1](https://www.a16z.news#footnote-1) Credits are most useful when the product performs valuable work but the final business result is not cleanly attributable. Once the outcome becomes observable, attributable, and valuable enough to support a stable price, the meter should move again. Under those conditions, price the outcome: a resolved support conversation, a qualified lead, a booked meeting, a processed claim, or a recovered dollar. If the results are not attributable enough, price the unit of work through credits. If the customer is buying raw model access, price tokens. Many products will use hybrids: seats for access, credits for variable work, token pass-through for unusually expensive or unpredictable model calls, and outcome fees where attribution is clean. Multiple meters are not the problem, but avoid using the wrong meter for the wrong layer. Token pricing pulls the customer conversation toward a cost curve that keeps falling. This is a poor anchor for a product whose usefulness, reliability, and role in the workflow should keep rising. The better path is to price at the highest layer of value you can reliably measure, attribute, and defend. Translate variable work into understandable units. Use credits to package those units when flexibility matters. Move toward outcomes as soon as customers can recognize and trust them. *This newsletter is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Furthermore, this content is not investment advice, nor is it intended for use by any investors or prospective investors in any a16z funds. This newsletter may link to other websites or contain other information obtained from third-party sources - a16z has not independently verified nor makes any representations about the current or enduring accuracy of such information. If this content includes third-party advertisements, a16z has not reviewed such advertisements and does not endorse any advertising content or related companies contained therein. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z; visit [https://a16z.com/investment-list/](https://a16z.com/investment-list/) for a full list of investments. Other important information can be found at [a16z.com/disclosures](http://a16z.com/disclosures). You’re receiving this newsletter since you opted in earlier; if you would like to opt out of future newsletters you may unsubscribe immediately.* https://www.clay.com/blog/clay-pricing-memo-internal