Six pricing models compete for AI project budgets in 2026. They are not equally well-suited to AI work, and the difference between the worst and the best is roughly a 4x outcome multiplier on the same dollar of spend. Per-seat licensing; the most common model; is structurally the worst fit for AI because it has no usage signal. Outcome-based pricing; the rarest model; is the best fit because it forces buyer and vendor onto the same axis. The four models in between rank by how strongly they tie payment to either usage or quality. This piece ranks many six, names when each works and when each fails, and assigns a gameability score per model.
It is a spoke under the AI project economics manifesto, which argues that AI economics has shifted from feature cost to evaluation cost; and pricing models that do not encode that shift produce predictable misalignment between vendor incentive and buyer outcome.
The ranking criteria
Each model is ranked against three criteria: usage signal (does payment scale with how much the system is used), quality signal (does payment scale with how well the system performs), and gameability (can the vendor optimize for getting paid in a way that diverges from buyer outcome).
A pricing model that scores well on usage signal aligns vendor incentive with the buyer’s underlying demand. A model that scores well on quality signal aligns vendor incentive with the buyer’s eval bar. A model that scores well on gameability resistance aligns vendor incentive with what the buyer values, rather than what the contract measures.
The worst-fit pricing models in 2026 are the ones inherited from the deterministic-software era, where usage was bounded by seats and quality was a function of whether the build compiled. AI systems are usage-elastic and quality-stochastic, and pricing models that do not reflect both produce predictable misalignment.
The full ranking, worst to best:
| Rank | Model | Usage signal | Quality signal | Gameability |
|---|---|---|---|---|
| 6 | Per-seat license | None | None | Low; but only because there’s nothing to game |
| 5 | Fixed-price | None | None | Medium; vendor optimizes for scope-cut |
| 4 | T&M with cap | Weak | None | Medium; vendor optimizes for hours |
| 3 | Milestone payment | None | Weak | High; vendor optimizes for milestone definition |
| 2 | Eval-threshold billing | Medium | Strong | Low; eval bar is the protection |
| 1 | Outcome-based fees | Strong | Strong | Low; when outcomes are well-defined |
Detail on each.
#6 Per-seat license; worst fit
The model. Buyer pays a fixed monthly fee per user with access to the system. Common in B2B SaaS; common in 2018-vintage enterprise software contracts; common in vendor-led AI product launches where the AI is wrapped around an existing seat-based product.
Why it scores worst for AI. Per-seat pricing has zero usage signal and zero quality signal. A buyer paying $80 per seat per month is paying the same amount whether the user runs 10,000 prompts per month or zero. The vendor is paying the inference cost on the heavy users and capturing pure margin on the light users. Both sides are misaligned with the underlying economics. The vendor wants light users (high margin); the buyer wants heavy users (high value). The contract optimizes for neither.
When it works. When AI usage per user is predictable and bounded; for example, an AI feature inside an existing seat-based product where the per-user cost variance is small. When the AI is a feature inside a product that was already seat-priced. When the buyer is comfortable subsidizing light users to fund heavy users (a “company average” pricing posture).
When it fails. When usage variance is high. When the AI workload is the dominant cost line. When the buyer wants to scale usage rapidly. When the vendor’s economics depend on inference volume that does not scale with seat count.
Gameability score: low; but only because there is nothing meaningful to game. The contract is dumb in a way that benefits the vendor when seats are sold but does not align with outcome.
#5 Fixed-price; rigid
The model. Buyer pays a fixed total fee for a defined scope of work. Common in the legacy enterprise software template; common in vendor RFP responses against fixed-budget RFPs; common in projects where the buyer’s procurement department prefers predictable spend.
Why it scores below T&M for AI. Fixed-price has no usage signal and no quality signal. Worse, it actively penalizes scope changes that AI projects routinely require; model upgrades, prompt revisions, eval-bar adjustments. Detailed in the decline of the fixed-price AI project. The vendor is incentivized to deliver the minimum scope that meets the contract, rather than the scope that meets the buyer’s outcome.
When it works. Narrow, well-bounded engagements where the deliverable is a discrete artifact (a finetuned model, a documented prompt library, a one-shot integration) and the eval bar is locked at signing. Engagements where the buyer is buying capacity rather than ongoing capability.
When it fails. Anything spanning a model release cycle (so anything longer than 3 to 4 months in 2026). Anything where the eval bar evolves. Anything where the system is going into production and will need ongoing operational support.
Gameability score: medium. Vendors optimize for scope-cut. The buyer asks for a feature that was implicit but not literal in the SOW; the vendor pushes back. The cost is a recurring negotiation rather than a delivery.
#4 Time and materials with cap; flexible but no quality signal
The model. Buyer pays for engineering time at a billable rate, with a contractual cap on total spend. Common in agency engagements; common in projects where the buyer wants flexibility on scope but predictability on total exposure.
Why it scores above fixed-price. T&M provides a weak usage signal; the more engineering hours, the more spend. It is honest about scope evolving, which AI projects do. It does not penalize the vendor for picking up scope that emerges during the engagement.
Why it scores below milestone payment. T&M has no quality signal. The vendor is paid for hours regardless of whether those hours produce a system that meets the eval bar. A vendor optimizing for revenue under T&M is incentivized to staff senior people on the engagement (higher rates) and to take longer to ship (more hours). Both cut against buyer outcome.
When it works. Trusted vendor relationships where the buyer has confidence the vendor will not optimize for hours over outcome. Engagements with strong buyer-side oversight (a competent technical product owner reading hours weekly). Discovery-phase engagements where the scope is genuinely undefined.
When it fails. Vendor-buyer relationships without trust. Engagements where the buyer cannot evaluate hours-spent against value-delivered. Long engagements where hours accumulate faster than outcomes.
Gameability score: medium. The cap protects against the worst outcome (unbounded spend). The hourly billing is honest. The lack of quality signal is the gap.
#3 Milestone payment; gameable
The model. Buyer pays in tranches as the vendor delivers milestones; a kickoff payment, a mid-project payment, a launch payment, a post-launch acceptance payment. Common in agency engagements; common in fixed-price hybrids that try to retain some flexibility.
Why it scores above T&M. Milestone payment has a weak quality signal; milestones are defined as deliverables, and deliverables imply a quality bar. It is more aligned with outcome than pure hours-billed.
Why it scores below eval-threshold billing. Milestone definitions are gameable. “Eval suite running” is not the same as “eval suite passing the locked threshold.” “System deployed to production” is not the same as “system in production handling 10x peak traffic without regressions.” Vendors writing the milestone definitions optimize for milestones that are easy to hit; buyers reading the milestone definitions often miss the gap until acceptance testing surfaces it.
When it works. When milestone definitions are tied to specific, measurable, externally-verifiable artifacts. When the buyer’s technical team has authored or reviewed each milestone definition. When the contract includes an acceptance gate at each milestone with the right to withhold payment for non-acceptance.
When it fails. When milestone definitions are vendor-authored without buyer-side technical review. When acceptance is a paperwork formality. When milestones are time-based (“week 8 milestone payment”) rather than artifact-based.
Gameability score: high. This is where the gameability concern is largest. The vendor controls milestone definition; the buyer controls acceptance; the gap between literal definition and buyer outcome is where games happen.
#2 Eval-threshold billing; good
The model. Vendor is paid when the AI system passes a locked eval threshold on a buyer-readable test set, scored by a buyer-shared rubric, on a CI-integrated eval harness. Detailed in stop budgeting AI projects in story points, budget them in eval runs and stop scoping AI projects in features, scope them in evaluations.
Why it scores second-best. Eval-threshold billing has a strong quality signal; the eval bar is exactly the buyer’s quality outcome. It has a medium usage signal indirectly: an eval suite run against a representative production workload encodes the usage profile. It is hard to game because the eval threshold is the protection; gaming it requires gaming the eval suite, which the buyer co-owns.
When it works. When the eval suite is buyer-readable from kickoff. When the rubric is co-owned. When the threshold is contractually locked. When the vendor and buyer are aligned on the eval discipline as the primary quality measure.
When it fails. When the buyer cannot co-author the eval suite (lacks domain expertise or engineering capacity). When the eval threshold is too easy and gets hit early without producing real value. When the eval suite is gameable through overfitting to known test cases.
Gameability score: low. The eval bar is the protection. The remaining gameability vector is overfitting to the test set, which a competent buyer-side eval owner catches with held-out evaluation.
#1 Outcome-based fees; best, but rare
The model. Vendor is paid based on a measured business outcome; leads generated, support tickets resolved, fraud prevented, revenue captured, cost saved. The fee scales with the outcome the buyer cares about, rather than with proxies (hours, milestones, evals) for that outcome.
Why it scores best. Outcome-based fees have the strongest possible alignment between vendor incentive and buyer outcome. The vendor wins when the buyer wins. The buyer pays for value delivered, not for inputs. Detailed in the AI cost-per-action framework; the unit economics model that makes outcome-based pricing work.
When it works. When the outcome is measurable, attributable, and not gameable. When the buyer’s revenue or cost-savings model is well-instrumented. When the vendor has enough confidence in the outcome to price against it (rather than the buyer absorbing many risk).
When it fails. When the outcome is hard to measure (most knowledge-work outcomes). When attribution is shared across multiple systems. When the outcome is gameable (vendor optimizes the proxy at the expense of the underlying value). When the buyer cannot afford the upside (outcome-based fees can run higher than fixed-price when outcomes land).
Gameability score: low when outcomes are well-defined; high when they are not. This is why outcome-based pricing is rare; most AI engagements do not have a clean enough outcome metric to safely price against. The engagements that do (lead-gen, fraud-prevention, revenue-share on AI features) tend to use outcome-based pricing; the engagements that do not (custom AI development for internal tooling, AI-augmented operations) fall back to T&M or eval-threshold billing.
How to pick the right model
Not most project belongs at the top of the ranking. The right model is a function of three project factors: outcome measurability, eval discipline maturity, and buyer-side risk tolerance.
Outcome measurability high, eval discipline mature. Use outcome-based fees with an eval-threshold floor. The vendor is paid on outcome, with a minimum eval-pass payment to cover variable cost. This is the structure mature 2026 AI engagements gravitate toward.
Outcome measurability low, eval discipline mature. Use eval-threshold billing. The eval bar is the protection. Most enterprise AI engagements without a clean revenue-share outcome land here.
Outcome measurability low, eval discipline immature. Use T&M with cap, plus an eval-engineering scope clause requiring eval discipline buildout in the first six weeks. Once eval discipline matures, migrate to eval-threshold billing.
Discovery or prototype phase. Use T&M with cap. Discovery is honest about scope being undefined; T&M is honest about hours being the unit.
Per-seat is almost rarely right for AI unless the AI is a feature inside an existing seat-priced product. Buyers offered per-seat pricing for AI work should ask what the assumed usage profile is per seat, and whether the pricing changes when usage exceeds that profile. Buyers should expect either a usage adder or a re-pricing trigger.
Fixed-price is rarely right for AI beyond narrow, well-bounded engagements. Fixed-price for a 12-month AI engagement that spans model release cycles is structurally underpriced or structurally over-scoped. Detailed in the decline of the fixed-price AI project.
The ranking is not absolute. The right pricing model depends on the project’s profile. The general direction; toward stronger usage signal, stronger quality signal, lower gameability; holds across the field. Vendors who price against the strongest signal available win the trust differential. Buyers who insist on the strongest signal available pay the lowest gameability premium.
Frequently asked questions
Why is per-seat pricing the worst fit for AI?
Per-seat pricing has no usage signal and no quality signal. A buyer paying per seat is paying the same amount regardless of whether the user runs 10,000 prompts per month or zero. The vendor’s economics are misaligned with the buyer’s economics; the vendor wants light users (high margin), the buyer wants heavy users (high value). For AI workloads with high usage variance, per-seat pricing produces a recurring re-negotiation when actual usage diverges from assumed usage.
When is fixed-price right for AI work?
Narrow, well-bounded engagements where the deliverable is a discrete artifact and the eval bar is locked at signing. A finetuned model with a documented test set. A prompt-library handoff with a representative scoring rubric. A one-shot integration. Anything longer than 3 to 4 months; anything spanning a model release cycle; is structurally underpriced or over-scoped at fixed-price.
What’s the difference between milestone payment and eval-threshold billing?
Milestone payment is paid when artifacts are delivered. Eval-threshold billing is paid when artifacts perform at a contractually locked level. The gap is the gameability of milestone definitions; “eval suite running” is not the same as “eval suite passing the threshold.” Eval-threshold billing closes the gap by making the threshold itself the milestone, rather than the existence of the artifact.
How do you measure outcomes for outcome-based fees?
Three properties are required: measurable (instrumented), attributable (clean signal from system to outcome), not gameable (the vendor cannot optimize the proxy at the expense of the underlying value). Lead-gen, fraud-prevention, and revenue-capture have many three properties. Knowledge-worker productivity, customer-experience quality, and “general efficiency” do not; outcome-based fees do not work cleanly for those, and projects in those domains usually use eval-threshold billing instead.
Can a project mix multiple pricing models?
Yes; and the most common mature 2026 structure is exactly this. Discovery phase on T&M with cap. Build phase on eval-threshold billing tied to an eval bar locked at the decline of discovery. Maintenance retainer at a hybrid (fixed retainer floor plus eval-bar progression bonuses). Outcome-based shared-savings layer on specific high-attribution use cases. The mix is structurally honest about different phases having different alignment characteristics.
Why is the eval threshold the protection in eval-threshold billing?
Because the eval bar encodes the buyer’s quality outcome. Vendors optimizing for getting paid have to optimize for passing the eval bar, which is exactly what the buyer wants. The remaining gameability vector; overfitting to the test set; is bounded by the buyer co-owning the eval suite and using held-out evaluation. The cost of held-out evaluation is small; the protection is large.
Are outcome-based fees used in practice in 2026?
Yes, but in narrow domains. Lead-generation AI (per-lead fees), fraud-prevention (revenue-share on prevented fraud), customer support deflection (per-deflected-ticket fees), AI-driven sales tools (revenue-share on closed deals). Outside those domains, outcome-based fees are rare because the outcome metric is hard to define cleanly. The ranking puts outcome-based fees first because when they work, alignment is strongest; not because most project should use them.
What about retainers; where do they fit?
Maintenance retainers are typically priced as fixed monthly fees with named scope. They are a hybrid of fixed-price (predictable) and T&M (scope-flexible) with an eval-bar progression clause that adds quality signal. The retainer fits between #5 (fixed-price) and #2 (eval-threshold billing) on the ranking, depending on how aggressively the eval-bar progression clause is enforced. Mature retainers approach eval-threshold billing in alignment.
Key takeaways
- Six pricing models compete for AI project budgets: per-seat, fixed-price, T&M with cap, milestone payment, eval-threshold billing, outcome-based fees. They are not equally well-suited to AI work.
- The ranking is driven by three criteria: usage signal, quality signal, gameability. AI workloads are usage-elastic and quality-stochastic, and pricing models that do not reflect both produce predictable misalignment.
- Per-seat is the worst fit for AI because it has no usage signal. Fixed-price is rigid and penalizes scope changes that AI projects routinely require. T&M with cap is flexible but has no quality signal. Milestone payment is gameable through milestone definition.
- Eval-threshold billing is the second-best model because the eval bar is the protection. Outcome-based fees are the best model when outcomes are measurable, attributable, and not gameable.
- Most mature 2026 engagements mix models by phase: discovery on T&M, build on eval-threshold billing, maintenance on a retainer with eval-bar progression, outcome-based shared-savings layer on specific high-attribution use cases.
The ranking is the design space. The right pricing model for a specific project depends on the project’s profile. The direction; toward stronger usage signal, stronger quality signal, lower gameability; is universal.
Arthur Wandzel
