WordPress 7.0 is set to change how plugins reach external services, generative models above all. Merging the WP AI Client into Core hands the ecosystem a standardized infrastructure layer, which is something plugin authors have wanted for years. I have spent over a decade untangling messy plugin integrations, so I read this as a stability win before I read it as an AI feature.
If you have followed the evolution of WordPress Core AI, you know the goal is developer infrastructure rather than a proprietary chatbot. The WP AI Client is a provider-agnostic API: your code calls models like GPT-4, Claude, or a local LLM through one interface. HTTP transport, caching and credential storage sit behind that interface, so a plugin no longer has to ship its own half-finished SDK.
Why the WP AI Client matters for architecture
Fragmentation is the bottleneck right now. Every plugin author decides on their own where to store API keys, how to handle rate limits, and which transport layer to use. You end up with three different OpenAI clients on one site, all competing for the same resources. A Core WP AI Client replaces that with a single registry.
The merge brings a PHP API along with a REST and JS layer for the browser. That means you can build a feature that uses AI without knowing whether the site owner runs OpenAI, Anthropic, or a model on their own hardware. Your code talks to the abstraction and the abstraction deals with the provider.
<?php
/**
* Example of how a developer might check for AI capabilities
* using the proposed Core infrastructure.
*/
function bbioon_check_ai_readiness() {
// Check if the site has a configured AI provider
if ( function_exists( 'wp_ai_get_client' ) && wp_ai_get_client()->has_provider() ) {
// Specifically check if the provider supports the 'text-generation' ability
if ( wp_ai_get_client()->supports_ability( 'text-generation' ) ) {
return true;
}
}
return false;
}
The “Connectors” shift and performance concerns
The roadmap then took a turn in the discussion on Trac ticket #64591. Matt Mullenweg pushed for a wider “Connectors” settings page: one central keychain for every external API connection, AI or otherwise. That adds work to the 7.0 release, but it is the sensible long game. It pushes WordPress closer to an operating system for the web instead of only a CMS.
Package size has drawn its own debate. Roughly 16K lines of code, most of it third-party dependencies, is a lot to add if you spend your days chasing milliseconds. Felix Arntz noted in the proposal that most of it lives in wp-includes and only costs anything when something actually invokes it. Core bloat is a fair worry, though a stable API for the next decade of the web buys back those few megabytes in the zip.
If the WP AI Client work is eating your dev hours, or you are unsure how 7.0 lands on your custom stack, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
Final take on the 7.0 roadmap
Without something like the WP AI Client in the middle, the ecosystem keeps splintering into one-off integrations. This proposal puts privacy (no outbound calls by default) and security (capability-gated secrets) at the foundation instead of leaving both to each plugin author. I will be watching the official GitHub repository as the first beta gets closer. If you are planning further out, we also have a guide on preparing for WordPress 7.0.
