{"id":3603,"date":"2026-03-28T07:01:41","date_gmt":"2026-03-28T06:01:41","guid":{"rendered":"https:\/\/isla-stud.io\/?p=3603"},"modified":"2026-03-28T07:01:43","modified_gmt":"2026-03-28T06:01:43","slug":"wordpress-7-ai-client-developer","status":"publish","type":"post","link":"https:\/\/isla-stud.io\/en\/allgemein\/wordpress-7-ai-client-developer\/","title":{"rendered":"The WordPress 7.0 AI client from a developer's perspective"},"content":{"rendered":"<p>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.<\/p>\n\n\n\n<p>I have been developing WordPress plugins since 2009 and have worked with <a href=\"https:\/\/citelayer.ai\" target=\"_blank\" rel=\"noopener\">citelayer\u00ae<\/a> I built an AI plugin myself that 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?<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Table of contents<\/h2><nav><ol><li><a href=\"#der-entry-point-wp-ai-client-prompt\">The entry point: wp_ai_client_prompt()<\/a><\/li><li><a href=\"#mehr-als-text-bild-sprache-video\">More than text: Image, language, video<\/a><\/li><li><a href=\"#feature-detection-keine-annahmen-treffen\">Feature Detection: Do not make any assumptions<\/a><\/li><li><a href=\"#model-preferences-statt-requirements\">Model preferences instead of requirements<\/a><\/li><li><a href=\"#strukturierte-antworten-mit-json-schema\">Structured responses with JSON schema<\/a><\/li><li><a href=\"#die-zwei-schichten-architektur\">The two-layer architecture<\/a><\/li><li><a href=\"#granulare-kontrolle-der-filter\">Granular control: The filter<\/a><\/li><li><a href=\"#starken-und-schwachen\">Strengths and weaknesses<\/a><\/li><li><a href=\"#was-das-fur-bestehende-plugins-bedeutet\">What this means for existing plugins<\/a><\/li><li><a href=\"#fazit\">Not a gadget but infrastructure<\/a><\/li><\/ol><\/nav><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"der-entry-point-wp-ai-client-prompt\">The Entry Point: <code>wp_ai_client_prompt()<\/code><\/h2>\n\n\n\n<p>It all starts with a single function:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">$builder = wp_ai_client_prompt();<\/code><\/pre>\n\n\n\n<p>This gives a <code>WP_AI_Client_Prompt_Builder<\/code>-object - a Fluent Builder via which the prompt, configuration and generation method are linked. The basic principle: The developer describes, <strong>what<\/strong> he needs. WordPress takes care of the <strong>how<\/strong>.<\/p>\n\n\n\n<p>A simple example of text generation:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">\/\/ Prompt directly as a parameter - convenient for simple cases\n$text = wp_ai_client_prompt( 'Summarize the benefits of caching in WordPress.' )\n    -&gt;using_temperature( 0.7 )\n    -&gt;generate_text();\n\n\/\/ Error handling as everywhere in WordPress: Check WP_Error\nif ( is_wp_error( $text ) ) {\n    return;\n}\n\necho wp_kses_post( $text );<\/code><\/pre>\n\n\n\n<p>The prompt text can be set as a parameter or via <code>with_text()<\/code> can be set - the latter is useful if the prompt is assembled dynamically.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"mehr-als-text-bild-sprache-video\">More than text: Image, language, video<\/h2>\n\n\n\n<p>The API is multimodal. Image generation works according to the same pattern:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">use WordPress\\AiClient\\Files\\DTO\\File;\n\n$image = wp_ai_client_prompt( &#039;A futuristic WordPress logo in neon style&#039; )\n    -&amp;gt;generate_image();\n\nif ( is_wp_error( $image ) ) {\n    return;\n}\n\n\/\/ File DTO with Data URI - directly usable\necho &#039;&lt;img src=&quot;&#039; . esc_url( $image-&gt;getDataUri() ) . &#039;&quot; data-no-translation=&quot;&quot; data-no-auto-translation=&quot;&quot;&gt;&#039;;<\/code><\/pre>\n\n\n\n<p>For variations there are <code>generate_images( 4 )<\/code> and <code>generate_texts( 4 )<\/code>. In addition <code>convert_text_to_speech_result()<\/code>, <code>generate_speech_result()<\/code> and <code>generate_video_result()<\/code>. WordPress covers all common modalities.<\/p>\n\n\n\n<p>Particularly exciting: multimodal output in a single request:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">use WordPress\\AiClient\\Messages\\Enums\\ModalityEnum;\n\n\/\/ Text and images in one response - the result contains both\n$result = wp_ai_client_prompt( 'Create a recipe with photos for each step.' )\n    -&gt;as_output_modalities( ModalityEnum::text(), ModalityEnum::image() )\n    -&gt;generate_result();<\/code><\/pre>\n\n\n\n<p>This opens the door to plugins that generate content that goes beyond pure text.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"feature-detection-keine-annahmen-treffen\">Feature Detection: Do not make any assumptions<\/h2>\n\n\n\n<p>Not every WordPress installation will have an AI provider configured. And not every provider supports every modality. The API offers deterministic checks:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">$builder = wp_ai_client_prompt( 'test' )\n    -&gt;using_temperature( 0.7 );\n\n\/\/ No API call - purely logical check against available providers\nif ( $builder-&gt;is_supported_for_text_generation() ) {\n    \/\/ Display UI for text generation\n}\n\nif ( $builder-&gt;is_supported_for_image_generation() ) {\n    \/\/ Show image generation button\n}<\/code><\/pre>\n\n\n\n<p>It's 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: <strong>Never assume that AI features will work just because WordPress 7.0 is installed.<\/strong><\/p>\n\n\n\n<p>Available checks: <code>is_supported_for_text_generation()<\/code>, <code>is_supported_for_image_generation()<\/code>, <code>is_supported_for_text_to_speech_conversion()<\/code>, <code>is_supported_for_speech_generation()<\/code>, <code>is_supported_for_video_generation()<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"model-preferences-statt-requirements\">Model preferences instead of requirements<\/h2>\n\n\n\n<p>The design philosophy becomes clear here:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">$result = wp_ai_client_prompt( 'Explain the history of printing.' )\n    -&gt;using_temperature( 0.1 )\n    -&gt;using_model_preference(\n        'claude-sonnet-4-6',\n        'gemini-3.1-pro-preview',\n        'gpt-5.4'\n    )\n    -&gt;generate_text_result();<\/code><\/pre>\n\n\n\n<p><code>using_model_preference()<\/code> is a <strong>Preference<\/strong>, no 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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"strukturierte-antworten-mit-json-schema\">Structured responses with JSON schema<\/h2>\n\n\n\n<p>This is a highlight for plugins that require structured data - and there are many of them:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">$schema = array(\n    'type' =&gt; 'array',\n    'items' =&gt; array(\n        'type' =&gt; 'object',\n        'properties' =&gt; array(\n            'plugin_name' =&gt; array( 'type' =&gt; 'string' ),\n            'category' =&gt; array( 'type' =&gt; 'string' ),\n        ),\n        'required' =&gt; array( 'plugin_name', 'category' ),\n    ),\n);\n\n$json = wp_ai_client_prompt( 'List 5 popular WordPress plugins with category.' )\n    -&gt;as_json_response( $schema )\n    -&gt;generate_text();\n\n\/\/ Structured data directly as an array - no manual parsing required\n$data = json_decode( $json, true );<\/code><\/pre>\n\n\n\n<p>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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"die-zwei-schichten-architektur\">The two-layer architecture<\/h2>\n\n\n\n<p>Under the hood, the AI Client consists of two levels:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>PHP AI Client<\/strong> (<code>wordpress\/php-ai-client<\/code>) - a provider-agnostic PHP SDK, bundled as an external library in Core. CamelCase methods, exceptions, technically WordPress-independent.<\/li>\n\n\n\n<li><strong>WordPress Wrapper<\/strong> \u2014 <code>WP_AI_Client_Prompt_Builder<\/code> develops the SDK in WordPress conventions: snake_case methods, <code>WP_Error<\/code> instead of exceptions, integration with WordPress HTTP Transport, Abilities API, Connectors infrastructure and the hook system.<\/li>\n<\/ol>\n\n\n\n<p>This is an elegant separation. The PHP SDK can theoretically also be used outside of WordPress. The WordPress wrapper makes it idiomatic. And that <code>GenerativeAiResult<\/code>-object can be serialized and can be connected directly to <code>rest_ensure_response()<\/code> REST API integration out of the box:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">function my_rest_callback( WP_REST_Request $request ) {\n    $result = wp_ai_client_prompt( $request-&gt;get_param( 'prompt' ) )\n        -&gt;generate_text_result();\n\n    \/\/ WP_Error oder GenerativeAiResult \u2014 beides funktioniert\n    return rest_ensure_response( $result );\n}<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"granulare-kontrolle-der-filter\">Granular control: The filter<\/h2>\n\n\n\n<p>For security and compliance there are <code>wp_ai_client_prevent_prompt<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code class=\"\">add_filter(\n    'wp_ai_client_prevent_prompt',\n    function ( bool $prevent, WP_AI_Client_Prompt_Builder $builder ): bool {\n        \/\/ Example: AI for admins only\n        if ( ! current_user_can( 'manage_options' ) ) {\n            return true;\n        }\n        return $prevent;\n    },\n    10,\n    2\n);<\/code><\/pre>\n\n\n\n<p>If a prompt is blocked: no API call, <code>is_supported_*()<\/code> gives <code>false<\/code> back, <code>generate_*()<\/code> supplies <code>WP_Error<\/code>. Clean, predictable, no race conditions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"starken-und-schwachen\">Strengths and weaknesses<\/h2>\n\n\n\n<p><strong>Which is a good solution:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The provider abstraction. Plug-in developers never have to deal with API keys, rate limits or provider peculiarities.<\/li>\n\n\n\n<li>Feature detection without API calls. No guessing whether something works.<\/li>\n\n\n\n<li>The WordPress conventions. <code>WP_Error<\/code>, hooks, REST compatibility - it feels native.<\/li>\n\n\n\n<li>JSON schema support. Structured responses are supported first class.<\/li>\n\n\n\n<li>The two-tier architecture. Clean separation between SDK and WordPress integration.<\/li>\n<\/ul>\n\n\n\n<p><strong>What I observe critically:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The site owner is responsible for the connector configuration. Plugins have no influence on this, <strong>whether<\/strong> a provider is configured. Feature Detection catches this, but the UX challenge remains.<\/li>\n\n\n\n<li>The model landscape is moving fast. It remains to be seen how well the preference list will age when new models appear every three months.<\/li>\n\n\n\n<li>Performance implications are still unclear. How does the system behave under load when 10 plugins send prompts at the same time?<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"was-das-fur-bestehende-plugins-bedeutet\">What this means for existing plugins<\/h2>\n\n\n\n<p>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?<\/p>\n\n\n\n<p>For <strong>SEO plugins<\/strong> the answer is clear - structured data, content analysis and meta description generation run much more cleanly via the AI client. For <strong>Form plugins<\/strong> opens up intelligent field validation and auto-fill. For <strong>E-commerce plugins<\/strong> AI-generated product descriptions suddenly become trivial.<\/p>\n\n\n\n<p>For a plugin like <a href=\"https:\/\/wordpress.org\/plugins\/citelayer\/\" target=\"_blank\" rel=\"noreferrer noopener\">citelayer\u00ae - AI Visibility for WordPress<\/a>, 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 what this means in concrete terms for AI Visibility <a href=\"https:\/\/citelayer.ai\/blog\/wordpress-7-ai-client\" target=\"_blank\" rel=\"noopener\">in more detail in the Citelayer blog<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fazit\">Not a gadget but infrastructure<\/h2>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>The complete API documentation is available on the <a href=\"https:\/\/make.wordpress.org\/core\/2026\/03\/24\/introducing-the-ai-client-in-wordpress-7-0\/\" target=\"_blank\" rel=\"noopener\">WordPress Make Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"<p>The WordPress 7.0 AI client in a developer deep-dive: API architecture, code examples, feature detection and what this means for existing plugins. From a plugin developer who's been at it since 2009.<\/p>","protected":false},"author":1,"featured_media":3606,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"off","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[1,754],"tags":[],"dipi_cpt_category":[],"class_list":["post-3603","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-allgemein","category-ki-b2b"],"acf":[],"_links":{"self":[{"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/posts\/3603","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/comments?post=3603"}],"version-history":[{"count":2,"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/posts\/3603\/revisions"}],"predecessor-version":[{"id":3607,"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/posts\/3603\/revisions\/3607"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/media\/3606"}],"wp:attachment":[{"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/media?parent=3603"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/categories?post=3603"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/tags?post=3603"},{"taxonomy":"dipi_cpt_category","embeddable":true,"href":"https:\/\/isla-stud.io\/en\/wp-json\/wp\/v2\/dipi_cpt_category?post=3603"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}