Skip to content
SlashClone
DiscoverUse in ClaudeSubmit a link
Sign in
Made by@agentcosts

Usage pricing simulator

@agentcosts/usage-pricing-simulator

Test pricing models for an AI product on your real usage before you change a price: per seat, per task, credits, and hybrid (platform fee plus included credits plus overage). Shows revenue, gross margin after LLM cost, and which customers' bills would jump or drop under each model.

SkillFinancev1.0.0 (latest)Tested
Use in Claude Save Like Clone Comment
Activity
New: be the first to try it
  1. 1---
  2. 2name: usage-pricing-simulator
  3. 3description: Simulate pricing models for an AI or agentic product on real usage data before changing prices. Compares current pricing with per seat, per task, credits, and hybrid (platform fee plus included credits plus overage), showing monthly revenue, gross margin after LLM cost, and which customers' bills would rise or fall sharply. Use when the user asks "should we charge per seat or per task", "usage-based pricing", "credits pricing", "how do we price our AI agent", "what if we raise prices", or has a customer that costs more than it pays.
  4. 4license: MIT
  5. 5---
  6. 6
  7. 7# Usage pricing simulator
  8. 8
  9. 9Pricing an AI product on gut feel is risky: per-seat pricing can lose money on heavy users, and pure usage pricing can scare off light ones. This kit replays last month's real usage under each pricing model you want to try, so you see revenue, margin, and the customers who would feel the change before anyone gets an email.
  10. 10
  11. 11## Inputs
  12. 12
  13. 131. **Usage** in the shared schema (from app logs or `llm-usage-normalizer`), ideally with `run_id` and `outcome` so tasks and successes can be counted. One to three recent months.
  14. 142. **Customers** `data/customers.csv`: `customer,seats,mrr` (what they pay per month today), optional `plan`.
  15. 153. **Pricing models** `data/pricing.json`. Copy `examples/pricing.json` and edit with the user:
  16. 16
  17. 17 ```json
  18. 18 {
  19. 19 "target_margin": 0.7,
  20. 20 "bill_on": "success",
  21. 21 "credit_rates": { "research_agent": 100, "doc_summary": 8, "*": 5 },
  22. 22 "models": [
  23. 23 { "name": "Per seat $20", "type": "per_seat", "price_per_seat": 20 },
  24. 24 { "name": "Per task", "type": "per_task", "minimum": 29, "prices": { "research_agent": 4, "*": 0.2 } },
  25. 25 { "name": "Credits", "type": "credits", "credit_price": 0.04, "minimum": 29 },
  26. 26 { "name": "Hybrid", "type": "hybrid", "platform_fee": 79, "included_credits": 1000, "overage_credit_price": 0.04 }
  27. 27 ]
  28. 28 }
  29. 29 ```
  30. 30
  31. 31 - `bill_on`: `success` (customers pay for results; you eat failed runs) or `all`.
  32. 32 - `credit_rates`: credits per task type, used by `credits` and `hybrid`. `*` covers any other task.
  33. 33 - Each model can have a `minimum` (monthly floor). Hybrid can also take `price_per_seat`.
  34. 34
  35. 35## Steps
  36. 36
  37. 371. Look at usage per customer first: runs per task per month and LLM cost. Point out the heavy users and the near-zero users; they decide which models work.
  38. 382. Set credit rates from cost, not guesses: a task's credits should be roughly proportional to its cost per successful run (the `agent-cost-dashboard` shows it). Then pick a credit price that gives the target margin on the average customer.
  39. 393. Run:
  40. 40
  41. 41 ```bash
  42. 42 node scripts/simulate.mjs data/usage.csv --customers data/customers.csv --pricing data/pricing.json --prices data/llm-prices.csv --out out/pricing-sim
  43. 43 ```
  44. 44
  45. 454. Read `out/pricing-sim.md`. For each model report: revenue vs today, gross margin, customers under target or negative, and whose bill rises or falls more than 25%.
  46. 465. Iterate with the user: adjust one number at a time in `data/pricing.json` (a minimum, the included credits, an overage rate) and rerun. Two or three rounds usually find a model that fixes margins without shocking many customers.
  47. 476. Write a short recommendation: the model, the numbers, who is affected, and a migration idea (grandfather current customers for a term, or apply at renewal).
  48. 48
  49. 49## How to read it
  50. 50
  51. 51- Margins are after LLM cost only. Add hosting and other costs with `gross-margin-by-customer` before final decisions.
  52. 52- A model that raises revenue but sends many small customers' bills up 3x is a churn risk; a model that cuts most bills is leaving money behind.
  53. 53- Usage changes when pricing changes. Treat results as a first-order estimate, not a forecast.
  54. 54
  55. 55## Output template
  56. 56
  57. 57```markdown
  58. 58**Recommendation: Hybrid ($79 platform fee, 1,000 credits included, $0.04 per extra credit).**
  59. 59Revenue +3% vs today, margin 81%, no negative customers (cobalt-labs goes from -10% to 60%).
  60. 60Bills up a lot: cobalt-labs ($60 to $166), foxglove-retail ($49 to $79). Bills down: bluepeak, elmstreet-health.
  61. 61Migration: apply at renewal; offer foxglove-retail a starter tier.
  62. 62```
  63. 63
  64. 64## Guardrails
  65. 65
  66. 66- Never change prices, plans, or invoices, and never contact customers. This is a planning tool.
  67. 67- Cost numbers depend on the price table; say "based on the example prices" if the user has not checked them against each provider's current pricing.
  68. 68- Customer revenue is sensitive. Keep per-customer tables in `out/`.
Sign in to comment on a line