Why Pricing Simulation Matters
Traditional SaaS pricing breaks down fast for AI agents because usage varies wildly. Some customers generate $50 in costs, others $700. A flat fee means you’re either:- Undercharging power users — leaving money on the table
- Overcharging light users — driving them away
- Going negative on high-usage customers — literally paying them to use your product
How It Works
The Pricing Simulator is a dev-first tool that bridges your telemetry data with billing logic. Here’s the flow:- Historical data (last month’s actual usage)
- Hypothetical scenarios (2x growth, new feature launch)
- Individual customers (understand per-customer economics)
- Different pricing models side-by-side (compare 3 pricing strategies instantly)
Pricing Models You Can Build
The simulator supports the most common usage-based pricing patterns AI companies use:Tiered Subscription
Free tier + volume discounts. Example: First 1M spans free, then 0.00003 thereafter.
Pay-As-You-Go
Linear or tiered per-unit pricing. Example: 0.002 per 1k tokens.
Subscription + Overage
Base monthly fee + usage charges beyond included amount. Example: 0.00005 per additional span.
Hybrid Model
Combine multiple pricing rules. Example: Base fee + per-session charge + per-token overage fee.
Quick Start Example
Here’s how a customer support agent company uses the simulator: Current problem: Flat $500/month, losing money on power users Step 1: Import last month’s usageCommon Use Cases
1. Switching from Flat to Usage-Based Pricing
Scenario: You charge $500/month but margins are inconsistent. Solution:- Run simulations on last 3 months of customer data
- Identify customers with negative margins
- Design tiered pricing that protects margins on high-usage customers
- Test in shadow mode with existing customers
- Roll out with grandfather pricing for early customers
2. Launching a New Feature with Separate Pricing
Scenario: Adding document analysis feature—should it be included or priced separately? Solution:- Estimate usage based on beta testing data
- Create two pricing models: “included” vs. “separate add-on”
- Run simulations comparing projected revenue and churn risk
- Use filters to charge only customers using the feature
3. Preventing Margin Erosion from Power Users
Scenario: Top 10% of customers consume 80% of resources but pay same as everyone. Solution:- Run per-customer margin analysis
- Identify customers with less than 5% margins
- Design threshold-based pricing: included usage + overage fee
- Test impact on revenue and projected churn
- Communicate transparently with affected customers
4. Validating Pricing Before Launch
Scenario: Pre-launch startup needs to price before first customer. Solution:- Use synthetic usage data based on beta testing
- Build 3-5 pricing model variants
- Run what-if scenarios (low/medium/high usage)
- Calculate break-even points and target margins
- Choose model that balances growth and profitability
Integration with Billing
Once you’ve designed and validated your pricing model in the simulator, connect it to your billing system:1
Save Your Pricing Model
Activate the pricing model via API or dashboard. This makes it available for production billing.
2
Configure Billing Webhooks
Set up webhooks to trigger billing events:
billing.period_end, billing.threshold_reached, or manual export.3
Map Customer Metadata
Ensure telemetry data includes
customer_id so usage is attributed correctly.4
Enable Shadow Mode (Optional)
Run the pricing model in shadow mode to generate reports without actual billing, perfect for validation.
5
Go Live
Switch from shadow mode to production. Webhooks automatically send billing data to Stripe, your internal system, or wherever you need it.
Pro tip: Always test new pricing models in shadow mode first. You’ll see exactly what customers would be charged before making it real.
Pricing Simulator API Reference
Overview
This document defines the API specification for a pricing simulator that enables users to build, manage, and test pricing models that convert usage records into bills. The API is designed to be SDK-compatible and follows REST conventions. Base URL:https://api.{domain}/v1
Authentication
All API requests require authentication via Bearer token in the Authorization header:1. Pricing Models API
Data Model
1.1 List Pricing Models
Retrieve a paginated list of pricing models. Endpoint:GET /pricing-models
Query Parameters:
| Parameter | Type | Default | Description |
|---|---|---|---|
limit | integer | 20 | Number of results per page (1-100) |
cursor | string | - | Pagination cursor from previous response |
status | string | - | Filter by status: draft, active, archived |
search | string | - | Search by name or description |
sort_by | string | created_at | Sort field: created_at, updated_at, name |
sort_order | string | desc | Sort order: asc, desc |
200 OK
1.2 Get Pricing Model
Retrieve a single pricing model by ID. Endpoint:GET /pricing-models/{model_id}
Path Parameters:
| Parameter | Type | Description |
|---|---|---|
model_id | string | The pricing model identifier |
| Parameter | Type | Default | Description |
|---|---|---|---|
version | string | latest | Specific version to retrieve |
include_history | boolean | false | Include version history |
200 OK
1.3 Create Pricing Model
Create a new pricing model. Endpoint:POST /pricing-models
Request Body:
201 Created
nameis required and must be 1-255 characterscurrencymust be a valid ISO 4217 coderulesarray must contain at least one rule- Each rule must have valid
telemetry_sourceandpricing_typecombinations - Tiered pricing must have at least one tier with the last tier having
upto: "unlimited" multiplierandper_unit_countare required forflat_multiplierpricing type
1.4 Update Pricing Model
Update an existing pricing model. This creates a new version. Endpoint:PUT /pricing-models/{model_id}
Path Parameters:
| Parameter | Type | Description |
|---|---|---|
model_id | string | The pricing model identifier |
| Parameter | Type | Default | Description |
|---|---|---|---|
version_bump | string | minor | Version increment: major, minor, patch |
200 OK
1.5 Partial Update (Patch) Pricing Model
Update specific fields without replacing the entire model. Endpoint:PATCH /pricing-models/{model_id}
Request Body:
200 OK
1.6 Delete Pricing Model
Delete a pricing model (soft delete - moves to archived status). Endpoint:DELETE /pricing-models/{model_id}
Query Parameters:
| Parameter | Type | Default | Description |
|---|---|---|---|
hard_delete | boolean | false | Permanently delete (requires admin) |
version | string | all | Specific version to delete, or “all” |
200 OK
1.7 Clone Pricing Model
Create a copy of an existing pricing model. Endpoint:POST /pricing-models/{model_id}/clone
Request Body:
201 Created
1.8 Validate Pricing Model
Validate a pricing model configuration without saving. Endpoint:POST /pricing-models/validate
Request Body: Same as Create Pricing Model
Response: 200 OK
400 Bad Request (if invalid)
2. Pricing Simulation API
Data Model
2.1 Run Simulation
Execute a pricing simulation. Endpoint:POST /pricing-models/simulate
Request Body:
200 OK
2.2 Simulate with Inline Model
Test a pricing model without saving it first. Endpoint:POST /pricing-models/simulate
Request Body:
2.3 Compare Models
Compare pricing across multiple models. Endpoint:POST /pricing-models/simulate/compare
Request Body:
200 OK
2.4 Batch Simulation
Run simulations for multiple customers/periods. Endpoint:POST /pricing-models/simulate/batch
Request Body:
202 Accepted (for async processing)
2.5 Get Batch Status
Endpoint:GET /pricing-models/simulate/batch/{batch_id}
Response: 200 OK
2.6 Margin Analysis
Analyze margins based on costs. Endpoint:POST /pricing-models/simulate/margin
Request Body:
200 OK
3. Error Handling
Error Response Format
Error Codes
| HTTP Status | Code | Description |
|---|---|---|
| 400 | VALIDATION_ERROR | Invalid request body |
| 400 | INVALID_MODEL_ID | Model ID format is invalid |
| 400 | INVALID_RULE_CONFIG | Rule configuration is invalid |
| 401 | UNAUTHORIZED | Missing or invalid API key |
| 403 | FORBIDDEN | Insufficient permissions |
| 404 | MODEL_NOT_FOUND | Pricing model does not exist |
| 404 | VERSION_NOT_FOUND | Specified version does not exist |
| 409 | VERSION_CONFLICT | Version already exists |
| 409 | MODEL_IN_USE | Cannot delete model assigned to customers |
| 422 | SIMULATION_ERROR | Unable to process simulation |
| 429 | RATE_LIMITED | Too many requests |
| 500 | INTERNAL_ERROR | Server error |
4. Webhooks
Subscribe to pricing model events.Available Events
| Event | Description |
|---|---|
pricing_model.created | New model created |
pricing_model.updated | Model updated (new version) |
pricing_model.activated | Model status changed to active |
pricing_model.archived | Model archived |
simulation.completed | Batch simulation completed |
Webhook Payload
5. SDK Usage Examples
Python SDK
TypeScript SDK
6. Rate Limits
| Endpoint | Rate Limit |
|---|---|
GET /pricing-models | 100/minute |
GET /pricing-models/{id} | 200/minute |
POST /pricing-models | 20/minute |
PUT/PATCH /pricing-models/{id} | 20/minute |
POST /pricing-models/simulate | 50/minute |
POST /pricing-models/simulate/batch | 10/minute |
7. Pagination
List endpoints use cursor-based pagination for consistent results:cursor parameter to fetch the next page:
Best Practices
Start with Shadow Mode
Start with Shadow Mode
Always test new pricing models in shadow mode before going live. Run simulations with real usage data, share results with your team, and validate that margins meet your targets.
Version Your Pricing Models
Version Your Pricing Models
Use semantic versioning (1.0.0, 1.1.0, 2.0.0) and include change summaries. This creates an audit trail and makes it easy to roll back if needed.
Monitor Per-Customer Margins
Monitor Per-Customer Margins
Don’t just look at aggregate metrics. Run margin analysis per customer to identify who’s profitable and who’s not. This informs both pricing and product decisions.
Use Multiple Pricing Rules
Use Multiple Pricing Rules
Combine base fees, usage tiers, and overage charges. Hybrid models give you predictable baseline revenue while protecting margins on high usage.
Test Growth Scenarios
Test Growth Scenarios
Always run “what-if” simulations at 2x, 5x, and 10x your current usage. Your pricing should scale profitably as you grow.
Communicate Changes Transparently
Communicate Changes Transparently
When changing pricing, grandfather existing customers or give 60-90 days notice. Use the simulator to quantify impact and prepare customer communications.
Pricing Strategies for AI Agents
Based on patterns from successful AI agent companies:| Company Stage | Recommended Model | Why |
|---|---|---|
| Pre-launch / Beta | Flat fee or free | Gather usage data, validate product-market fit |
| Early Revenue (0-50 customers) | Simple tiered pricing | Easy to explain, predictable for customers |
| Growth (50-500 customers) | Usage-based with tiers | Scales with value, protects margins |
| Scale (500+ customers) | Hybrid model | Base fee + usage ensures minimum revenue per customer |
Anti-Patterns to Avoid
Quick Reference
When to Use the Pricing Simulator
✅ Use it for:- Designing initial pricing for a new product
- Switching from flat to usage-based pricing
- Adding new billable features or metrics
- Optimizing margins on existing pricing
- Validating pricing changes before rollout
- Understanding per-customer economics
- Modeling growth scenarios
- Simple flat-fee pricing with no usage component
- One-time services with no recurring revenue
- Products with fixed costs and no variable usage
Next Steps
Build Your First Model
Follow the API guide to create your first pricing model via SDK or API
Run a Simulation
Test your model against usage data and see projected revenue
Margin Analysis
Calculate true profitability by connecting your cost data
Billing Integration
Connect your pricing model to billing webhooks for production use