---
title: The WordPress 7.0 AI Client from a developer 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 brings a built-in AI client. Not as a plugin, not as an experimental feature flag, but as part of the core. That is a statement.



I've been developing WordPress plugins since 2009 and have built an AI plugin myself, citelayer®, which is directly affected by this architectural decision. Here is my technical analysis: What can the API do, what are its strengths, and what do plugin developers need to know?



Table of contents



The entry point: wp_ai_client_prompt()



Everything starts with a single function:



$builder = wp_ai_client_prompt();



This returns a WP_AI_Client_Prompt_Builder object - a Fluent Builder via which the prompt, configuration and generation method are linked. The basic principle: The developer describes what they need. WordPress takes care of the how.



A simple example of text generation:



// Prompt directly as 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 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 if the prompt is assembled dynamically.



More than text: Image, speech, video



The API is multimodal. Image generation works according to the same pattern:



use WordPress\AiClient\Files\DTO\File;

$image = wp_ai_client_prompt( 'A futuristic WordPress logo in neon style' )
    ->generate_image();

if ( is_wp_error( $image ) ) {
    return;
}

// File DTO with Data URI - directly usable
echo '<img src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" data-src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" decoding="async" class="lazyload" data-no-translation="" data-no-auto-translation=""><noscript><img src="' . esc_url( $image-&gt;getDataUri() ) . '" data-eio="l" data-no-translation="" data-no-auto-translation=""></noscript>';



For variations, there are generate_images( 4 ) and generate_texts( 4 ). There are also 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 one response - the result contains both
$result = wp_ai_client_prompt( 'Create a recipe with photos for each step.' )
    -&gt;as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )
    -&gt;generate_result();



This opens the door for plugins that generate content that goes beyond pure text.



Feature detection: make no 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' )
    -&gt;using_temperature( 0.7 );

// No API call - purely logical check against available providers
if ( $builder-&gt;is_supported_for_text_generation() ) {
    // Display UI for text generation
}

if ( $builder-&gt;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 show a helpful hint if no AI is available. The rule: Never assume that AI features will 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



The design philosophy becomes clear here:



$result = wp_ai_client_prompt( 'Explain the history of letterpress printing.' )
    -&gt;using_temperature( 0.1 )
    -&gt;using_model_preference(
        'claude-sonnet-4-6',
        'gemini-3.1-pro-preview',
        'gpt-5.4'
    )
    -&gt;generate_text_result();



using_model_preference() is a preference, not a requirement. The AI client takes the first available model from the list - or any compatible one if none is configured. The plugin code always works, regardless of the provider.



This is the right decision. Plugin developers should never depend on a specific model being available. The official recommendation is to sort your models so that newer ones come before older ones. The three official provider plugins for the launch already do this.



Structured responses with JSON schema



This is a highlight for plugins that require structured data - and there are many of them:



$schema = array(
    'type' =&gt; 'array',
    'items' =&gt; array(
        'type' =&gt; 'object',
        'properties' =&gt; array(
            'plugin_name' =&gt; array( 'type' =&gt; 'string' ),
            'category' =&gt; array( 'type' =&gt; 'string' ),
        ),
        'required' =&gt; array( 'plugin_name', 'category' ),
    ),
);

$json = wp_ai_client_prompt( 'List 5 popular WordPress plugins with category.' )
    -&gt;as_json_response( $schema )
    -&gt;generate_text();

// Structured data directly as an array - no manual parsing required
$data = json_decode( $json, true );



This is worth its weight in gold for SEO plugins, form plugins and content analysis tools. Instead of parsing unstructured text, you get directly usable data.



The two-layer architecture



Under the hood, the AI Client consists of two layers:




PHP AI Client (wordpress/php-ai-client) - a provider-agnostic PHP SDK, bundled as an external library in Core. CamelCase methods, exceptions, technically WordPress-independent.



WordPress Wrapper - WP_AI_Client_Prompt_Builder wraps the SDK in WordPress conventions: snake_case methods, WP_Error instead of exceptions, integration with WordPress HTTP Transport, Abilities API, 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-&gt;get_param( 'prompt' ) )
        -&gt;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 for admins only
        if ( ! current_user_can( 'manage_options' ) ) {
            return true;
        }
        return $prevent;
    },
    10,
    2
);



If a prompt is blocked: no API call, is_supported_*() returns false, generate_*() returns WP_Error. Clean, predictable, no race conditions.



Strengths and weaknesses



What is well solved:




The provider abstraction. Plug-in developers never have to deal with API keys, rate limits or provider peculiarities.



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 first class.



The two-tier architecture. Clean separation between SDK and WordPress integration.




What I observe critically:




The connector configuration lies with the site owner. Plugins have no influence on whether a provider is configured. Feature Detection catches this, but the UX challenge remains.



The model landscape is moving fast. How well the preference list ages when new models appear every three months remains to be seen.



Performance implications are still unclear. How does the system behave under load when 10 plug-ins send prompts at the same time?




What this means for existing plugins



Every plugin that currently has its own AI integrations is faced with a decision: Keep your 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 cleanly via the AI client. For form plugins, intelligent field validation and auto-fill are opening up. For e-commerce plugins, AI-generated product descriptions suddenly become trivial.



For a plugin like citelayer® - AI Visibility for WordPress, which works 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 such as UCP and WebMCP. The AI Client could supplement these analysis layers with more intelligent, AI-supported evaluations. I have explained in more detail what this means for AI Visibility in the Citelayer blog.



Not a gadget but infrastructure



The WordPress 7.0 AI Client is not a gadget. It is 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 is the foundation on which the next generation of WordPress plugins will be built.



The complete API documentation is available on the WordPress Make blog.