Shipping a risky change used to mean a deploy and a prayer: if the new checkout flow broke, the fix was another deploy, minutes or hours later, with the bug live the whole time. Feature flags turned that into a config change, wrapping the risky code in a toggle you can flip from a dashboard without touching the build pipeline.
On May 19, 2026, LaunchDarkly launched AgentControl, a runtime layer that changes how an AI agent behaves in production without redeploying it, reacting in under 200 milliseconds to swap models or trigger a fallback. Alongside that expansion, the platform's pricing dropped per-seat charging entirely: the current LaunchDarkly pricing page meters everything by service connections and monthly active users instead, with a separate line for AI runs.
Feature flagging is quietly becoming one of the places a vendor can decide it wants a bigger slice of your infrastructure budget. Here is what LaunchDarkly's platform costs now, and three ways to route around it.
Side-by-Side Comparison
| Platform | Model | Self-hosted free tier | Cheapest paid entry | Watch out for |
|---|---|---|---|---|
| LaunchDarkly | Proprietary, metered by connection + MAU | No | Foundation: $10/connection + $8.33/1K MAU | Median contract $63,960-$72,000/year per Vendr |
| Unleash | AGPL-3.0, self-hosted or cloud | Yes, unlimited | Pay-As-You-Go $75/seat/mo | Self-hosted under Pay-As-You-Go needs 5 seats minimum |
| GrowthBook | MIT core, enterprise dirs licensed separately | Yes, unlimited users | Cloud Pro $40/seat/mo | Free tiers cap at 1 project |
| Flagsmith | BSD-3-Clause | Yes, no published request cap | Start-Up $40/mo | Hosted free tier is 50K requests/mo only |
What LaunchDarkly Costs Now

The Developer plan is free forever, no credit card required: unlimited seats and feature flags, 5 service connections, 1,000 client-side MAU a month, 5,000 AI runs a month, and 14-day data retention. That covers a side project without hitting a wall.
Foundation is where the new model shows its shape. There is no platform or seat fee, just two meters: $10 per service connection per month, plus $8.33 per 1,000 client-side monthly active users, billed yearly. AI runs past the included 5,000 a month cost $5 per additional 1,000. Enterprise stays custom, adding advanced targeting and custom roles on top of Foundation, plus an optional paid Guardian add-on for release monitoring with automatic pause or rollback when a flagged release misbehaves.
None of this is unreasonable for what LaunchDarkly does well: real-time flag delivery at scale, audit trails, and now a control plane for agents that change behavior between deploys. But per Vendr's marketplace data, the median LaunchDarkly contract runs $63,960 to $72,000 a year, and a bill built on connections and client-side MAU moves with your traffic the same way a Railway or Fly.io bill does. If you only need flags and not agent orchestration, that is real money for capability you may not use.
Three Ways to Route Around It
The first option is a different vendor with the same idea: send flags over the network from a hosted dashboard, priced differently. Unleash, GrowthBook, and Flagsmith all fit here, and all three ship a genuinely free, self-hosted open source edition, not just a time-limited trial.
The second option is self-hosting that open source edition yourself, which turns the bill into the cost of a small VPS instead of a per-connection or per-MAU meter.
The third option sits underneath both: OpenFeature, a CNCF specification that gives your application code one vendor-neutral API for reading a flag. Write against OpenFeature once, and the provider underneath, LaunchDarkly, Unleash, Flagsmith, or your own in-house system, becomes a config change instead of a rewrite.
Unleash
Unleash is licensed AGPL-3.0, sitting at 13,772 GitHub stars, and the open source edition is a genuine docker compose up -d away with no paid tier required to run it.

The hosted Pay-As-You-Go plan is $75 per seat per month with a 14-day trial and no credit card required, covering unlimited flags, projects, and experiments, 25-plus SDKs, and 53 million API requests a month before overage at $5 per additional million. Choosing a self-hosted deployment under that plan carries a 5-seat minimum. Custom Enterprise adds a 99.99% uptime SLA and priced-by-quote support, against 99.9% on the standard plan.
Pricing: Self-hosted open source free (AGPL-3.0) · Pay-As-You-Go $75/seat/mo, 5-seat minimum self-hosted · Enterprise custom
GrowthBook
GrowthBook licenses most of its repository MIT, with three enterprise directories (packages/back-end/src/enterprise, packages/front-end/enterprise, packages/shared/src/enterprise) carved out under a separate GrowthBook Enterprise License, confirmed straight from the repo's own LICENSE file. It sits at 8,179 GitHub stars and pitches itself as warehouse-native: experiment results compute against your own data warehouse rather than a vendor's copy of your events.

The free self-hosted edition has no user limit, just a 1-project ceiling, with unlimited flags, experiments, and traffic. Cloud Starter matches that for up to 3 users at $0. Cloud Pro is $40 per seat per month for up to 50 users and 3 projects, adding a visual editor, multi-armed bandits, and safe rollouts. Enterprise, cloud or self-hosted, removes the project ceiling and adds SSO, SCIM, and a 99.99% uptime SLA.
Pricing: Self-hosted open source free, 1 project (MIT core) · Cloud Starter free, 3 users · Cloud Pro $40/seat/mo, 50 users · Enterprise custom
Flagsmith
Flagsmith is licensed BSD-3-Clause for most of the codebase, at 6,535 GitHub stars, and its self-hosted edition has no published API request ceiling at all, a real difference from vendors that meter self-hosted usage too.

The hosted side starts free at 50,000 requests a month for one team member, then Start-Up at $40 a month billed yearly (or $45 month-to-month) for up to 1 million requests and 3 members, then Scale-Up at $250 a month billed yearly (or $300 month-to-month) for 5 million-plus requests, with 5 members included and room for up to 20 at $50 per extra member.
Pricing: Self-hosted free, no published request limit (BSD-3-Clause) · Free hosted tier, 50K requests/mo · Start-Up $40/mo · Scale-Up $250/mo
OpenFeature
OpenFeature is not a competing vendor, it is a CNCF specification, licensed Apache-2.0, that defines one API for evaluating a flag: your code calls client.getBooleanValue(flagKey, defaultValue) and never imports a vendor SDK directly. LaunchDarkly, Unleash, Flagsmith, and GrowthBook each publish an OpenFeature provider, so the vendor becomes a line of setup code instead of the shape of your entire codebase.

The tradeoff is real: you get the lowest common denominator of what every provider supports, so a vendor's most advanced targeting rules may need an escape hatch. For straightforward boolean and string flags, which is most of what feature flagging is actually used for, the lock-in you avoid is worth that ceiling.
Proof: Swapping Providers Without Touching Application Code
The claim that OpenFeature avoids lock-in is easy to state and worth actually testing. Here is business logic that only ever imports the OpenFeature client, never a vendor SDK:
JavaScript// checkout.mjs - business logic that only knows the OpenFeature API, never a vendor SDK. import { OpenFeature } from "@openfeature/server-sdk" export async function renderCheckoutButton(userId) { const client = OpenFeature.getClient() const newFlowEnabled = await client.getBooleanValue("new-checkout-flow", false, { targetingKey: userId, }) return newFlowEnabled ? "Rendering the new one-click checkout" : "Rendering the classic checkout" }
And here is a script that swaps the provider underneath it twice, using the SDK's built-in InMemoryProvider to stand in for a real vendor plugin (every vendor above ships one that drops in the same way):
JavaScript// run.mjs - swaps the provider under checkout.mjs without touching a line of it. import { OpenFeature, InMemoryProvider } from "@openfeature/server-sdk" import { renderCheckoutButton } from "./checkout.mjs" const flagsOff = { "new-checkout-flow": { variants: { on: true, off: false }, disabled: false, defaultVariant: "off" } } const flagsOn = { "new-checkout-flow": { variants: { on: true, off: false }, disabled: false, defaultVariant: "on" } } console.log("--- Provider A: flag off ---") await OpenFeature.setProviderAndWait(new InMemoryProvider(flagsOff)) console.log(await renderCheckoutButton("user-1")) console.log("\n--- Provider B: flag on (different provider, same call site) ---") await OpenFeature.setProviderAndWait(new InMemoryProvider(flagsOn)) console.log(await renderCheckoutButton("user-1"))
Running npm install @openfeature/server-sdk (version 1.23.0 at the time of writing) and then node run.mjs prints this, unedited:
text--- Provider A: flag off --- Rendering the classic checkout --- Provider B: flag on (different provider, same call site) --- Rendering the new one-click checkout
checkout.mjs never changed between the two runs. Swapping a real vendor provider in production works the same way: change what you pass to setProvider, not what your application calls.
How to Migrate Without Breaking Targeting Rules
- Inventory every flag and its targeting rules first. Percentage rollouts, user segments, and prerequisite flags are the part that does not port automatically between vendors, so export the current rule set before touching code.
- Put OpenFeature between your code and the vendor SDK. Wrap existing calls in the OpenFeature client now, even while still pointed at LaunchDarkly, so the migration becomes a provider swap later instead of a second rewrite.
- Stand up the new backend and recreate flags by hand. Automatic import tools are inconsistent across vendors; treat this as a chance to delete flags nobody has checked in months.
- Run both providers in parallel behind a flag on the flag system itself. Read from both, log any disagreement, and only trust the new one once a full week of production traffic agrees.
- Cut over targeting rules last, one segment at a time. Start with internal users, then a small percentage of real traffic, watching error rates before widening the rollout.
- Decommission the old vendor only after a full billing cycle with the new one live, so a rollback is a config change, not an emergency migration.
The step people skip is percentage rollout math: LaunchDarkly, Unleash, and GrowthBook each hash users into buckets slightly differently, so the same 10% rollout on two systems will not be the same 10% of users. Do not assume parity without checking.
Which One Should You Pick?
For a small team that wants zero infrastructure to manage, GrowthBook Cloud Starter costs nothing for up to 3 users and includes real experimentation, not just flags. To run your own server with the most permissive self-hosted terms, Flagsmith publishes no request ceiling on self-hosted deployments at all. If you want the most mature open source project with genuine enterprise adoption, Unleash at 13,772 stars and AGPL licensing is the safest bet, accepting that AGPL requires you to open-source modifications you distribute as a service. And if you are building against multiple flag providers, or just want to keep your options open, put OpenFeature in front of whichever one you pick; it costs nothing, and the provider-swap demo above shows exactly what it buys you.
Conclusion
LaunchDarkly's move into AI agent control is a real product, not just a rebrand, and its pricing reflects genuine platform investment. The reason to look elsewhere is narrower: teams paying LaunchDarkly's median $63,960 to $72,000 a year for straightforward flag delivery, without needing agent orchestration, are paying for capability they are not using. Unleash, GrowthBook, and Flagsmith all cover that gap with a real free self-hosted tier, not a crippled trial, and OpenFeature means the choice between them does not have to be permanent.
Related DevToolLab Tools
- .env File Generator - scaffold the environment variables a self-hosted Unleash, GrowthBook, or Flagsmith instance needs before your first
docker compose up. - Env File Diff Checker - compare staging and production
.envfiles to catch a flag-related config value that drifted between environments. - Webhook Signature Verifier - verify the HMAC signature on an incoming flag-change webhook before trusting the payload, since every platform here can notify your backend when a flag flips.
- Z-Score Calculator - check whether an experiment result from GrowthBook or LaunchDarkly's experimentation add-on is actually statistically significant before you ship it.
Related Guides
- Best Heroku Alternatives in 2026 - the same "the vendor changed the deal" calculation, applied to hosting instead of flags
- Best AI Agent Frameworks in 2026 - the application layer that AgentControl's runtime governance sits underneath
- Best Secrets Management Tools in 2026 - where flag-provider API keys and webhook secrets should actually live
- Best Infrastructure as Code Tools in 2026 - version-control a self-hosted flag server's config the same way you do the rest of your stack
