Tier Design

Agent product tiers are fundamentally layered model budgets and task volume caps — four design principles, typical tier structure, overage behavior design.

In traditional SaaS, tiers are combinations of “features + seat count”. Agent product tiers are fundamentally different — the core dimension is model budget and task volume cap; feature differentiation is secondary.

Reason: agent product experience quality is directly tied to which model performs each inference — Haiku is slower / less accurate / lower completion rate on the same task than Opus. A tier is “how much token quota the user receives per month + which model runs by default”. Feature toggles (BUA, MCP, custom subagents) are surface differences.

Four design principles

1. Token caps are hard; dollar caps are soft

Rationale: see economics/controls-and-roi. Token is the stable unit at the product-semantic layer; dollar amounts drift with model pricing. Tier quotas should be specified in tokens; dollar conversion happens at internal accounting.

2. Tiers should jump 4-10× in budget

Tier capacity grows ~7× per step Log-scale visual · equal pixel steps = equal multiplicative jumps · the designed exponential Free 30 tasks/mo ×6.7 Lite 200 tasks/mo ×7.5 Pro 1,500 tasks/mo ×6.7 Ultra 10,000 tasks/mo Enterprise tier (custom) omitted · 5-8× per step is the SaaS empirical sweet spot for tier design

Jumps under 3× feel like “upgrade isn’t worth it”; jumps over 15× leave no intermediate tier between user segments, forcing all-or-nothing decisions. SaaS empirical sweet spot is 5-8×.

TierTypical monthly task rangeJump multiple
Free10-50—
Lite50-3006×
Pro300-2,0007×
Ultra2,000-15,0007×

3. Default model and tier — coupled or decoupled

Two approaches:

Approach A: tier locks the default model — Lite uses Haiku only, Pro defaults to Sonnet, Ultra defaults to Opus.

  • Pro: cost-controllable; prevents Lite users from running Opus tasks and exploding the bill
  • Con: users feel “constrained” — simple tasks still require Pro to access Sonnet

Approach B: tier sets budget, model is user-selectable — any tier can choose any model, but Opus tasks consume token quota faster.

  • Pro: strong user control; high-quality scenarios can opt up temporarily
  • Con: cost accounting is more complex; user education cost is high (need to explain “why did one Opus task consume 5% of my monthly quota”)

Industry trend is migration from A toward B — customers accept “consumption-based” more than “feature-gated”. But B requires the usage UI be sufficiently transparent (see the “user-layer usage visibility” in economics/controls-and-roi).

4. Overage behavior must be explicit

What the product does when users hit their tier cap is the most commonly overlooked yet retention-critical aspect of tier design. Three typical strategies:

StrategyUser experienceBusiness impactSuitable scenario
Hard stop”Monthly quota exhausted, resumes next month or upgrade now”Stable cashflow; risk losing active usersFree / Lite anti-abuse; budget-sensitive SMBs
Soft degradationAuto-switches to cheaper model and continuesMargin protection; users may not notice quality dropMid-usage Pro users
Auto pay-as-you-goOverage billed per token in real-time, consolidated next billCustomer surprise risk; complex financeEnterprise contracts / signed hybrid

Worst design: no notification on overage, continues running unrestricted, month-end bill becomes 10× normal. This is the most common churn cause for usage-billed products.

Typical tier structure example

A reference structure for an SMB-targeted agent product:

┌─────────┬──────────────┬───────────────┬────────────────────────┐
│ Tier    │ Monthly fee   │ Task cap       │ Overage behavior        │
├─────────┼──────────────┼───────────────┼────────────────────────┤
│ Free    │ $0           │ 30 tasks       │ Hard stop               │
│ Lite    │ $19          │ 200 tasks      │ Soft degrade to Haiku   │
│ Pro     │ $79          │ 1,500 tasks    │ Overage $0.05 / task    │
│ Ultra   │ $299         │ 10,000 tasks   │ Overage $0.03 / task    │
│ Enterp. │ Custom       │ Custom         │ Contractual             │
└─────────┴──────────────┴───────────────┴────────────────────────┘

(Synthetic example.)

Notable details:

  • Overage unit price decreases at higher tiers: Ultra’s $0.03 is lower than Pro’s $0.05 — overage for large customers is expected behavior, not an anomaly; pricing should encourage rather than penalize
  • Enterprise tier shows no numbers: large customer contracts are always case-by-case; not publishing concrete Enterprise numbers preserves sales conversation flexibility
  • Free tier must exist but be strictly limited: 30 tasks/month allows trial + word-of-mouth without creating abuse pathway

Tier count

3-5 tiers is the empirical range:

  • Fewer than 3: customers feel “all-or-nothing”, narrow conversion funnel
  • More than 5: decision fatigue, customer choice paralysis, longer sales conversations
  • 4 is the median recommendation: Free / Lite / Pro / Ultra covers most customer segments

Cross-language / cross-market may require different tier structures — China-region customers are more sensitive to low-priced tiers; enterprise markets expect Enterprise customization. Early stage does not need regional variation; revisit after market entry.

Cross-section connections

Was this page helpful?
Edit on GitHub