WordPress 7.0 is shaping up to be a defining moment for how we handle external services, specifically generative models. The proposal to merge the WP AI Client into Core isn’t just about adding “AI” for the sake of the buzzword; it’s about building a standardized infrastructure layer that we’ve desperately needed for years. As someone who has spent over a decade refactoring messy plugin integrations, I see this as a huge win for stability.
If you’ve been following the evolution of WordPress Core AI, you know the goal isn’t to ship a proprietary chatbot. Instead, the WP AI Client serves as developer infrastructure—a provider-agnostic API that allows your code to call models like GPT-4, Claude, or local LLMs through a consistent interface. It handles the heavy lifting like HTTP transport, caching, and credentials storage, so every plugin doesn’t have to ship its own half-baked SDK.
Why the WP AI Client Matters for Architecture
The primary bottleneck in the current ecosystem is fragmentation. Every plugin author currently has to decide how to store API keys, how to handle rate limits, and which transport layer to use. Consequently, we end up with three different OpenAI clients on one site, all competing for resources. The Core WP AI Client changes this by providing a unified registry.
Specifically, this merge introduces a robust PHP API and a browser-friendly REST/JS layer. For developers, this means you can build “AI-ready” features without knowing if the end user is using OpenAI, Anthropic, or an on-site model. You simply interact with the standardized abstraction layer.
<?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
However, the roadmap took an interesting turn during the discussion on Trac ticket #64591. Matt Mullenweg recently pushed for a broader “Connectors” settings page. This would create a centralized “keychain” for all external API connections, not just AI. While this adds complexity to the 7.0 release, it’s a pragmatic long-term play. It moves WordPress closer to being an operating system for the web rather than just a CMS.
Furthermore, there’s been a healthy debate about package size. Adding roughly 16K lines of code (mostly third-party dependencies) is a concern for those of us obsessed with performance. But as Felix Arntz pointed out in the proposal, much of this is bundled in wp-includes and only impacts the site when actively invoked. We need to be careful not to create “Core bloat,” but providing a stable API for the future of the web is worth a few extra megabytes in the zip file.
Look, if this WP AI Client stuff is eating up your dev hours or you’re worried about how 7.0 will affect your custom stack, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Take on the 7.0 Roadmap
Standardization is the only way forward. Without a centerpiece like the WP AI Client, the WordPress ecosystem would continue to fragment. This proposal ensures that privacy (no outbound calls by default) and security (capability-gated secrets) are handled at the foundation level. I strongly recommend keeping an eye on the official GitHub repository as we approach the first beta. For more on high-level strategy, check out our guide on preparing for WordPress 7.0.
