How the Field Stacks Up
Pricing, usage limits, and performance across MonetizeKit, Autumn, Flexprice, Stigg, Lago, Stripe Billing, and Chargebee, in one place, with the source of every number.
98 cells across 14 dimensions. 4 are measured by a public harness; the rest are what each vendor documents or claims. Verified against sources on 2026-09-06.
How to Read This
A number without its origin is an opinion. Every cell below carries one of four provenance labels and, where one exists, a link to the page it came from.
Produced by a public, reproducible harness you can run yourself. Only MonetizeKit's own nightly numbers qualify; we have not load-tested any other vendor.
Stated in the vendor's documentation, pricing page, or API reference on the date shown.
Stated in vendor marketing or a blog post, or repeated by a third party. Not independently verifiable.
We could not find a public statement. The absence of a number is not a judgement about the product.
One vocabulary for every cell
Vendors write P95, p95, and "sub-50ms"; per second, /sec, and RPS; 10K and 10,000. Every figure below is rewritten into the same units so the cells read on one scale.
- p95, p99
- The 95th or 99th percentile of response time: 95 or 99 of every 100 requests were at least this fast. Always paired with where it was measured.
- end to end
- Measured by a client outside the vendor's network, so the figure includes network time. Only measured figures on this page are end to end.
- server-side
- Measured inside the vendor's infrastructure, excluding client network time. Not comparable with end to end.
- cached
- Served from a local cache or sidecar next to your application. Reflects cache hits, not the vendor's API.
- N/s, N/min, N/month
- Requests or events per second, minute, or month. Every rate names its scope: per API key, per account, per organization, or per customer.
- uptime SLA
- A contractual availability commitment. Marketing uptime figures without a contract are labeled Claimed.
Three things this page does not do
- It does not benchmark other vendors. We have not load-tested any competitor and will not publish a number about them that they did not publish first.
- It does not rank. Scopes differ (per API key, per account, per customer), and a server-side or cached latency is not comparable with an end-to-end one that includes network.
- It does not stay current on its own. Tiers and limits change without notice; the linked source is authoritative and this page tells you where to look.
Pricing lens
What each vendor bills on, what is free, what the first paid tier costs, and what sits on top. Dollar figures are as published on the verification date and change often; check the linked pricing page before deciding.
| Vendor | What you pay for The billable metric each vendor prices on. It decides whether your bill grows with customers, events, or revenue. | Free tier What you get before paying. | Entry paid tier The first fixed-price tier and what it includes. | Fees on top Charges that apply in addition to the platform tier. | License and hosting Whether you can inspect or run the platform yourself. |
|---|---|---|---|---|---|
MonetizeKit Monetization control plane above Stripe | Monetized Customers (entities with entitlements or usage in the period) DocumentedSource | Up to 100 Monetized Customers; core entitlements and metering DocumentedSource | Pro $349/month: 1,000 Monetized Customers included, graduated overage above; Scale $999/month DocumentedSource | None from MonetizeKit; your Stripe account's processing and Billing fees apply DocumentedSource | Hosted platform; SDKs MIT licensed DocumentedSource |
Autumn Open-source billing-state engine on Stripe Head to head | Monthly billing volume (revenue processed) plus API requests DocumentedSource | $8K billing volume/month, 10,000 customers and entities, 10,000,000 API requests/month, CLI and MCP DocumentedSource | Pro $375/month: $50K billing volume/month, 20,000,000 API requests/month then $5 per 1,000,000, unlimited customers DocumentedSource | Stripe fees still apply: 0.7% Billing plus payment processing DocumentedSource | Apache-2.0 open source; hosted cloud or self-host DocumentedSource |
Flexprice Open-core usage-first billing engine Head to head | Events per month, with cumulative or monthly billing-revenue caps per tier DocumentedSource | 100,000 events/month, up to $100K cumulative billing revenue; or self-host DocumentedSource | Build $500/month: 1,000,000 events/month, up to $250K cumulative or $20K/month billing revenue; Scale $1,000/month: 5,000,000 events/month DocumentedSource | No revenue share; connected gateway fees apply DocumentedSource | AGPL-3.0 open core; cloud, dedicated, self-hosted, on-prem DocumentedSource |
Stigg Usage runtime and entitlements platform Head to head | Managed entities plus usage events/month; ingestion rate tiers sold separately Pricing page marked early preview, GA September 2026 DocumentedSource | 10,000 managed entities, 5,000,000 events/month, 1,000 events/s per account; full credits and entitlements engine DocumentedSource | Pro $499/month ($399/month billed annually): 10,000 entities and 25,000,000 events/month included, graduated above; 10,000 events/s per account DocumentedSource | No revenue share; ingestion rate upgrades from $1,500/month; data destinations $150/month each on Pro DocumentedSource | Proprietary; cloud, with BYOC / in-VPC / air-gapped from $40K/year DocumentedSource |
Lago Open-source usage-based billing Head to head | Cloud quotes based on annual billing volume and events/month; self-host is free DocumentedSource | Open-source self-host with no feature gating; cloud trial available DocumentedSource | Starter, Pro, and Business cloud tiers are quote-only DocumentedSource | No revenue share stated; payment provider fees apply DocumentedSource | AGPLv3 open source; cloud or self-host DocumentedSource |
Stripe Billing Payment-native subscription billing Head to head | Percentage of Billing volume: 0.7% pay as you go, 0.67% on volume above a monthly tier DocumentedSource | No platform fee; 0.7% of Billing volume plus payment processing DocumentedSource | Monthly plans on a one-year contract, priced by Billing-volume band; 0.67% on volume above the band DocumentedSource | Payments 2.9% + 30 cents per card charge; customer portal custom domain $10/month DocumentedSource | Proprietary hosted service DocumentedSource |
Chargebee Subscription billing and revenue operations Head to head | Percentage of monthly invoicing volume: $0/month + 0.80%, or $99/month + 0.65% DocumentedSource | $0/month + 0.80% of invoicing volume on Flow DocumentedSource | Flow $99/month + 0.65% of invoicing volume; Enterprise custom DocumentedSource | Gateway fees apply; RevRec, CPQ, and data export are paid add-ons DocumentedSource | Proprietary hosted service DocumentedSource |
Usage lens
Rate limits, ingestion ceilings, batch sizes, and what happens at the limit. Every rate is written as N/s, N/min, or N/month followed by its scope: per API key, per account, per organization, or per customer. A per-customer limit and a per-key limit are not directly comparable.
| Vendor | API rate limit The default ceiling on general API calls. Every rate names its scope (per API key, per account, per organization, per customer); compare the scope as well as the number. | Entitlement or balance checks How fast you may ask 'can this customer do this' and what the check returns. | Usage event ingestion Documented limits on sending usage events, and the batch size per request. | Behavior at the limit and under failure What happens when you exceed a limit or the vendor is unreachable. This is where billing systems differ most in practice. |
|---|---|---|---|---|
MonetizeKit Monetization control plane above Stripe | 100 requests/min per API key by default, tier-aware through a plan entitlement; plus an API requests/month quota per plan The public harness reads X-RateLimit-Limit before every run and paces to it MeasuredSource | Within the 100 requests/min per API key limit; one call returns allowed, reason code, granting plans, and reset time DocumentedSource | Within the 100 requests/min per API key limit; batch endpoint accepts up to 500 events per request MeasuredSource | 429 with X-RateLimit-Reset; the Node SDK offers response caching and configurable degradation modes (fail open or fail closed) DocumentedSource |
Autumn Open-source billing-state engine on Stripe Head to head | 25 requests/s per organization on general endpoints; 30 requests/min per customer on billing operations DocumentedSource | 10,000 requests/s per customer on check and customer reads DocumentedSource | 10,000 requests/s per customer on track; batch endpoint accepts up to 1,000 events per request, processed asynchronously DocumentedSource | 429; customer-state reads may shed 503 with Retry-After; SDKs fail open by default (check returns allowed, track drops the event) DocumentedSource |
Flexprice Open-core usage-first billing engine Head to head | Not published for general endpoints; event ingestion limits are documented separately Not published | Entitlements read as configuration; the architecture guide recommends push alerts and a local flag rather than hot-path calls DocumentedSource | 1,000 single-event requests/min per account; 100 bulk requests/min per account with up to 1,000 events per request Marketing cites 40,000+ events/s and, elsewhere, 1,000,000 events/s; those are claimed, not documented limits DocumentedSource | 429; events are acknowledged only after a durable Kafka write; SDK retries plus optional S3 degraded mode and replay DocumentedSource |
Stigg Usage runtime and entitlements platform Head to head | Entitlement reads unlimited per account on the Edge API; management API limits not published DocumentedSource | Unlimited entitlement reads per account on the Edge API; the sidecar serves cached reads locally DocumentedSource | Report usage 3,000 requests/min per account; report events 1,000 bulk requests/s per account; ingestion tiers of 1,000, 10,000, 50,000, and 1,000,000+ events/s by plan DocumentedSource | 429 above the ingestion limit while existing enforcement continues; the sidecar serves cached reads and static defaults during outages DocumentedSource |
Lago Open-source usage-based billing Head to head | REST limits exist but figures are not published; streaming connectors are exempt DocumentedSource | Entitlements read per subscription over REST; no dedicated check endpoint documented DocumentedSource | REST batch of up to 100 events per request, atomic; Kafka, Redpanda, Kinesis, and S3 connectors are not rate limited Marketing claims up to 1,000,000 events/s through the ClickHouse pipeline DocumentedSource | Batch is atomic: one invalid event rejects the whole batch with 422; streaming is bounded by your broker DocumentedSource |
Stripe Billing Payment-native subscription billing Head to head | 100 requests/s per account in live mode; 25 requests/s per endpoint DocumentedSource | Active entitlements list per customer within the 100 requests/s per account limit; no quota check DocumentedSource | Meter events 1,000 events/s per account (v1); meter event streams 10,000 events/s per account with 100 events per request, up to 200,000 events/s on request DocumentedSource | 429 with Stripe-Rate-Limited-Reason; meter events are processed asynchronously and aggregated at period end DocumentedSource |
Chargebee Subscription billing and revenue operations Head to head | 150 requests/min (Starter), 1,000 requests/min (Performance), 3,500 requests/min (Enterprise default) per site; 50 concurrent GET and 100 concurrent POST DocumentedSource | Subscription entitlements list within the plan's requests/min limit; no quota check DocumentedSource | 100,000,000 events/month included on Flow; up to 500,000,000 events/month with an add-on; API calls within the plan's requests/min limit DocumentedSource | 429 with Retry-After; live sites are flagged and may have requests blocked until traffic falls within limits DocumentedSource |
Performance lens
Latency, uptime commitments, transparency, and consistency. Percentiles are written p95 and p99, and every latency figure states whether it was measured end to end, server-side, or cached. Only MonetizeKit's figures are measured by a public harness; every other latency figure is what the vendor documents or claims.
| Vendor | Published latency Response-time figures and where they were measured. End-to-end figures include network; server-side and cached figures do not, so they are not comparable. | Uptime commitment Contractual uptime SLAs where published, otherwise marketing uptime claims. | Status and transparency How you can see the platform's health and verify the numbers above. | Consistency of usage and balances How quickly a recorded event is reflected in the next access decision. | Regions and failover Where the service runs and how it handles a regional problem. |
|---|---|---|---|---|---|
MonetizeKit Monetization control plane above Stripe | p95 190 ms entitlement check and p95 174 ms usage ingest, end to end from an external runner, including a p95 159 ms network floor (latest nightly run) Nine scenarios, 600 samples each, published with the raw run record; two scenarios missed their p95 budget on the latest run MeasuredSource | No published uptime SLA; custom SLA on Enterprise DocumentedSource | monetizekit.app/status with synthetic checks every 5 minutes from multiple regions and a live API health endpoint; public nightly performance harness with per-run permalinks and methodology | Usage and credits are updated on write and reflected by the next check; SDK caching is opt-in and bounded DocumentedSource | Single region; the harness measures from one runner network path DocumentedSource |
Autumn Open-source billing-state engine on Stripe Head to head | Under 50 ms for US checks, as repeated in a third-party roundup, measurement point not stated; no latency figure in Autumn's own docs ClaimedSource | No published uptime SLA; public status page DocumentedSource | status.useautumn.com; engineering blog with public post-mortems | Synchronous: check can deduct atomically (sendEvent) or hold a lock; balances are the system of record DocumentedSource | Single region after retiring an active-active multi-region setup; documented publicly DocumentedSource |
Flexprice Open-core usage-first billing engine Head to head | Server-side targets: p95 under 500 ms entitlement or balance check, p95 about 200 ms event ingestion; marketing cites p99 under 60 ms, measurement point not stated DocumentedSource | 99.95% uptime SLA on standard and premium, 99.99% uptime SLA on enterprise dedicated; SOC 2 Type II DocumentedSource | Status page; architecture doc publishes SLOs, failure modes, and freshness tiers DocumentedSource | Balances derived from ClickHouse aggregations; reconciled within 5 minutes on standard tiers, within 1 minute on enterprise dedicated DocumentedSource | US, India, and EU stacks with region isolation; multi-AZ data tier DocumentedSource |
Stigg Usage runtime and entitlements platform Head to head | p95 under 100 ms entitlement reads and p95 about 200 ms usage reporting, server-side on the Edge API; p95 under 10 ms cached, from the sidecar in an internal benchmark DocumentedSource | 99.95% uptime SLA on Pro, 99.99% uptime SLA on Scale and BYOC; Edge API architecture target above 99.9975% DocumentedSource | status.stigg.io with component uptime; sidecar Prometheus metrics DocumentedSource | Sidecar cache updated by real-time subscriptions; report usage returns the updated credit balance optimistically DocumentedSource | Multi-region active-passive management API with automated failover; CloudFront edge for reads DocumentedSource |
Lago Open-source usage-based billing Head to head | No latency figure published Not published | 99.9% historical uptime cited; uptime SLAs for enterprise customers by contract ClaimedSource | Open-source repository; no public status page found Not published | Real-time aggregation on the ClickHouse pipeline ClaimedSource | Not published for cloud; self-host wherever you run it Not published |
Stripe Billing Payment-native subscription billing Head to head | No latency figure published Not published | No public standard uptime SLA; Stripe reports above 99.999% API uptime in newsroom posts ClaimedSource | status.stripe.com with per-product history DocumentedSource | Meter events processed asynchronously; summaries and invoices may lag recent events DocumentedSource | Global infrastructure; details not published per product Not published |
Chargebee Subscription billing and revenue operations Head to head | GET requests 'often under 50 milliseconds', server-side, in the API rate-limit notes; no formal figure DocumentedSource | 99.9% uptime SLA; status page reports 90-day uptime per region DocumentedSource | status.chargebee.com with 90-day uptime by region and incident history DocumentedSource | Near real-time usage aggregation on the usage-based billing tier DocumentedSource | US, EU, and AU API regions reported on the status page DocumentedSource |
Why Only One Column Is Measured
We sell an API, so its latency is part of the product and is published like documentation: nightly, from a public harness, against a normal customer key, with the raw record behind every number. The method, the k6 workload, and the pipeline are open so the measurements can be reproduced and the method critiqued.
What is measured
Nine scenarios: network floor, platform baseline, single and batch entitlement checks, customer and catalog reads, and three usage-ingest shapes. Each authenticated scenario runs for 10 minutes at the key's 100 requests/min limit, so every p95 rests on 600 samples.
What the numbers claim
End-to-end p95 from an external runner, including its network. Each scenario's SLO is a budget above the measured network floor, so a breach means the platform moved, not the runner. Two of nine scenarios missed their budget on the latest run and the results page says so; the methodology describes the runner and its placement.
What they do not claim
Server-side latency, behavior above the 100 requests/min per API key limit, or any comparison with another vendor. A single region and a single runner network path are known limits of the method and are listed as such.
Frequently Asked Questions
Did MonetizeKit benchmark the other vendors?
No. Only MonetizeKit's own numbers are measured, by a public nightly harness whose method and raw run records are published. Every other vendor's figure is what that vendor documents or claims, and each cell says which. Load-testing a competitor's production API without permission would be neither fair nor reliable.
Why do the latency figures look so different across vendors?
They are measured at different points. MonetizeKit's p95 is end to end from an external runner and includes a p95 159 ms network floor. Stigg's p95 under 10 ms is cached, served by a sidecar next to your application. Flexprice's targets are server-side. Marketing figures rarely say where they were measured, and the table says so when that is the case. Compare like with like or not at all.
Why is MonetizeKit's API rate limit lower than some peers?
MonetizeKit's default is 100 requests/min per API key, tier-aware through a platform entitlement, and the public harness paces to it. Some peers publish per-customer or per-organization limits in the thousands of requests/s. Scopes differ, and a per-customer limit is not the same as a per-key limit, but the gap is real and we publish it rather than hide it.
How often is this page refreshed?
Every cell records the date it was verified against its source. Pricing tiers and rate limits change without notice, so treat the linked source as authoritative and this page as a map of where to look.
Sources
Every page cited in the tables, verified on 2026-09-06. If a vendor updates a figure, the source wins and this page is wrong until refreshed.
- apidocs.chargebee.com/docs/api/error-handling
- doc.getlago.com/guide/events/ingesting-usage
- docs.flexprice.io/docs/event-ingestion/sending-events
- docs.flexprice.io/docs/getting-started/architecture
- docs.stigg.io/documentation/high-availability-and-scale/high-availability-architecture
- docs.stigg.io/guides/i-want-to/run-stigg-sidecar-api-in-production
- docs.stripe.com/billing/subscriptions/usage-based/recording-usage-api
- docs.stripe.com/rate-limits
- docs.useautumn.com/documentation/fail-open
- docs.useautumn.com/documentation/rate-limits
- docs.useautumn.com/welcome
- flexprice.io/pricing
- getlago.com/platform/usage-metering
- getlago.com/pricing
- github.com/MonetizeKit/node
- github.com/MonetizeKit/performance/blob/main/docs/methodology.md
- github.com/flexprice/flexprice
- github.com/getlago/lago
- github.com/useautumn/autumn
- monetizekit.github.io/performance
- status.chargebee.com
- status.stigg.io
- status.stripe.com
- status.useautumn.com
- stripe.com/billing/pricing
- stripe.com/newsroom/news/bfcm2023
- useautumn.com/blog/active-active-redis-cache
- useautumn.com/pricing
- www.chargebee.com/pricing/
- www.chargebee.com/solutions/usecases/contract-billing/
- www.monetizekit.app/pricing
- www.monetizekit.app/status
- www.stigg.io/blog-posts/ai-pricing-platform
- www.stigg.io/pricing
Numbers You Can Check
See the control plane behind the measured column, then read the head-to-head pages for the vendors that matter to you.