The short answer: feature flag vendors charge on five different meters, and the meter matters more than the feature list. Seat pricing punishes you for letting support and product touch flags. MAU pricing punishes consumer products with large anonymous audiences. Request pricing punishes chatty evaluation patterns and background polling. Event pricing punishes high-traffic experiments. Flat pricing punishes nobody but is rarer than you would expect. Before you compare features, model your own numbers against each meter, because the same tool can be $0 for one company and $40,000 a year for another with identical usage of the product.
Below are the current published rates, verified in July 2026, and the specific shape of product each one is expensive for.
The five meters
Almost every vendor in this category picks one of five things to count. Knowing which one you are looking at tells you immediately whether the price will track your headcount, your traffic, your architecture or nothing at all.
| Meter | Who charges this way | Expensive when |
|---|---|---|
| Seats | Unleash | You want non-engineers involved in flag decisions |
| Monthly active users | LaunchDarkly (client-side), Harness | You have a large anonymous or logged-out audience |
| Requests | PostHog, Vercel, AWS AppConfig, Azure App Configuration | Your services poll frequently or your fleet is wide |
| Events | Statsig | You run experiments at high traffic volumes |
| Flat | ConfigCat, Flagsmith, us | Never, though the ceiling per tier can bind |
Seat pricing: the meter that shapes your process
Unleash is the clearest example at $75 per seat per month with a five-seat minimum, so $375 a month before anyone has done anything. Self-hosting used to be the escape hatch, but Unleash moved its open-source edition and Edge OSS to end of life, with LTS from December 10, 2025 and full EOL on December 31, 2026. That changes the calculation for anyone who chose it specifically to avoid a per-seat bill.
The problem with seat pricing is not the number. It is what the number does to your process. When each additional person costs $75 a month, you ration access. Support cannot enable a beta for a customer who is on the phone, so they file a ticket. The product manager cannot check whether a flag is on, so they ask in Slack. Every one of those rationing decisions is small, and collectively they turn a self-service tool into an engineering queue, which was the thing flags were supposed to eliminate.
Worth noting that several vendors deliberately do not meter seats: LaunchDarkly charges per service connection and per client MAU rather than per user, PostHog offers unlimited seats, and ConfigCat's flat tiers include unlimited seats and unlimited MAUs. Seat pricing is a choice, not an industry standard.
MAU pricing: fine for B2B, punishing for consumer
LaunchDarkly's published model is $0 for the Developer plan, then $10 per service connection per month plus $8.33 per 1,000 client-side monthly active users. Harness feature flags meter client MAUs too, with 25,000 included on Free, 100,000 on Team and 1 million on Enterprise, though Harness publishes no price for any paid tier.
Do the arithmetic on your own audience before you get attached to the product. A B2B tool with 4,000 named users pays $33 a month in MAU charges, which is noise. A consumer app with two million monthly visitors, each one evaluated by a client-side SDK, is looking at roughly $16,600 a month on the same rate card. Same product, same features, two orders of magnitude apart.
The uncomfortable part is that MAU cost tracks marketing performance rather than engineering value. A successful campaign, a viral week or a bot wave all raise the flag bill without raising what flags are doing for you. If your traffic is spiky and anonymous, ask specifically how anonymous users are counted, whether a stable anonymous identifier is required, and what happens when the same person appears from three devices.
Request pricing: cheap headline, expensive footnotes
This is now the most common meter, and it is the one with the most fine print. Four current examples, all verified this month:
PostHog bills requests to the flags endpoint: free to 1 million a month, then $0.000100 each to 2 million, $0.000045 to 10 million, $0.000025 to 50 million and $0.000010 above. Unlimited seats. The detail almost nobody publishes is that each local-evaluation definition fetch counts as ten requests, so a single always-on server polling at the 30-second default generates about 864,000 billable requests a month before a single end user is evaluated. Run six of those and you are past the free tier on background polling alone. Experiments and survey targeting checks bill on the same meter.
Vercel Flags charges $0.03 per 1,000 flag requests on Pro, and its counting rule runs the other way: a page evaluating ten flags from one source project counts as a single request. That batching makes the effective rate far kinder than the headline. Details in the Vercel feature flags breakdown.
AWS AppConfig splits the meter in two: $0.0000002 per configuration request and $0.0008 per configuration received, where received means the configuration actually changed. That second number is 4,000 times the first, which is the whole story. A fleet polling normally costs a few dollars a month; a pipeline that rewrites the flag profile on a schedule, forcing every poll to count as a receive, costs thousands. The AWS feature flags page works the numbers through.
Azure App Configuration is the outlier because the binding constraint is not money at all. In US East the tiers are $0 per day for Free, $0.12 for Developer, $1.20 for Standard and $9.60 for Premium, so at most about $292 a month. What actually decides your tier is the request quota: Free is capped at 1,000 requests per day and returns HTTP 429 for the rest of the day once you cross it, Developer at 6,000 per hour, Standard at 30,000 per hour, and only Premium is uncapped. Feature flags are monitored separately from configuration at one request per 100 flags per refresh interval, per instance, which adds up faster than teams expect. The Azure feature flags page has the full tier table.
The general lesson across all four: with request pricing, your bill is a function of your architecture, not your business. Fleet width, poll interval, whether you use a local-evaluation cache, and whether flags batch per page all move the number by an order of magnitude. Those are engineering decisions being made, usually implicitly, by whoever wired up the SDK.
Event pricing: the experimentation meter
Statsig's model is $0 to start and $150 a month flat for Pro, plus $0.05 per 1,000 events. Events here means analytics events you send, so the meter tracks how much you measure rather than how many flags you have. For a team that instruments heavily, which is precisely the team that wants an experimentation platform, the variable component grows with the behavior the product is encouraging. Model it against your current analytics volume, since you probably already know that number.
Flat pricing: fewer people offer it than you would think
ConfigCat publishes flat tiers at $0, $110, $325 and $900 a month with unlimited seats and unlimited MAUs on every one. Flagsmith runs $0, $40 and $250. These are the two clearest flat options in the category, and the reason to care is not that flat is always cheaper. Often it is not. The reason to care is that a flat price is a number you can put in a budget in October and still be right about in March.
Every usage meter transfers forecasting work onto you. Somebody has to model poll intervals across services, or MAU growth, or event volume, and then re-model it each time the architecture changes. That work is invisible until it appears as a surprise invoice or an emergency ticket to reduce a refresh interval. Teams that already track metered cloud spend carefully will recognize the pattern immediately: the discipline that keeps a cloud and SaaS spend line item predictable is the same discipline a usage-metered flag bill demands, and most companies only build it after the first bad month.
We priced our own plans flat for exactly that reason: unlimited seats and unlimited flags, so nobody has to predict next quarter's MAU curve to know next quarter's bill.
The hidden costs nobody meters
Three costs sit outside every rate card and routinely exceed the subscription.
Flag debt. Every flag you ship is a branch in your code that someone has to remove. A team shipping four flags a month accumulates roughly fifty a year, and the ones nobody removes become permanent conditionals that make every future change harder to reason about. Vendors that give you staleness reports, code references and ownership fields are selling you time back. Vendors that do not are handing you a spreadsheet problem. Our notes on naming, ownership and flag debt cover what a working process looks like.
The build alternative. A basic flag service is a weekend project and a permanent operational obligation: consistent bucketing across languages, an audit trail, a UI, caching, a story for what happens when it is unreachable. We put real numbers on that trade in build vs buy feature flags. The short version is that the build is cheap and the ownership is not.
Migration. Switching vendors is rarely blocked by the SDK call. It is blocked by flag definitions, targeting rules, segments, integrations and the fact that bucketing algorithms differ between vendors, so users can land in different variants after the move. This is the case people use to justify adopting OpenFeature; our view on whether that abstraction earns its keep is in the OpenFeature analysis.
How to actually run the comparison
Four steps, in this order, and they take about an hour.
First, write down your real numbers: number of services evaluating flags, instances per service, poll interval, monthly active users split into identified and anonymous, analytics event volume, and how many people outside engineering should be able to flip a flag. Most teams have never written these down together, and half the pricing confusion in this category dissolves the moment you do.
Second, run those numbers through each vendor's meter at your current scale and at three times your current scale. The three-times case is where the meters separate. A model that is fine today and untenable at 3x is a model you will be renegotiating under pressure.
Third, ask each vendor what happens at the boundary. What counts as an active user. Whether local evaluation multiplies the request count. Whether archived flags still count against limits. Whether overage is billed or throttled, because throttling is an availability problem rather than a finance one. Azure throttles. AWS bills. Those are very different failure modes at 2am.
Fourth, add the seat question. If the price of letting a support engineer flip a flag is another $75 a month, you will not do it, and the tool will quietly become an engineering queue. That is a process cost that never shows up in a pricing comparison and shapes how the tool gets used for years.
The one-line summary per meter
| If your product is | The meter that hurts | The meter that helps |
|---|---|---|
| B2B SaaS, few thousand named users | Seats, if you want wide access | MAU, flat |
| Consumer app, large anonymous audience | MAU | Flat, batched requests |
| Many small services, wide fleet | Requests, especially with local-eval multipliers | Flat, seats |
| Heavy experimentation program | Events | Flat |
| Frontend-heavy, one host | Per-flag requests without batching | Batched requests, flat |
For the full field with verified July 2026 numbers, including the vendors not covered here, see the best feature flag tools roundup. If you would rather skip the modeling exercise entirely, our feature flags platform is flat per team with unlimited seats and unlimited flags, and the price is on the website.