Learning objectives
By the end of this lesson, you will be able to:
- Identify the WordPress AI Client as the shared infrastructure layer for AI requests, introduced in WordPress core version 7.0
- Explain how the AI Client routes requests from WordPress features to configured AI providers
- Trace the path of a single AI feature request through the AI Client, connector, and provider
- Evaluate how centralized AI request handling shapes governance decisions, particularly for AI Request Logging and Connector Approval
You have already seen the AI Client at work throughout this course: every time a feature generated a title, excerpt, or alt text, the AI Client was the component routing that request to your provider. This lesson explains what the AI Client actually is, how it handles that routing, and why it matters for how you configure and govern your site.
What is the WordPress AI Client?
You were introduced to the AI Client in Module 1: Lesson 1: What is WordPress AI? as one of the four AI building blocks. Here is a closer look at how it works.
The WordPress AI Client is a core WordPress component, introduced in version 7.0 “Armstrong,” that provides a unified interface for making AI requests to any configured provider. It is available on every site running WordPress 7.0 or later, with no additional plugin required.
Before the AI Client existed, every plugin that wanted AI functionality had to build its own provider integration: its own credential management, its own request handling, its own error logic. Users had to enter API keys separately for each plugin, and when a provider updated its API, every plugin that used it broke independently.
The AI Client centralizes all of that in one place.
What the AI Client handles
The AI Client sits between WordPress features and AI providers, managing everything in between.
Provider-agnostic request routing. Plugins call a single interface regardless of which provider you have configured. The AI Client translates that request into the format the provider expects and handles the response. The plugin code does not need to change when you switch providers.
Shared credential management. You configure your AI provider credentials once in Settings > Connectors. Every plugin using the AI Client can access those credentials automatically, with no additional setup per plugin.
REST API endpoints for JavaScript. The AI Client adds REST API endpoints (URL-based interfaces that allow JavaScript and other systems to access WordPress functionality) so AI capabilities are available to block editor features as well as PHP plugins. This is how features like Generate Excerpt and Title Generation make their requests from within the editor.
A consistent integration point for admin experiments. Experiments like AI Request Logging and Connector Approval operate at the AI Client layer. Because every AI request passes through the Client, these experiments apply uniformly across all features and plugins on your site.
💡 Why this matters for you: The AI Client is why configuring one connector in Settings > Connectors makes all AI features work across the plugin. It is also why switching to a different provider does not require changing settings inside each individual feature. Everything flows through the same layer.
📸 Screenshot placeholder: [Diagram showing the flow of an AI request: Feature (e.g., Generate Excerpt) AI Client Connector AI Provider Response returned through the same path]
How a request flows through your site
When you click a button like Generate Excerpt or Generate Alt Text, the following happens: the feature calls the AI Client with a request; the AI Client checks your configured connector in Settings > Connectors; it builds the request in the format that provider expects, sends it, and returns the response to the feature. From the feature’s perspective, it simply asked for text and received it. The complexity of communicating with the provider is fully handled by the Client.
How admin experiments connect to the AI Client
Because all AI requests pass through the AI Client, experiments that need to observe or control AI activity operate at this layer.
AI Request Logging records every request that passes through the Client. The log entries in Tools > AI Request Logs reflect activity at the Client itself: provider used, model, duration, token counts, and request source. (See Module 3: Lesson 3: Monitoring and controlling AI on your site [Link — verify URL before publishing])
Connector Approval uses the Client as its enforcement point. When Connector Approval is enabled, the Client checks whether the plugin or theme making the request has been approved in Tools > Connector Approvals before forwarding it. If it has not been approved, the Client blocks the request entirely. (See Module 3: Lesson 3: Monitoring and controlling AI on your site [Link — verify URL before publishing])
This architecture means you have a single place to observe and govern all AI activity on your site, regardless of how many plugins are using AI features.
For developers: making requests with the AI Client
For plugin developers, the AI Client provides a clean, minimal starting point. A provider-agnostic text generation call looks like this:
php
$text = AiClient::prompt( 'Summarize this content in one sentence.' )
->generateText();The Client handles provider selection, authentication, and response normalization automatically. To target a specific model, you can specify one explicitly, though provider-agnostic calls are recommended for broader compatibility across different user configurations:
php
$text = AiClient::prompt( 'Write a title for this post.' )
->usingModel( Google::model( 'gemini-2.5-flash' ) )
->generateText();For the full SDK reference, see the PHP AI Client on GitHub [Link — verify URL before publishing].
WordPress Playground
The AI Client has no dedicated admin interface. Its work happens behind the scenes every time an AI feature runs. You have already interacted with it in every Playground exercise throughout this course.
Key terms
| Term | Definition |
| WordPress AI Client | A core WordPress component, introduced in version 7.0, that provides a unified interface for making AI requests to any configured provider, abstracting away provider-specific implementation details |
| Provider-agnostic | Designed to work with any AI provider without being tied to a specific one; plugin code written against the AI Client works with any provider the user configures |
| REST API endpoint | A URL-based interface that allows JavaScript and other systems to access WordPress functionality over standard web requests |
| Connector | An AI provider configuration set up in Settings > Connectors, which the AI Client uses to authenticate and route requests to the appropriate AI service |
✅ Check your understanding
- Before the AI Client existed, every plugin had to build its own AI provider integration. What specific problems does centralizing this in WordPress core solve for site owners and administrators, not just developers?
- Think about the AI Request Logging and Connector Approval experiments you explored in Module 3: Lesson 3: Monitoring and controlling AI on your site [Link — verify URL before publishing]. How does knowing that both features operate at the AI Client layer change how you would configure and manage them on a production site?