Quick answerPrice a deliberately capped capability as its own tier with its own name, not as a discount off the uncapped version, and document the specific competitive, liability, or regulatory reason for the cap in an internal decision record before it ships, since that reason determines how the cap should be reviewed later and who has authority to lift it. Govern the decision to cap as a standing policy owned by legal or product leadership, revisited on a fixed schedule tied to whatever regulatory or competitive condition justified it in the first place, not left as a one-time engineering choice that nobody revisits once the underlying model becomes more capable.
This is an upfront decision, not a routing decision made per request
How to decide which AI agent conversations get routed to a cheaper model covers a runtime decision made per conversation turn: given the models you support, which one should handle this specific request, purely a cost-quality tradeoff with no other agenda. A deliberate capability cap is different in kind: a decision, usually made once and reviewed periodically, to keep the agent from doing something it is technically capable of doing, for reasons that have nothing to do with cost or per-request quality, competitive positioning, legal exposure, or a regulatory requirement that has not caught up with what the model can actually do.
Name and price the capped tier as its own thing, not a discount
Pricing a deliberately capped capability as simply 'the cheaper version' invites customers to treat the cap as a removable limitation they can pay their way past, which creates pressure to lift it for the wrong reasons, a large account complaining, rather than the reason it was set in the first place. Give the capped tier its own name and its own value proposition independent of the uncapped alternative, so the pricing conversation is about what the tier does provide, not framed entirely around what it deliberately withholds.
Document the specific reason before the cap ships, not after someone asks
A competitive-positioning cap, a liability cap, and a regulatory-readiness cap each need to be revisited under different triggers and by different people. A competitive cap might get revisited when a competitor ships the withheld capability first; a liability cap when your insurance or legal posture changes; a regulatory cap when the relevant rule is finalized or clarified. Write the specific reason down in an internal decision record at the time the cap ships, not reconstructed later from institutional memory when someone finally asks why the limitation exists at all.
Assign ownership and a review cadence tied to the actual reason
A capability cap set for regulatory caution should be reviewed against the regulatory calendar, not on the same generic annual cycle as a cap set for competitive reasons. Put legal in the review loop for regulatory and liability-driven caps, and product leadership for competitive ones, and set the review trigger to the condition that actually justified the cap, not a fixed date chosen for convenience. This is deliberately a different threshold than what counts as a material change requiring compliance sign-off, which governs reviewing a change once it happens; capping a capability upfront is the decision that happens before any change is on the table at all.
Watch for the cap becoming stale as the underlying model improves
The competitive or liability reasoning behind a cap made against last year's model capabilities can quietly become outdated as the underlying model, or your own confidence in monitoring it, improves. Build the review cadence to explicitly ask whether the original reason still holds given the current state of the model and the market, not just whether the cap is still technically in place, since a cap can survive years past the point its original justification expired simply because nobody was assigned to ask. This is a different trigger than what happens when a customer's usage outgrows their AI agent pricing plan, which is about volume against a plan limit rather than the capability ceiling itself.
FAQ
Is a capability cap the same as cost-quality model routing?
No. Routing is a per-request runtime decision based on cost and quality. A capability cap is an upfront, usually company-wide decision to withhold a capability for competitive, liability, or regulatory reasons unrelated to per-request cost.
Should a capped tier be priced as a discount off the full version?
No. Price and name it as its own tier with its own value proposition, so customers are not implicitly invited to treat the cap as something to negotiate away.
Who should own the decision to lift a capability cap later?
Whoever owns the reason the cap was set, legal for regulatory or liability-driven caps, product leadership for competitive ones, reviewed against the condition that justified the cap, not a generic fixed date.