What promptfoo costs to own, and which edition changes the total
promptfoo is licensed under the MIT license, and the Community edition is free and includes all LLM evaluation features, all model providers and integrations, and red teaming with 10k probes per month. The software itself does not add a license fee in that edition. The total cost of ownership comes from three places: the model API calls your evals and red team runs make, the staff time to write, run and maintain the test suites, and the edition you choose. Model API spend recurs with every run, so the number of test cases, the number of providers compared and how often CI executes the suite will shape it more than the tool does.
Teams usually reach the point of comparing editions for one of three reasons. The first is moving from local runs on individual laptops to shared evals that several people or a CI pipeline depend on. The second is a security review asking who can change test configurations and see red team outputs, which raises access control. The third is an audit that needs centralized, dated evidence of testing. Each trigger should be written down as a requirement before anyone looks at pricing, because it determines whether Community with your own hosting is enough or whether Enterprise or On-Premise features are needed.
Confirm three things before budgeting. Ask the vendor for the Enterprise and On-Premise quote in writing, including what support levels and deployment help are included, since those figures are custom and are not published. Count your expected monthly probe volume against the 10k probe allowance in Community. Estimate your model API spend from your own test suite size and run frequency, not from a generic figure.
Whether to compare editions in-house or with a partner depends on how much of the decision is technical and how much is commercial. Teams with strong engineering capacity often run the comparison internally using the public feature list. Teams that need help mapping their access and evidence requirements to a deployment, or that want the rollout and self-hosting work scoped in advance, often bring in a partner to write that scope. Either way, the deciding input is the written requirement list, not the edition name.
What a cost-of-ownership study covers
A cost-of-ownership study compares Community, Enterprise and On-Premise against your own requirements and volumes. The result is a written recommendation you can use to decide whether, and how, to ask promptfoo for a custom quote.
Edition comparison against your requirements
Each edition is scored against the requirements you bring: red team probe volume, team sharing, SSO, custom roles, continuous monitoring and support terms. Community includes red teaming with 10k probes per month, so the study tests whether your probe volume fits that allowance before any Enterprise discussion starts.
Model API spend estimate
Model API spend is estimated from your own eval and red team volumes, not from vendor figures. The study counts prompts, providers and runs per cycle, then shows how spend changes with CI frequency. You pay the model provider directly in every edition, so this line is the same whichever edition you pick.
Self-hosting and infrastructure requirements
On-Premise and self-hosted deployments need an Express app, a database and a deployment target. Self-hosted promptfoo stores data in SQLite that cannot be shared across replicas and has no built-in authentication, so the study prices the infrastructure and access controls you would need to add yourself.
Staffing model for operation
The staffing model lists who builds, runs and upgrades the instance: platform engineers, security engineers and the people who write assertions. It shows which roles are one-time and which recur, and where Community leaves gaps that your own team would fill.
Upgrade and Node.js maintenance effort
promptfoo ships frequent releases, and the current npm release requires Node.js 22.22.0 or newer. The study estimates the recurring effort to test upgrades, pin versions in CI and keep the runtime supported, and states which of those tasks an Enterprise support agreement would cover.
Written recommendation and vendor questions
The study ends with a recommendation, the conditions under which it holds, and a list of questions for promptfoo, such as what the Enterprise price depends on, which SLAs apply and what On-Premise deployment support includes. Pricing is custom, so these questions are what turn the study into a quote request.
What drives the cost of promptfoo
This table lists the main drivers of promptfoo cost, explains why each one moves spend and suggests how to keep it down.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Edition | Community is free and includes all evaluation features and providers. Enterprise and On-Premise are priced by custom quote. | Compare the written quote against the features your team needs, and ask which edition covers each one. |
| Red team probe volume | Community includes red teaming with 10k probes per month, so heavy scheduled scans can exceed it. | Run full sweeps before releases, scope scans to changed components and track monthly probe counts from the start. |
| Number of teams and users | Shared access, team sharing and access control are Enterprise features, so cost grows with each team needing them. | Confirm how the quote counts users or teams. Start with one shared group and add teams in phases. |
| SSO and access control | Teams-based access control, SSO and custom roles are Enterprise features. The self-hosted app has no built-in authentication or RBAC. | Decide early whether SSO is needed. Place the self-hosted app behind an existing VPN or access proxy. |
| Self-hosting versus local CLI use | Local CLI runs on your machine and calls the LLM directly. Self-hosting adds servers, storage and upkeep. | Keep individual evals on the CLI. Self-host only when a shared instance is justified and plan a database beyond the default SQLite store. |
| CI/CD pipelines and providers | Each pipeline job calls model providers, so job frequency drives model API spend and runner time. | Run a small smoke suite on each commit and full suites on release. Cache results where your setup allows. |
| Data isolation and residency | On-Premise runs Enterprise functions with complete data isolation on your infrastructure. Community evals run on your machine. | Confirm where prompts, outputs and red team results are stored, and whether model providers receive them. |
| Support and SLA needs | Community offers community support only. Enterprise adds priority support with SLAs, and On-Premise adds a dedicated deployment engineer. | Ask for SLA terms in writing and estimate the internal staff time each support gap would cost. |
How the cost study runs
The sequence turns a Community versus Enterprise question into a written decision memo grounded in your own usage, provider rates and staffing.
Gather requirements from security, engineering and compliance
We interview security, engineering and compliance owners to record which evaluation and red teaming outcomes they need, who signs off on tool choices, and which data may leave your environment. The output is a requirements list with an owner named against each item, reviewed and accepted by those owners before modeling starts.
Map current and planned usage
We document eval runs, red team probe volumes, the model providers each team calls, and the CI/CD pipelines that will trigger tests. Where your team has no logs yet, we record estimates as assumptions. The output is a usage inventory that lists every provider, pipeline and team, confirmed by the engineers who operate them.
Compare edition fit against the listed capabilities
We check the requirements list against the published Community, Enterprise and On-Premise capabilities, including probe limits, team sharing, SSO, access control, monitoring and support terms. The output is a fit table marking each requirement as met, unmet or needing vendor confirmation, with the exact vendor wording recorded beside it.
Model model API spend at your provider rates
We apply your own negotiated or list rates from each model provider to the usage inventory, separating one-time setup from recurring token and probe costs. Vendor licensing is modeled separately from provider charges. The output is a monthly spend model with the rate source and assumptions shown for each line, so finance can change any input.
Size the staffing and support model
We estimate who maintains the deployment, upgrades it, writes and tunes test suites, and answers pipeline failures, comparing internal staff time with vendor support tiers. The output is a staffing table listing roles, the share of time each role needs and the support level each edition provides, checked with your engineering manager.
Write the decision memo and vendor questions
We combine the requirements, fit table, spend model and staffing table into a written decision memo that states the recommended edition, the cases where Community remains sufficient and the reasons. The memo closes with open questions for the vendor, such as how probe limits are counted and what On-Premise requires. The output is the memo and question list, delivered for your review.
Recurring costs after the decision
This table lists each recurring and one-time cost line for Community, Enterprise and On-Premise promptfoo, who is paid for it, and what to ask for in a quote.
| Cost line | Who is paid | One-time or recurring | What to ask for or confirm |
|---|---|---|---|
| Model provider API spend for evals and red teaming | Your model providers, billed on your own accounts | Recurring, scales with eval runs, CI jobs and red team test volume | Confirm which providers your pipelines call and set spend limits per key before wide rollout |
| Enterprise or On-Premise subscription | promptfoo, under a custom price | Recurring, usually annual, set by the written quote | Ask what is included in the probe allowance, how overage is billed and whether it renews automatically |
| Community edition licence | No licence fee, MIT license | Not applicable, no subscription | Confirm your own internal review of the MIT license terms and the Node.js version your runners use |
| Hosting and storage for a self-hosted instance | Your cloud account, data center or hardware budget | Recurring compute, storage and backup costs, plus one-time setup | Size the instance for a shared database, since the default SQLite store cannot be shared across replicas |
| Upgrade and Node.js runtime maintenance | Your platform team, or DeployOpen under a retainer | Recurring, tied to frequent releases and minimum Node.js versions | Confirm the pinned promptfoo version, the Node.js baseline (22.22.0 or newer for release 0.124.1) and who tests each upgrade |
| Internal staff time | Your engineers, security and compliance staff | Recurring for triage, review and rule upkeep, one-time for initial setup | Estimate hours for assertion design, red team review and access administration with your own team leads |
| Support tier and SLA terms | promptfoo for Enterprise and On-Premise, community forums for Community | Recurring with the subscription | Ask for response targets, SLA terms in writing and the scope of the dedicated deployment engineer on On-Premise |
Where cost estimates usually go wrong
Most promptfoo budgets miss a few recurring items rather than the license line. The cards below cover the assumptions that most often break a Community or Enterprise estimate.
Community is not a shared team plan
The Community edition is free and includes all evaluation features, providers and red teaming with 10k probes per month, but it comes with community support only. Teams that share one instance, one set of results and one set of reviewers should confirm whether that shared use fits the edition before assuming it costs nothing.
Red team probe volume against the allowance
The Community allowance is 10k probes per month. Probe counts grow with the number of plugins, strategies, test cases and repeated runs, so a scan that looks small can consume the allowance quickly. Estimate probes per scan from your own configuration and compare the monthly total before scheduling recurring red team runs.
Model API spend on every CI run
Each evaluation that calls a model is billed by the provider, not by promptfoo. A suite wired into CI/CD repeats that spend on every pull request, merge and scheduled run. Ask your team to multiply prompts, test cases, providers and runs per month, and to decide which checks run on every commit and which run nightly.
Self-hosted Community treated as production
The self-hosting documentation states that the local SQLite store cannot be shared across replicas, has no RBAC, horizontal scaling, built-in authentication or SSO, and is not recommended for production use. A budget that assumes a shared, production-grade instance on Community needs extra design and infrastructure work before it is valid.
Staff time for pinning and release tracking
Releases arrive frequently and the npm package requires Node.js 22.22.0 or newer for the 0.124.1 release. Someone must pin versions in CI, test upgrades, track Node.js changes and review release notes. That recurring staff time is often left out of Community estimates even though it does not appear on any invoice.
Enterprise budgeted without identity requirements
Enterprise adds teams-based access control, SSO and custom roles, but the SSO setup depends on your identity provider, group mapping and approval rules. Confirm those requirements with your identity team before quoting, because identity integration can add scope that a license-only estimate does not show.
How the comparison changes by starting point
A team running evals from a laptop or CI runner mostly asks whether the Community edition covers its work. The software runs locally and talks directly to the model provider, so the main cost lines are model API usage and the engineering time to write assertions and keep test suites current.
- Edition questions: whether 10k red teaming probes per month and community support meet the test plan.
- Cost lines: model API spend, CI runner time, and staff hours for building and maintaining configurations.
- Recurring: API usage and maintenance time, which scale with suite size and run frequency.
- Confirm with promptfoo: current Community limits and whether any usage terms change after the OpenAI acquisition announced on 9 March 2026.
A group that shares results across several people needs to know who can see and change what. Here the edition question becomes whether team sharing, teams-based access control and SSO justify Enterprise pricing, and the self-hosted app alone does not provide built-in authentication or RBAC.
- Edition questions: team sharing, role granularity, SSO, and support expectations.
- Cost lines: Enterprise subscription at custom pricing, identity integration work, and hosting for a shared instance.
- Recurring: the subscription, plus hosting and administration of the shared instance.
- Confirm with promptfoo: the custom quote, included SLA terms, and whether SSO requires a specific identity provider.
An organization that must keep evaluation data inside its own boundary asks whether On-Premise is needed rather than a hosted setup. On-Premise is described as Enterprise functionality on the customer's infrastructure with complete data isolation and a dedicated deployment engineer.
- Edition questions: data residency, isolation guarantees, deployment engineer scope, and evidence for compliance reviews.
- Cost lines: On-Premise subscription, infrastructure for hosting, storage and backups, and internal review effort.
- Recurring: subscription, infrastructure, and the internal time spent on access reviews and evidence.
- Confirm with promptfoo: what isolation covers in writing, upgrade and support responsibilities, and the custom price.
An organization already running promptfoo on Kubernetes with Helm has the deployment in place but must still check the self-hosted limits. The self-hosted app uses a local SQLite database that cannot be shared across replicas, so horizontal scaling and production use depend on the edition and architecture chosen.
- Edition questions: whether Enterprise replaces the SQLite-backed design for shared, scaled use.
- Cost lines: Kubernetes capacity, storage, backup tooling, and the engineering time for chart upgrades.
- Recurring: cluster capacity, chart maintenance, and upgrades across frequent releases.
- Confirm with promptfoo: supported topology for Helm deployments, migration path from SQLite, and whether a self-hosted Enterprise option fits the cluster.
What you need to provide
Before anyone can compare Community and Enterprise costs, the client has to supply a set of inputs that decide which edition fits and what the surrounding work costs. The first is a count of teams and users who will run evals or review red team results, split by who only reads output and who writes configurations. Next, collect current and expected volumes: how many red team probes and evals run per month today, and how that is likely to grow. Community includes red teaming with 10k probes per month, so a volume estimate tells you early whether that limit is a constraint.
Second, list every model provider and the API account behind each one, including who owns the account, who pays the invoices and which keys are issued per project. Model API spend is usually the largest recurring cost and is paid to the provider, not to promptfoo or DeployOpen, so the owner of each account needs to be named. Confirm the provider list against the current promptfoo provider documentation, since the supported set changes between releases.
Third, gather identity provider details if you expect shared access: the provider type, the protocols it supports, group structures and who administers it. This drives whether SSO and teams-based access control are needed, which are Enterprise features. Also record data classification and residency rules for prompts, eval datasets and red team outputs, because these decide whether a self-hosted or On-Premise deployment is required. Name the budget owner and the owner of the runtime, and list the compliance frameworks your outputs must support, such as the OWASP LLM Top 10, the NIST AI Risk Management Framework or the EU AI Act. Ask your compliance lead which control evidence the assessor will expect.
Common questions about promptfoo costs
Is promptfoo still free after OpenAI acquired it?
Yes. The Community edition is free, and promptfoo is licensed under the MIT license. OpenAI acquired promptfoo, announced on 9 March 2026, and the founders state that promptfoo will remain open source and continue to support a diverse range of providers and models. Community includes all LLM evaluation features, all model providers and integrations, and red teaming with 10k probes per month, with community support. Calls to model APIs made with your own provider keys are billed by those providers, so budget for them separately.
What do Enterprise and On-Premise add over Community?
Enterprise adds team sharing, teams-based access control and SSO, custom roles and permissions, continuous monitoring, a centralized guardrail dashboard, remediation recommendations and priority support with SLAs, at custom pricing. On-Premise runs the same Enterprise functionality on your own infrastructure, with complete data isolation and a dedicated deployment engineer. Ask for the written SLA terms, the deployment scope, and whether the deployment engineer's time is included in the quote.
What drives the total cost of ownership for promptfoo?
Four cost areas drive the total: model API usage, edition fees, infrastructure and people. Model API spend grows with the number of test cases, the providers you use, and how often evals and red team runs execute in your CI/CD pipelines. Edition fees apply only if you choose Enterprise or On-Premise, and their custom pricing follows from the scope you agree. Infrastructure matters if you host a shared instance, and people time covers setup, assertion design and maintenance. Ask each vendor to split the quote into these areas.
Which promptfoo costs recur, and do Node.js and releases add staff time?
Model API usage recurs with every run. An Enterprise subscription also recurs, under the terms your quote sets out, and so does hosting and patching a shared instance. Setup, CI integration and assertion design are mostly one-time effort. Yes, the Node.js requirement and frequent releases add staff time. Release 0.124.1 requires Node.js 22.22.0 or newer, so each upgrade needs a version pin, a test run and a check of your CI pipeline. Plan recurring time for upgrades from the start.
Can our own engineers run promptfoo without an outside partner?
Yes, many teams run it themselves if each area has a named owner. Assign owners for CI/CD integration, the Node.js runtime and upgrade testing, provider API keys, test suite maintenance and, if you host a shared instance, access control. Self-hosted promptfoo stores data in a local SQLite database, has no RBAC or built-in SSO, and the documentation does not recommend it for production use. A shared setup therefore needs either Enterprise or access controls your team builds and tests. A partner can scope and build those pieces for you.
How DeployOpen scopes and supports this work
DeployOpen scopes promptfoo cost of ownership in writing before any work starts, covering the edition, the eval and red team workload, and the model API and staff costs behind them. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope lists which Community, Enterprise or On-Premise features the cost model covers, agreed before work starts.
- Scope also records the probe volume, model providers and CI/CD jobs your evals and red team runs need.
- Deliverables are named in writing and may include the cost comparison and the assumptions behind each line item.
How we build
- We map each eval, red team and CI/CD workload to the edition limits and features it depends on.
- We model provider API spend and staff effort separately, so each cost line has a named payer.
- We check the Community probe allowance against your planned test volume using documented pricing limits only.
How we hand over
- Handover covers the edition decision record, the cost model and the assumptions it depends on.
- For self-hosted deployments, we document the Docker, Compose or Helm setup, including its SQLite persistence limits.
- Your team receives a quote checklist naming items to confirm directly with promptfoo's sales team before purchase.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade work tracks promptfoo releases and the Node.js version each release requires, tested before rollout.
- Response expectations are written into the retainer, and promptfoo's priority support SLAs belong to its Enterprise tier.
