Make WordPress Core

Opened 6 days ago

Last modified 2 days ago

#64591 new feature request

Add WP AI Client

Reported by: flixos90's profile flixos90 Owned by:
Milestone: 7.0 Priority: normal
Severity: normal Version:
Component: AI Keywords: needs-unit-tests has-patch
Focuses: Cc:

Description (last modified by flixos90)

This ticket is for merging the WP AI Client into Core.

Technically, this means bundling the PHP AI Client as an external dependency in Core (similar to e.g. the Requests library), while the WP AI Client will become a direct part of Core. The package for the latter will most likely be discontinued after the merge.

See the merge proposal for additional context.

Change History (6)

#1 @flixos90
6 days ago

  • Description modified (diff)

This ticket was mentioned in Slack in #hosting by chaion07. View the logs.


5 days ago

#3 @schmitzoide
5 days ago

First off, this is a fantastic proposal. Having a provider-agnostic AI foundation in Core is exactly what the ecosystem needs, it will reduce fragmentation and give plugin developers a stable base to build on. Really excited to see this moving forward.

That said, I wanted to raise one potential design consideration regarding how WP AI Client might interact with the Abilities API.

The Question

If WP AI Client registers abilities like ai/prompt or ai/completion, could this create some philosophical tension?

  1. Layer confusion - Abilities typically represent "what WordPress can do". An ability to "call an AI model" feels more like external infrastructure that WordPress uses.
  1. Meta-recursion - The API was designed for AI to orchestrate WordPress. Having "invoke AI" as a discoverable ability could create circular confusion — a bit like listing "call the chef" as a menu item.
  1. Schema considerations - Abilities have deterministic schemas. AI responses are non-deterministic.
  1. Discovery implications - Plugins that auto-discover abilities might inadvertently expose "call external LLM" as a tool, confusing UX.

Possible Solutions

  • Option A: is_infrastructure metadata flag for filtering
  • Option B: Namespace convention (ai/* for internal use)
  • Option C: Keep WP AI Client as developer infrastructure without Abilities exposure

Again, great work on this proposal. Just wanted to flag this early in case it's helpful for the design. Happy to discuss further!

Last edited 5 days ago by schmitzoide (previous) (diff)

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


5 days ago

This ticket was mentioned in Slack in #hosting by amykamala. View the logs.


5 days ago

This ticket was mentioned in PR #10881 on WordPress/wordpress-develop by @jason_the_adams.


2 days ago
#6

  • Keywords has-patch added; needs-patch removed

Trac ticket: https://core.trac.wordpress.org/ticket/64591
Merge Proposal: https://make.wordpress.org/core/2026/02/03/proposal-for-merging-wp-ai-client-into-wordpress-7-0

## Summary

Adds a provider-agnostic AI Client, enabling developers to interact with generative AI services through a single, fluent API — without needing to know which provider is configured.

This PR includes three layers:

  • PHP AI Client SDK (php-ai-client): The upstream SDK from WordPress/php-ai-client, bundled into wp-includes/php-ai-client/ with all third-party dependencies (PSR interfaces, HTTPlug) scoped to WordPress\AiClientDependencies\* to avoid conflicts with plugins shipping their own versions.
  • Import tooling (tools/php-ai-client/): An installer script and PHP-Scoper configuration that fetches, scopes, and reorganizes the SDK for bundling. Running bash tools/php-ai-client/installer.sh reproduces the bundled output deterministically.
  • WP AI Client (ai-client-utils/, ai-client.php): The WordPress integration layer. This provides minimal PSR-7/PSR-17 implementations backed by string buffers and wp_parse_url(), an HTTP client adapter that routes requests through wp_remote_request(), a discovery strategy so the SDK automatically finds these implementations, and an event dispatcher that bridges PSR-14 events to WordPress hooks.

The public API is a single function:

$summary = wp_ai_client_prompt( 'Summarize this post' )
    ->with_text( $post->post_content )
    ->generate_text();

WP_AI_Client_Prompt_Builder wraps the SDK's fluent builder with WordPress conventions — snake_case methods, WP_Error returns instead of exceptions, and using_abilities() for connecting the Abilities API to AI function calling.

The wp_ai_client_prevent_prompt filter gives site owners and plugins centralized control over AI availability. When a prompt is prevented, generating methods return WP_Error while is_supported_* methods return false — giving plugin developers a graceful way to hide AI features entirely when AI is not available.

This gives plugin and theme developers a stable, provider-neutral way to add AI features without bundling their own HTTP clients or managing provider-specific SDKs.

## Follow up PRs

There will be a couple more PRs. I broke up the WP AI Client, introducing only the main core files in this one. Following PRs will be:

  • The REST API
  • The provider credentials settings screen

## Use of AI Tools

This is a compilation of work from the PHP AI Client and WP AI Client repositories, with some changes made in porting to core. Claude Code was used in both the original development of those packages as well as the porting over and creation of the tooling. All code was generated by Claude Code and reviewed by myself and @felixarntz.

Note: See TracTickets for help on using tickets.