MW
Tutorial

WordPress 7.0 AI: Client, Abilities & Connectors

The headline feature of WordPress 7.0 is native AI in Core. Here is what the WP AI Client, the Abilities API, and the Connectors system actually mean for plugin developers.

intermediate 25 min May 20, 2026
Comfortable with WordPress hooks and the plugin API Basic familiarity with the block editor's JavaScript packages

WORDPRESS 7.0 AI

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. 1

    Request

    Your plugin calls the WP AI Client with a prompt

  2. 2

    Preference

    using_model_preference() picks models in priority order

  3. 3

    Route

    Core routes the request to a configured connector

  4. 4

    Provider

    The chosen provider runs the model

  5. 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.

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.

Google
•••••••••••••••••••• Not connected

A default provider shipped with WordPress 7.0.

Save Changes

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_key and none, 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 Action wp_connectors_init · priority 10 · 1 arg: $connectors
my-plugin.php
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-abilities to automatically fetch and register server-side abilities via the REST API.
  • Enqueue only @wordpress/abilities to 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:

  1. 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.
  2. Design for absence. AI is opt-in per site. Always handle the “no connector configured” case — feature-detect, do not assume.
  3. 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.

You've completed this tutorial!

Get the next one in your inbox. Practical tips, no fluff.

Subscribe

Get weekly notes in your inbox

Practical tips, tutorials and resources. No spam.