---
title: "The WordPress 7.0 AI Client from a Developer's Perspective — isla Studio"
url: "https://isla-stud.io/en/allgemein/wordpress-7-ai-client-developer/"
date: 2026-03-28
---
# The WordPress 7.0 AI Client from a Developer’s Perspective
WordPress 7.0 introduces a built-in AI client. Not as a plugin, not as an experimental feature flag, but as part of the core. That’s a statement.
I’ve been developing WordPress plugins since 2009 and have built an AI plugin myself—[citelayer®](https://citelayer.ai)—that’s directly affected by this architectural decision. Here’s my technical analysis: What can the API do, what are its strengths, and what do plugin developers need to know?
The Entry Point: `wp_ai_client_prompt()`
----------------------------------------
It all starts with a single function:
```
$builder = wp_ai_client_prompt();
```
This returns a `WP_AI_Client_Prompt_Builder` object—a fluent builder that chains together the prompt, configuration, and generation method. The basic principle: The developer describes **what** they need. WordPress takes care of the **how**.
A simple example of text generation:
```
// Prompt directly as a parameter — convenient for simple cases
$text = wp_ai_client_prompt( 'Summarize the benefits of caching in WordPress.' )
->using_temperature( 0.7 )
->generate_text();
// Error handling as everywhere in WordPress: check for WP_Error
if ( is_wp_error( $text ) ) {
return;
}
echo wp_kses_post( $text );
```
The prompt text can be set as a parameter or via `with_text()` — the latter is useful when the prompt is dynamically constructed.
More Than Just Text: Images, Audio, Video
-----------------------------------
The API is multimodal. Image generation follows the same pattern:
```
use WordPress\AiClient\Files\DTO\File;
$image = wp_ai_client_prompt( 'A futuristic, neon-style WordPress logo' )
->generate_image();
if ( is_wp_error( $image ) ) {
return;
}
// File DTO with Data URI — ready to use
echo '';
```
For variations, there are `generate_images( 4 )` and `generate_texts( 4 )`. In addition, there are `convert_text_to_speech_result()`, `generate_speech_result()`, and `generate_video_result()`. WordPress thus covers all common modalities.
Particularly exciting: multimodal output in a single request:
```
use WordPress\AiClient\Messages\Enums\ModalityEnum;
// Text and images in a single response — the result contains both
$result = wp_ai_client_prompt( 'Create a recipe with photos for each step.' )
->as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
->generate_result();
```
This opens the door to plugins that generate content beyond plain text.
Feature Detection: Don’t Make Assumptions
-----------------------------------------
Not every WordPress installation will have an AI provider configured. And not every provider supports every modality. The API offers deterministic checks:
```
$builder = wp_ai_client_prompt( 'test' )
->using_temperature( 0.7 );
// No API call — purely logical check against available providers
if ( $builder->is_supported_for_text_generation() ) {
// Display UI for text generation
}
if ( $builder->is_supported_for_image_generation() ) {
// Show image generation button
}
```
This is a clean solution. The checks cost nothing—no API calls, no latency. Plugin developers can load their UI conditionally and display a helpful message if AI isn’t available. The rule: **Never assume that AI features work just because WordPress 7.0 is installed.**
Available checks: `is_supported_for_text_generation()`, `is_supported_for_image_generation()`, `is_supported_for_text_to_speech_conversion()`, `is_supported_for_speech_generation()`, `is_supported_for_video_generation()`.
Model Preferences Instead of Requirements
------------------------------------
This is where the design philosophy becomes clear:
```
$result = wp_ai_client_prompt( 'Explain the history of printing.' )
->using_temperature( 0.1 )
->using_model_preference(
'claude-sonnet-4-6',
'gemini-3.1-pro-preview',
'gpt-5.4'
)
->generate_text_result();
```
`using_model_preference()` is a **preference**, not a requirement. The AI Client uses the first available model from the list—or any compatible one if none are configured. The plugin code always works, regardless of the provider.
This is the right decision. Plugin developers should never rely on a specific model being available. The official recommendation: Sort your models so that newer ones appear before older ones. The three official provider plugins available at launch already do this.
Structured Responses with JSON Schema
---------------------------------------
For plugins that require structured data—and there are many—this is a highlight:
```
1TP4Schema = array(
'type' => 'array',
'items' => array(
'type' => 'object',
'properties' => array(
'plugin_name' => array( 'type' => 'string' ),
'category' => array( 'type' => 'string' ),
),
'required' => array( 'plugin_name', 'category' ),
),
);
$json = wp_ai_client_prompt( 'List of 5 popular WordPress plugins by category.' )
->as_json_response( $schema )
->generate_text();
// Structured data directly as an array — no manual parsing required
$data = json_decode( $json, true );
```
This is invaluable for SEO plugins, form plugins, and content analysis tools. Instead of parsing unstructured text, you get data that’s ready to use.
The Two-Layer Architecture
------------------------------
Under the hood, the AI Client consists of two layers:
1. **PHP AI Client** (`wordpress/php-ai-client`) — a provider-agnostic PHP SDK, bundled as an external library in Core. CamelCase methods, exceptions, technically independent of WordPress.
2. **WordPress Wrapper** — `WP_AI_Client_Prompt_Builder` wraps the SDK in WordPress conventions: snake_case methods, `WP_Error` instead of exceptions, integration with the WordPress HTTP transport, the Abilities API, the Connectors infrastructure, and the hook system.
This is an elegant separation. The PHP SDK can theoretically also be used outside of WordPress. The WordPress wrapper makes it idiomatic. And the `GenerativeAiResult` object is serializable and can be passed directly to `rest_ensure_response()` — REST API integration out of the box:
```
function my_rest_callback( WP_REST_Request $request ) {
$result = wp_ai_client_prompt( $request->get_param( 'prompt' ) )
->generate_text_result();
// WP_Error or GenerativeAiResult — both work
return rest_ensure_response( $result );
}
```
Granular control: The filter
-------------------------------
For security and compliance, there is `wp_ai_client_prevent_prompt`:
```
add_filter(
'wp_ai_client_prevent_prompt',
function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {
// Example: AI only for admins
if ( ! current_user_can( 'manage_options' ) ) {
return true;
}
return $prevent;
},
10,
2
);
```
When a prompt is blocked: no API call, `is_supported_*()` returns `false`, `generate_*()` returns `WP_Error`. Clean, predictable, no race conditions.
Strengths and Weaknesses
---------------------
**What’s done well:**
- Provider abstraction. Plugin developers never have to deal with API keys, rate limits, or provider-specific quirks.
- Feature detection without API calls. No guessing whether something works.
- The WordPress conventions. `WP_Error`, hooks, REST compatibility—it feels native.
- JSON Schema support. Structured responses are supported exceptionally well.
- The two-layer architecture. Clean separation between the SDK and WordPress integration.
**What I’m keeping a critical eye on:**
- Connector configuration is up to the site owner. Plugins have no control over **whether** a provider is configured. Feature detection handles this, but the UX challenge remains.
- The model landscape is evolving rapidly. It remains to be seen how well the preference list will hold up when new models are released every three months.
- Performance implications are still unclear. How does the system behave under load when 10 plugins send prompts simultaneously?
What this means for existing plugins
---------------------------------------
Every plugin that currently includes its own AI integrations faces a decision: Keep its own API connection or migrate to the AI Client?
For **SEO plugins**, the answer is clear—structured data, content analysis, and meta description generation run much more smoothly via the AI Client. For **form plugins**, this opens up the possibility of intelligent field validation and auto-fill. For **e-commerce plugins**, AI-generated product descriptions suddenly become a breeze.
For a plugin like [citelayer® – AI Visibility for WordPress](https://wordpress.org/plugins/citelayer/), which operates at the interface between WordPress and AI systems, the AI Client is a natural extension. Citelayer makes content readable for AI—through llms.txt, schema injection, bot tracking, and protocols like UCP and WebMCP. The AI Client could supplement these analysis layers with smarter, AI-powered evaluations. I’ve [discussed in more detail what this specifically means for AI visibility on the Citelayer blog](https://citelayer.ai/blog/wordpress-7-ai-client).
Not a Gadget, but Infrastructure
---------------------------------
The WordPress 7.0 AI Client isn’t a gadget. It’s infrastructure. Well-thought-out, WordPress-idiomatic, and with a clear design philosophy: The developer describes the intention; the system takes care of the execution.
Anyone developing WordPress plugins today should familiarize themselves with this API. Not because you have to—but because it’s the foundation upon which the next generation of WordPress plugins will be built.
The complete API documentation is available on the [WordPress Make Blog](https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/).