The headline of WordPress 7.0 is simple to say and large to absorb: AI is now part of Core. Not a plugin, not a hosted add-on — a set of APIs in WordPress itself that any plugin can build on. This is the feature the rest of the release is quietly organised around, and it is the one most worth understanding early.
This tutorial walks through the four building blocks as a developer needs them: what each one is, how they fit together, and where your own code plugs in.
The four building blocks
WordPress 7.0’s AI layer is not one feature. It is four, and they stack:
- WP AI Client
- Abilities API
- Connectors Screen
- Connectors API
The WP AI Client is the interface your plugin code calls. The Abilities API describes what the AI can do. The Connectors Screen is where the site owner manages provider credentials. The Connectors API is the extensibility layer underneath that screen. Understand those four roles and the rest is detail.
1. The WP AI Client
The WP AI Client is a central interface that lets plugins talk to generative AI models while staying provider-agnostic. Your plugin does not call OpenAI or Anthropic directly. It calls the client; WordPress Core handles request routing to whichever provider the site has configured.
This is the important architectural idea. The provider is a site-owner decision, not a plugin decision. The same plugin code runs against Anthropic on one site and Google on another, with no code change.
- 1
Request
Your plugin calls the WP AI Client with a prompt
- 2
Preference
using_model_preference() picks models in priority order
- 3
Route
Core routes the request to a configured connector
- 4
Provider
The chosen provider runs the model
- 5
Response
The result returns through the client, provider-agnostic
Two pieces of the client are worth knowing by name. The using_model_preference() function lets a plugin declare which models it wants, in order of preference — then feature detection matches those preferences against the models the site actually has available. The practical effect is lower cost and faster processing: you ask for the cheapest model that can do the job, and fall back gracefully when it is not configured.
For building the request itself, the client provides a WP_AI_Client_Prompt_Builder class with methods for assembling a call. And for the migration path, the wordpress/wp-ai-client package handles the transition to 7.0 automatically — if you adopt the package, upgrades are managed for you.
2. The Connectors screen and API
If the AI Client is how plugins use AI, the Connectors system is how site owners configure it. WordPress 7.0 adds a dedicated screen at Settings → Connectors.
Connectors
Manage the AI providers WordPress can route requests to. Registered connectors appear here automatically.
| Anthropic | •••••••••••••••••••• Connected A default provider shipped with WordPress 7.0. |
|---|---|
| OpenAI | •••••••••••••••••••• Connected A default provider shipped with WordPress 7.0. |
| •••••••••••••••••••• Not connected A default provider shipped with WordPress 7.0. |
The screen ships with three default providers — Anthropic, Google, and OpenAI — and site owners can configure their own connections beyond those. Registered connectors are displayed automatically, along with their registry metadata in a card layout.
Underneath the screen is the Connectors API — the extensibility layer, and the part you will touch if you are a plugin developer rather than a site owner. A few things define it:
- It supports two authentication methods,
api_keyandnone, chosen based on a provider’s metadata. - It uses the WP AI Client’s default registry to auto-discover providers and generate connectors from their metadata.
- It exposes three public functions for querying the registry.
- It is explicitly designed to support additional connector types — including agents — in future releases.
The hook to know is wp_connectors_init. It is how you register a new connector type or override the metadata of an existing one:
wp_connectors_init · priority 10 · 1 arg: $connectors add_action( 'wp_connectors_init', function ( $connectors ) {
// Override metadata for an existing connector,
// or register a new connector type.
// wp_connectors_init is the key extension point
// for connector registration in future releases.
} ); 3. The Client-Side Abilities API
The Abilities API describes what the AI can do — discrete, named capabilities the AI Client can invoke. WordPress 7.0 expands it with a JavaScript counterpart: the Client-Side Abilities package, which brings new and hybrid abilities, a UI, command-palette integration, and filter and query functionality.
There are two packages, and which you enqueue depends on what you need:
- Enqueue
@wordpress/core-abilitiesto automatically fetch and register server-side abilities via the REST API. - Enqueue only
@wordpress/abilitiesto work purely with a plugin’s client-side abilities.
Registered abilities are organised into customizable categories. Both abilities and categories can be unregistered through the PHP API, metadata annotation is supported, and core/abilities makes useSelect available so you can run reactive ability queries inside React components — the same data-store pattern the block editor already uses.
import { useSelect } from '@wordpress/data';
function AbilityList() {
const abilities = useSelect(
( select ) => select( 'core/abilities' ).getAbilities(),
[]
);
// Render the abilities available on this site.
}
The Abilities API is also integrated directly into the WP AI Client — which is what makes “agentic” workflows possible: abilities can be chained, running one after another inside a single workflow.
What this means for your plugin
If you maintain a plugin, three takeaways matter:
- You no longer ship provider integrations. Drop bespoke OpenAI or Anthropic HTTP code and call the WP AI Client. Less code, no key handling, no provider lock-in.
- Design for absence. AI is opt-in per site. Always handle the “no connector configured” case — feature-detect, do not assume.
- Think in abilities. If your plugin exposes something an AI could usefully do, registering it as an ability makes it available to agentic workflows across the whole site.
What’s next
The AI layer is the deepest single change in 7.0, but it is not the most visible one. Next in this series: the modernized dashboard — the new admin theme, the command palette, the font library, and the visual revisions tools that every site owner will notice on day one.
Get the next one in your inbox. Practical tips, no fluff.
More tutorials
View all- WordPress
How to Prepare Your Plugin or Theme for WordPress 7.0
A step-by-step compatibility process for shipping a WordPress 7.0-ready release — set up a test site, audit your blocks, fix the breaking changes, and ship with confidence.
22 min
- WordPress
WordPress 7.0 for Block Developers: Breaking Changes
WordPress 7.0 enforces the iframed editor, broadens contentOnly mode, and drops PHP 7.3. Here are the breaking changes block and plugin developers must fix before users upgrade.
25 min
- WordPress
WordPress 7.0 Developer APIs
PHP-only block registration, the Interactivity API's new watch() function, DataViews and DataForms, Block Bindings iterations — the new developer APIs in WordPress 7.0.
25 min