OpenAI is acquiring Promptfoo. The announcement went out March 9, 2026, and the technology is being folded into OpenAI Frontier, OpenAI's platform for building agents. If you gate your prompts or your agent on Promptfoo in CI, the first thing you want to know is whether your pipeline is about to break.

It isn't. Here's the answer in one screen, because that's the question everyone actually has:

If you use nothing but the local CLI, you can stop reading and get back to work. The rest of this is for founders deciding whether — and toward what — to hedge.

What the acquisition actually changes#

Strip the headline and there are exactly two facts that matter to a builder.

First, the open-source core is untouched today. Promptfoo's CLI is Apache-2.0. It runs on your laptop or your CI runner, hits whatever model providers you configure, and needs no OpenAI account to score a local eval. The commercial pieces — hosted result sharing, enterprise controls — were always separate from the core, and it's the core your pipeline depends on. Nothing in that sentence changed on March 9.

Second, the direction changed. Before, Promptfoo's roadmap was steered by an independent company whose incentive was to serve every model equally — that neutrality was part of the pitch for a tool whose whole job is comparing providers. Now the steering wheel belongs to a model lab, and the natural commercial pull is toward OpenAI Frontier. Open-source projects under a single commercial owner follow that owner's incentives over time. That's not cynicism; it's how the Terraform and Redis license stories both went. The code you have is safe. The next three years of the code are now an OpenAI product decision.

For most teams, that's fine. For three specific teams, it isn't:

  1. You compete with OpenAI. You may not want a direct competitor sitting upstream of the tool that red-teams your agent.
  2. Procurement bars single-lab dependencies. Some enterprises will not let a model lab own a link in your evaluation supply chain.
  3. You were on the hosted cloud. If you relied on Promptfoo's SaaS rather than the CLI, your neutral-vendor assumption is gone and a foundation-governed platform may fit better.

If none of those describe you, staying is the correct, boring answer.

The three control models#

Once you stop comparing eval frameworks on metric count — they all have "50+ metrics" now, it stopped being a differentiator a year ago — the useful axis is who decides what the tool becomes.

The eval market no longer sorts by features. It sorts by governance: a single lab, an independent startup, or a neutral foundation.

Promptfoo — single-lab, red-team-first. Declarative YAML is its signature: you describe prompts, providers, and pass/fail assertions in promptfooconfig.yaml, and its red-teaming mode auto-generates jailbreaks, prompt injections, and PII-extraction attempts to see what breaks your guardrails. That declarative, config-as-code model is genuinely the nicest way to run a provider bake-off or an adversarial scan, and it's the reason to keep Promptfoo in the stack regardless of who owns it. Just keep the config in your repo.

DeepEval — independent, pytest-native. DeepEval treats an eval as a test. You write assert_test() calls, they run under pytest, and a failing eval fails your build like any other test. If your team already thinks in unit tests, this is the least-friction way to make evaluation a permanent CI gate rather than a thing someone runs manually before a launch. It's maintained by Confident AI — an independent startup, so still single-vendor, but not a model lab, which is exactly the distinction the acquisition made matter.

MLflow — foundation-governed, platform-scale. MLflow is the broadest of the three: OpenTelemetry-compatible tracing, built-in and LLM-as-judge metrics, prompt versioning, and an AI gateway, all on one platform with 30M+ monthly downloads. Its real differentiator now is governance — it's a Linux Foundation project, the most vendor-neutral option on the board. If the reason you're rethinking Promptfoo is precisely that you don't want a single commercial owner, MLflow is the destination that answers that objection directly.

The decision, in one rule#

Don't rip out Promptfoo. It's Apache-2.0, it's excellent at red-teaming, and leaving on principle costs you a good tool for a risk that may never land.

Do two things instead. Pin the open-source version so an upstream product decision can't move your pipeline without your say-so. And keep every eval definition in your application repo, versioned next to the code it tests — YAML for Promptfoo, test files for DeepEval, logged runs for MLflow. Do that, and switching harnesses is a mechanical port, not a migration, because the thing that's hard to move — the accumulated definition of "correct" for your product — never left your control.

The tool is a detail. The control model is the decision. Choose the one you'd be comfortable depending on after the next acquisition, because in this market there's always a next one.

Next step: the hands-on version of "keep your config in your repo" — a Promptfoo CI eval gate that runs fully self-hosted and never phones home. And for the metric-by-metric split, our earlier DeepEval vs Ragas vs Promptfoo.