WordPress 7.0 is fast approaching, and the official documentation for the AI team’s progress makes the integration look straightforward. However, if you dig into the recent v0.4.0 update of the WordPress AI Client, there’s a major architectural shift you need to understand before you start building your next plugin.
The team recently reconvened for 2026, and the focus has shifted from “experiments” to “core readiness.” This isn’t just about adding a chatbot to the dashboard; it’s about building a provider-agnostic SDK that can handle anything from OpenAI to local Ollama instances without creating a dependency nightmare. I’ve spent enough time untangling legacy code to know that if we don’t get the abstraction right now, we’ll be paying for it for the next five years.
The PHP AI Client v0.4.0 Refactor
The standout update is the full rewrite of the Google, Anthropic, and OpenAI providers. Consequently, the team is moving toward extracting these into separate repositories. This is a brilliant move for performance. Loading a massive SDK for a provider you aren’t using is a classic performance bottleneck we see in bloated “all-in-one” plugins.
More importantly, the WordPress AI Client now supports PSR-14 event dispatching. This allows developers to hook into the generation process using actions and filters. If you need to log usage, filter prompts for sensitive data, or inject custom metadata, you finally have a standard way to do it. Specifically, the addition of a caching layer in this version will prevent redundant API calls, saving both latency and budget.
<?php
/**
* Example of hooking into the new Event Dispatching
* in the WordPress AI Client (v0.4.0+).
*/
add_action( 'bbioon_before_ai_generation', function( $event ) {
$model = $event->getModel();
$messages = $event->getMessages();
// Log the request for auditing or modify the prompt
error_log( "AI Request sent to model: " . $model );
} );
Stability Over Shiny UI
One detail from the recent meeting summary that I appreciated was the decision to prioritize a solid V1 for the “Abilities Explorer” over converting it to Data Views immediately. Furthermore, the focus is on “versionless deprecation.” In plain English: making sure that when we update the AI logic, we don’t break every site that implemented the early beta versions.
This is a lesson in project management. I’ve seen too many devs get distracted by the latest Gutenberg UI components while the underlying logic is still fragile. By focusing on the WordPress AI Client stability first, the team is ensuring that the foundation for WordPress 7.0 is actually ship-ready by the February 19th Beta 1 target.
If you’re worried about how these architectural shifts might affect your current projects, you should check out my guide on Technical Debt in AI Development. It covers the pitfalls of building on top of moving targets.
The Challenge of Local AI (Ollama)
There is growing interest in supporting local providers like Ollama. However, this introduces a significant UX challenge for multi-user sites. If a site owner enables a local model on their machine, how does that translate to other contributors? The “race condition” here isn’t in the code, but in the environment parity. For now, the team is looking at existing solutions like the ClassifAI plugin for inspiration on how to bridge this gap.
Look, if this WordPress AI Client stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Preparing for the Merge
The next few weeks are critical. With the release squad for WordPress 7.0 assembling, we’re going to see a formal merge proposal on Make/Core soon. The goal is to get the WordPress AI Client into the core so it can be used as a standardized API for the entire ecosystem. Therefore, if you are a plugin author, now is the time to start testing the exploratory PRs in the AI Experiments plugin.
Stop waiting for the final release to learn how this works. The era of hardcoded API wrappers is over; the era of standardized WordPress AI integration is here. Ship it.
