WordPress 7.0 is close, and the AI team’s documentation makes the integration sound simple. The v0.4.0 release of the WordPress AI Client tells a different story. There is an architectural shift buried in it that is worth understanding before you build your next plugin against it.
The team reconvened for 2026 with the focus moved off experiments and onto core readiness. What they are building is a provider-agnostic SDK that can talk to OpenAI or a local Ollama instance without dragging in a dependency mess, which is a far bigger job than bolting a chatbot onto the dashboard. I have untangled enough legacy code to know that a bad abstraction here gets paid for over the next five years.
The PHP AI Client v0.4.0 refactor
The big change is the full rewrite of the Google, Anthropic and OpenAI providers, with the team now moving to extract each one into its own repository. That helps performance more than it sounds like it should. Loading a large SDK for a provider you never call is the same bottleneck that makes all-in-one plugins slow.
The WordPress AI Client also supports PSR-14 event dispatching now, so you can hook into the generation process with actions and filters. Logging usage, stripping sensitive data out of prompts, attaching your own metadata: there is finally a standard place to do all of that. The same release adds a caching layer, which cuts repeat API calls along with the latency and cost that come with them.
<?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 in the recent meeting summary I liked: they chose to ship a solid V1 of the Abilities Explorer rather than convert it to Data Views straight away. The other priority is versionless deprecation, which in practice means updating the AI logic without breaking every site that already built against an early beta.
I have watched plenty of devs chase the newest Gutenberg UI components while the logic underneath was still held together with tape. Putting WordPress AI Client stability first is what gives WordPress 7.0 a chance of being genuinely ship-ready by the February 19th Beta 1 date.
If you are wondering how these shifts hit your current projects, my guide on Technical Debt in AI Development goes through what happens when you build on top of a moving target.
The problem with local AI (Ollama)
Support for local providers like Ollama keeps coming up, and it creates a real UX problem on multi-user sites. If the site owner runs a local model on their own machine, what happens for every other contributor? The mismatch sits in environment parity rather than in the code. For now the team is looking at how the ClassifAI plugin handles it.
If keeping up with the WordPress AI Client is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
Preparing for the merge
The WordPress 7.0 release squad is assembling, and a formal merge proposal should land on Make/Core shortly. The aim is to get the WordPress AI Client into core as a standard API the whole ecosystem can call. Plugin authors should be testing the exploratory PRs in the AI Experiments plugin now rather than after the merge.
Waiting for the final release to learn how this works costs you time you do not have. Hardcoded API wrappers are on their way out, and a standardized AI integration in core is what replaces them.
