You have an AI feature that customers want, but its unit economics do not work. Engineering expects inference to become cheaper, finance refuses to fund a hope, and the roadmap decision is due now. The mistake is treating either today’s price or tomorrow’s discount as certain.
AI capability prices have been falling at an estimated 13x year over year. That rate is important enough to change product planning, but it is not a guarantee that every model, workload, or vendor bill will follow the same path. I would use it as a sensitivity case: a way to find decisions that remain sound across very different cost futures.
Treat the cost curve as a product input, not a vendor discount
Most product plans freeze AI cost at its current level. A feature is declared viable or unviable, and that conclusion quietly survives long after the underlying economics have changed. When the input price can move this quickly, that static decision process produces two errors: rejecting valuable products too early and approving weak products because lower costs are expected to rescue them later.
The practical response is to classify every cost-sensitive opportunity by what must change before it works:
- Viable now: The product clears its quality, reliability, and contribution requirements at current prices.
- Viable on the cost curve: The experience already works, but model expense prevents a sustainable launch. Test what happens if only the model-cost line falls to one-thirteenth of its current level.
- Blocked by product quality: The model is affordable, but users do not consistently accept the result. Cheaper failures are still failures.
- Blocked outside the model: Human review, retrieval, integrations, support, or another operating cost dominates. A decline in inference prices will not remove that bottleneck.
- Structurally weak: Even aggressive cost compression does not create enough customer value or margin. Remove it from the roadmap instead of waiting for another model release.
This classification separates an economic constraint from a product constraint. It also tells you what to do next. A cost-blocked feature may deserve a thin prototype and production instrumentation. A quality-blocked feature needs better evaluations, context, or interaction design. A structurally weak feature needs neither.
Do not assume that falling prices will appear as savings in the budget. Teams often spend the headroom on more context, more attempts, stronger models, broader availability, or background automation. That can be a good trade, but it is product investment rather than automatic margin expansion. Name the intended use of the savings before the savings arrive.
Measure cost per accepted outcome, not cost per token
A lower token price is not a product outcome. The useful unit is the cost of producing something that meets a defined acceptance standard: a support issue resolved without an incorrect action, a draft the user keeps, a record processed correctly, or a workflow completed without manual recovery.
A workable unit-economics model is:
Cost per accepted outcome = model inference + tool calls + retrieval + safety checks + human review + variable infrastructure, divided by accepted outcomes.
That denominator matters. If a workflow retries, falls back to another model, gets abandoned, or requires a person to repair the result, its true cost is higher than the successful final call suggests. Measure the whole execution path.
For each production trace, capture enough information to reconstruct that path:
- The product workflow and customer segment.
- The model and model version used at each step.
- Input and output consumption, retries, fallbacks, and tool invocations.
- Retrieval, infrastructure, and third-party charges attributable to the run.
- Latency and whether the user abandoned or repeated the task.
- The evaluation result or other acceptance signal.
- Whether a person reviewed, corrected, escalated, or completed the work.
Do not call a workflow successful merely because the model returned an answer. Define acceptance before launch, then use the same definition in your evaluations, analytics, and financial model. Otherwise, a team can improve its apparent unit cost simply by tolerating worse outputs.
Build several views from the same data. The baseline uses current behavior and current prices. The cost-curve view divides only model expense by 13 while leaving other costs unchanged. The expansion view also includes the additional demand, background runs, and retries that lower prices may encourage. The quality view spends some or all of the savings on a stronger model, more context, or additional verification.
If current total variable cost is model cost plus everything else, the cost-curve scenario is model cost divided by 13, plus everything else. Dividing the entire cost base by 13 will materially overstate the improvement whenever human work, tools, or infrastructure remain significant.
Sequence the roadmap around evidence and option value
Waiting for cheaper inference sounds prudent, but waiting without learning produces no advantage. By the time the price becomes attractive, competitors may understand the workflow, evaluation criteria, and distribution channel better than you do. The better move is to buy information now without committing to full-scale economics.
Create a decision card for each AI opportunity with these fields:
- Accepted outcome: The observable result that counts as useful.
- Quality gate: The evaluation the product must pass before broader exposure.
- Cost ceiling: The maximum variable cost that the business model can support per accepted outcome.
- Current economics: The measured cost across the full execution path.
- Cost-curve economics: The same calculation after reducing only model expense.
- Dominant constraint: Quality, model cost, human operations, latency, integration work, demand, or risk.
- Reversible next step: The smallest experiment that reduces uncertainty without creating a hard dependency.
Then sequence work according to the constraint. If quality and economics already work, launch with cost observability. If quality works but cost does not, validate demand, collect evaluation cases, and keep the integration narrow enough to benefit from future model substitution. If quality does not work, improve the workflow before optimizing price. If human review dominates, redesign exception handling and escalation rather than negotiating token rates.
This approach preserves option value. You can learn the customer’s language, establish an evaluation set, secure the required data access, and test interaction patterns before high-volume deployment. Those assets remain useful if the preferred vendor, model, or price changes.
Revisit previously rejected opportunities whenever the economics materially change. Do not simply reopen the old business case. Recalculate demand as well. A capability that becomes cheap enough to run continuously may need a different interface, permission model, notification policy, and support plan than one invoked deliberately by a user.
Change packaging before lower prices change customer behavior
Lower unit prices do not guarantee a lower bill. When a feature becomes easier to include, customers may invoke it more often, teams may place it inside automated workflows, and the product may begin running it in the background. Usage can rise faster than price falls.
That makes packaging a product architecture decision, not a late finance exercise. Define four things before expanding access:
- The entitlement: What the customer receives with the plan and where additional usage begins.
- The customer-facing value metric: A unit the buyer understands, such as a completed workflow or processed item, rather than an internal model primitive that has little connection to value.
- The internal cost meter: The actual calls, consumption, tools, retries, and human work that drive variable expense.
- The guardrails: Controls for accidental loops, abusive workloads, unexpected automation, and workloads whose cost or risk differs sharply from ordinary use.
The customer-facing metric and internal meter do not have to be identical. They do have to reconcile. If customers buy completed workflows while one workflow can trigger radically different internal workloads, the product needs routing rules, limits, or differentiated packaging to prevent invisible margin leakage.
Avoid pure cost-plus pricing. If your price mechanically follows today’s inference bill, rapid input-cost declines can force unnecessary repricing and make the product look interchangeable. Price against the customer outcome and use the cost model as a viability constraint. The relevant calculation is contribution per account after AI expense, other variable costs, and any human operations required to deliver the promise.
Also avoid promising unlimited usage merely because the current average looks inexpensive. The average can hide a small group of automated or unusually complex workloads. Test the expansion scenario first, make abnormal consumption visible, and give customers a clear path when they need more capacity.
When prices fall, decide deliberately where the headroom goes. You can improve contribution, lower the customer price, include more usage, increase output quality, or fund new capabilities. Each choice supports a different strategy. Letting the savings disappear into unmeasured consumption supports none.
Build advantage where the cost curve cannot give it away
When access to useful model capability becomes cheaper, model-only features become easier to imitate. The model still matters, but durable advantage moves toward the parts of the system that a falling API price does not automatically provide.
- Workflow position: The product sits where the work begins, where decisions are made, or where actions are completed.
- Permissioned context: The system can use relevant customer data with appropriate access controls, provenance, and governance.
- Action reliability: Tools, permissions, approvals, and recovery paths make it safe to move beyond generating text.
- Evaluation capability: The team can tell whether a change improved the customer outcome before exposing it broadly.
- Distribution: The product already reaches the people who have the problem and can introduce the capability inside their existing workflow.
- Learning speed: Production feedback becomes better prompts, routing, interfaces, policies, and evaluation cases without depending on one model vendor.
This should also shape build-versus-buy decisions. Commodity model access is a weak place to recreate infrastructure without a differentiating reason. Your evaluation system, workflow orchestration, customer context, safety controls, and user experience are more likely to encode product-specific judgment. Keep the boundary between those layers clear enough that you can compare models and adopt better economics without rebuilding the product.
Portability does not require supporting every provider. It requires knowing where the dependency lives. Record cost, latency, evaluation performance, and failure behavior by model version. Put model selection behind a deliberate decision boundary. Review commercial commitments against the falling-cost scenario before locking a cost-sensitive roadmap to one pricing structure.
Key takeaways
- Use the 13x decline as a sensitivity case, not a guaranteed budget forecast.
- Measure cost per accepted customer outcome across the full workflow, including retries, tools, and human intervention.
- Reduce only the model-cost line in a cost-curve scenario; the rest of the operating cost does not disappear with it.
- Fund reversible learning for cost-blocked opportunities, but do not expect cheaper inference to repair weak quality or weak demand.
- Price around customer value while keeping an internal meter and explicit usage guardrails.
- Place long-term advantage in workflow, context, reliability, evaluations, distribution, and learning speed.
At your next roadmap review, take the most promising AI feature currently labeled too expensive. Define its accepted outcome, reconstruct its full variable cost, and rerun the economics with the model line divided by 13. You will know whether to ship, learn, redesign, or stop waiting. That is a more durable decision than betting the roadmap on either today’s invoice or tomorrow’s price.
References
