Designs and optimizes usage-based pricing for AI products: how to calibrate freemium tiers, model LTV for token/credit economies, design upgrade triggers from usage signals, and avoid the traps specific to AI pricing. Use when setting up a freemium tier, diagnosing low free-to-paid conversion, modeling unit economics for an AI API, or deciding between credits, subscriptions, and pay-as-you-go.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Designs and optimizes usage-based pricing for AI products: how to calibrate freemium tiers, model LTV for token/credit economies, design upgrade triggers from usage signals, and avoid the traps specific to AI pricing. Use when setting up a freemium tier, diagnosing low free-to-paid conversion, modeling unit economics for an AI API, or deciding between credits, subscriptions, and pay-as-you-go.
triggers
["/ai-usage-pricing-growth","user is designing a freemium tier for an AI product","free-to-paid conversion is low for an AI product","user wants to model unit economics for an AI API","user is deciding between credits, subscriptions, and pay-as-you-go","user wants to design upgrade triggers from usage signals"]
Usage Economics Strategist. AI products have fundamentally different unit economics than traditional seat-based SaaS. The marginal cost of serving a user is real (inference is not free), LTV is driven by usage intensity not seat count, and the freemium calibration problem is acute — too generous and you serve users for free forever; too restrictive and they never experience the value. This skill is the map through that.
Scope boundary: this skill is the AI-specific monetization layer (token/credit economies, inference-cost LTV, AI freemium). For general value-based pricing — value-metric choice, value/cost/competitor triangulation, packaging/tiers, and the LTV/CAC sanity gate that isn't AI-specific — use pmm/pricing. The two compose: pmm/pricing for the value/packaging spine, this skill for the AI-usage economics.
Contract
This skill guarantees:
Pricing model recommendation is matched to the specific product type and growth motion — not generic
Freemium calibration uses the habit-threshold framework, not arbitrary limits
Upgrade prompts are behavior-triggered, not time-based
LTV model uses cohort-level revenue trajectory logic, not seat-based SaaS formulas
AI pricing antipatterns are checked before any tier structure is recommended
API pricing includes the free → developer → production → enterprise tier logic with the prototype enablement principle
Before starting
Confirm (ask or infer):
Product type — consumer AI app / prosumer AI tool / AI API / AI infrastructure?
Current model — credits/tokens / flat subscription / pay-as-you-go / hybrid / no monetization yet?
Conversion problem — free-to-paid rate / trial-to-active / active-to-enterprise?
Inference cost structure — is marginal cost per user material? (determines whether free tier generosity is bounded)
ICP — developer / creative professional / business user / enterprise? (determines willingness-to-pay and tier design)
Inputs
Required before proceeding:
Product description and primary use case
Current pricing model (if any)
Free-to-paid conversion rate or the specific metric that is underperforming
Inference cost per typical user session (approximate)
Target ICP and their primary use frequency
Step 1 — Pricing model selection
Model
How it works
Best for
Growth risk
Credits / tokens
User buys or receives a fixed quantity; depletes on use
API products, image generators, usage-variable products
Credit anxiety kills habit formation; users ration, never explore
Subscription (flat)
Monthly fee, unlimited (or high-cap) use
High-frequency use; productivity tools
Hard to monetize light users; over-serves heavy users at cost
Pay-as-you-go (metered)
Billed per unit of use; no upfront commitment
API products, enterprise
High barrier to start; users hesitate to explore
Hybrid (freemium credits + subscription)
Free tier with credit allowance; paid tier is subscription or PAYG
Most consumer and prosumer AI products
Most complex to explain; can confuse the user
For growth optimization: the freemium → subscription transition is the highest-leverage design decision. The free tier must be generous enough to create habit, restrictive enough to create upgrade pressure at the moment of highest perceived value.
Step 2 — Freemium calibration
Wrong question: "How much should we give away for free?"
Right question: "What is the minimum amount of usage that creates a formed habit, and can we let users reach that before hitting a limit?"
FREEMIUM CALIBRATION FRAMEWORK
Step 1: Define the habit threshold.
The usage point at which users are likely to continue on their own.
Examples:
- Coding assistant: completing 10+ code generations
- Image tool: exporting 5+ images
- Writing tool: completing 3+ full drafts
IF no habit threshold is known → run a cohort analysis:
What usage volume separates users who return within 7 days from those who don't?
That volume is your habit threshold.
Step 2: Set the free tier limit just beyond the habit threshold.
Users form the habit before they hit the wall.
IF limit is before habit threshold → users leave instead of upgrade.
This is the most common miscalibration.
Step 3: Time the upgrade prompt at the moment of highest perceived value.
NOT at an arbitrary limit (e.g., "you've used 50% of credits").
AT a signal of value delivery (e.g., "you've exported 5 images" or "you've completed
your first production-grade output").
Step 4: Validate with cohort data.
What is free-to-paid conversion rate by days-since-signup cohort?
The peak conversion day is when perceived value is highest.
Align the free tier limit to that day — not earlier, not much later.
COMMON MISTAKE: setting the free tier limit before users can experience the product's
best capability. Users hit the limit during exploration, not after value delivery.
They leave instead of upgrade.
Step 3 — LTV modeling for usage-based AI
Seat-based SaaS formula does not apply:
SEAT-BASED SAAS (does not apply):
LTV = ARPU_seat × (1 / churn_rate)
USAGE-BASED AI (use this):
LTV = ARPU_active_month × retention_curve_integral
Why the difference matters:
Usage-based products have non-linear usage patterns:
heavy months, light months, dormant periods, reactivations.
Monthly churn rate alone is misleading.
Model cohort-level revenue trajectories, not just monthly churn.
Key metrics to track:
Metric
What it reveals
Revenue per active user (not per all users)
True monetization density; filters out inactive accounts
Usage concentration
What % of revenue comes from top 10% of users? High concentration = expansion revenue opportunity
Upgrade trigger event
What action preceded the upgrade decision? Instrument this — it's where to add upgrade prompts
Inference cost per user tier
Free users who consume heavily are a cost center; track cost-to-serve by tier
Credit depletion rate
How fast do free users exhaust credits? Too fast = bad calibration; too slow = no upgrade pressure
Step 4 — Usage signals as upgrade triggers
The highest-converting upgrade prompts are behavior-triggered, not time-based.
UPGRADE TRIGGER DESIGN
Signal: Approaching credit limit (80%, not 100%)
Prompt: "You've used 80% of your free credits. You're clearly getting value — [upgrade CTA]."
Why 80%, not 100%: catch users before frustration, not during it.
Signal: Hit the limit mid-task
The worst moment — the interrupt is jarring.
Design for graceful pause: "Save your work; continue with [upgrade]."
Critical: never lose the user's work. Lost work = lost user.
Signal: Repeated high-value action
Prompt: "You've [done X valuable thing] N times this week —
[users like you] typically upgrade for [specific benefit]."
Specificity is the conversion signal.
Signal: Team invitation attempt
ANY attempt to add a teammate in a free tier = strong enterprise signal.
Trigger: sales-touch or team plan upsell immediately.
Signal: Export / integration attempt
Trying to export to another tool or connect an integration signals production intent.
This is the upgrade moment — do not let it pass without an upgrade prompt.
RULE: behavior-triggered > time-based > arbitrary usage percentage.
Step 5 — API pricing: developer-specific
For developer-facing AI APIs (foundation models, AI infrastructure):
API TIER STRUCTURE
Free tier (exploration)
Rate-limited; small context window; no SLA
Required: first API call achievable with zero credit card.
Developers will not add a payment method to explore.
Provide credits at signup, immediately usable, no approval required.
Developer tier (building)
Higher limits; webhook support; logs; larger context window
This tier must be generous enough to build a real prototype.
A prototype that depends on your API is the best expansion driver.
IF the free tier cannot produce a prototype → upgrade point is too early.
Production tier (scaling)
SLA; priority routing; volume pricing
Enterprise tier (mission-critical)
Dedicated infrastructure; custom contracts; SSO; data handling agreements
FREE → DEVELOPER TRANSITION (biggest drop-off for most API products):
Common cause: free tier is too limited to build a real prototype.
Fix: expand the free tier until a developer can build a realistic demo.
The conversion from demo-builder to paying customer is very high.
VOLUME DISCOUNT DESIGN:
For usage-based APIs, volume discounts drive expansion more than feature upgrades.
A customer using 10M tokens/month does not upgrade for more features —
they upgrade for lower per-token cost.
Build the volume discount table as an expansion motion, not just a pricing sheet.
Step 6 — AI pricing antipatterns
Antipattern
Why it fails
Charging before value is clear
Requiring payment before users experience the best capability means most never reach the upgrade decision with sufficient motivation
Opaque credit consumption
Users who can't predict how fast credits deplete get anxious and ration use; anxiety kills habit
Punishing heavy free use
Throttling or downgrading free users who use a lot punishes the best potential customers
One-size pricing
Developer wanting API access has different willingness-to-pay than a creative professional; segment tiers by ICP
Output format
## AI Usage Pricing Analysis
**Product:** [Name]
**Product type:** [Consumer / Prosumer / AI API / AI infrastructure]
**Current model:** [Credits / Subscription / PAYG / Hybrid / None]
**Conversion problem:** [Free-to-paid / Trial-to-active / Active-to-enterprise]
### Recommended pricing model
Model: [Credits / Subscription / PAYG / Hybrid]
Rationale: [2–3 sentences matching model to product type and ICP]
### Freemium calibration
Estimated habit threshold: [Usage event + volume]
Recommended free tier limit: [Just beyond habit threshold]
Upgrade prompt timing: [Specific behavioral trigger]
Cohort analysis needed: [Yes — which data to pull / No — threshold is established]
### Upgrade trigger design
| Signal | Prompt design | Priority |
|---|---|---|
| [Signal] | [Specific prompt language approach] | [P0 / P1 / P2] |
### LTV model inputs (for API products)
Revenue per active user: [$ — or "not yet measured"]
Usage concentration (top 10% revenue share): [% — or "not yet measured"]
Identified upgrade trigger event: [Named event — or "not yet instrumented"]
Inference cost per tier: [Free / Developer / Production]
### Antipattern check
[ ] No payment required before first value experience
[ ] Credit consumption is transparent and predictable
[ ] Heavy free users are not throttled or downgraded
[ ] Pricing tiers are segmented by ICP, not one-size
### API tier structure (if API product)
[Free / Developer / Production / Enterprise tier definitions]
Free → Developer conversion risk: [Identified / Not identified]
Brain reads / writes
If a companion brain repo is connected:
Before starting:
Read knowledge/icp-map.md — ICP segment determines usage patterns and willingness-to-pay; let ICP drive tier design
Read decisions/ — any previous pricing decisions and their outcomes
Brain not connected: proceed normally.
Anti-patterns (workflow anti-patterns)
Anti-pattern
Why it fails
Fix
Using seat-based SaaS LTV formula for usage-based products
Upgrade triggers are behavior-based (at least the top two)
LTV model uses cohort trajectory logic, not seat-based formula
Antipattern check completed (all four items)
API products include the four-tier structure and prototype-enablement principle
References & Sources
Tier 2 (operator source — adapted, not authoritative):
ai-usage-pricing-growth (growth-skills v1.0): three pricing model tradeoffs, freemium calibration framework, LTV model for usage-based AI, usage signals as upgrade triggers, API pricing tier structure, AI pricing antipattern taxonomy
