WordPress 7.0 put an AI layer in core. What that changes for the estimate
WordPress shipped something in 7.0 that changes the economics of a specific, common request: “can you add AI to this”. Not because the models got better, but because the integration stopped being bespoke.
Felix Arntz introduced it on the core development blog on 24 March 2026:
WordPress 7.0 includes a built-in AI Client — a provider-agnostic PHP API that lets plugins send prompts to AI models and receive results through a consistent interface.
Felix Arntz, Introducing the AI Client in WordPress 7.0, Make WordPress Core
Two design decisions in that announcement matter more than the feature itself.
The first: “WordPress Core does not bundle any AI providers directly. Instead, they are developed and maintained as plugins, which allows for more flexible and rapid iteration speed.” Core defines the interface and ships no vendor.
The second, for anyone who has built this by hand: “Plugin developers using the AI Client to build features do not need to handle credentials at all.”
What was expensive before
Every AI feature added to a WordPress site used to carry the same overhead, regardless of how simple the feature was. Somewhere in the codebase: an HTTP client for one vendor’s API, a way to store a key that is not a constant in wp-config.php, error handling for rate limits and timeouts, a response parser shaped to one vendor’s JSON, and a quiet dependency on that vendor’s pricing never changing.
None of that is the feature. It is the tax on the feature, and it was paid again on every project.
Worse, it was paid per vendor. Switching providers — because pricing moved, or a model was deprecated, or a client’s procurement objected to a US processor — meant rewriting the integration rather than changing a setting.
What changes
Vendor choice becomes configuration. The feature is written once against the interface; the provider arrives as a plugin. For a studio that builds for clients with different constraints — one insists on a European processor, another already pays for a particular vendor — this is the difference between a variant per client and one codebase.
Credentials become platform infrastructure. Keys stop being a thing each plugin invents a home for. That is a security improvement dressed as a convenience: the most common way an API key leaks from a WordPress site is a plugin that stored it somewhere thoughtless.
The estimate for “add AI to this” drops. Not to nothing — the feature still has to be designed, and the hard part was never the API call. But the fixed cost that used to make small AI features not worth doing is largely gone, which changes which requests are worth saying yes to.
What has not changed
A standard interface does not make the output correct, the cost predictable, or the feature a good idea. The questions that actually decide whether an AI feature is worth building are untouched: what happens when the model is confidently wrong, who is accountable for the output, what the per-request cost looks like at real traffic, and whether the user could have got there faster with a form.
There is also a governance question that arrives with the convenience. When switching providers is a setting, it can be changed by someone who does not know that the new provider processes data in another jurisdiction. If you have a privacy policy naming your processors — and you should — that policy is now one click away from being untrue.
What we would do
- Build new AI features against the AI Client, not against a vendor SDK. The abstraction costs nothing today and buys the option to switch.
- Treat the provider as a documented decision, recorded where the privacy policy can follow it, not as a dropdown someone changes quietly.
- Do not port working integrations for the sake of it. The gain is in what you build next.
Source: Felix Arntz, “Introducing the AI Client in WordPress 7.0”, Make WordPress Core, 24 March 2026.
