AI Services

You can use the ai_services_model_params filter in PHP to customize the model parameters before they are used to retrieve a given AI service model. This filter is run consistently in any context, regardless of whether the AI model is used via PHP, JavaScript, or WP-CLI. This can be helpful, for example, if you need to inject custom model configuration parameters or a custom system instruction for a specific feature in a way that it happens dynamically on the server. Here is an example code snippet which injects a custom system instruction whenever the feature my-movie-expert is used with any google model: add_filter( 'ai_services_model_params', function ( $params, $service ) { if ( 'my-movie-expert' === $params['feature'] && 'google' === $service ) { $params['systemInstruction'] = 'You are a movie expert. You can answer questions about movies, actors, directors, and movie references.'; $params['systemInstruction'] .= ' If the user asks you about anything unrelated to movies, you should politely deny the request.'; $params['systemInstruction'] .= ' You may use famous movie quotes in your responses to make the conversation more engaging.'; } return $params; }, 10, 2 ); Note that this filter does not allow you to change the feature parameter, as that needs to be controlled by the caller.

There is a simple WordPress Assistant chatbot available as an experimental feature of the plugin, effectively acting as a proof of concept. Since the plugin is purely an infrastructure plugin that other plugins can use to access AI capabilities in WordPress, that chatbot feature is disabled by default. If you want to test or use the chatbot, you can easily enable it via filter: add_filter( 'ai_services_chatbot_enabled', '__return_true' );

The wp ai-services generate-text command streams text responses by default. This can help provide more immediate feedback to the user, since chunks with partial response candidates will be available iteratively while the model still processes the remainder of the response. An exception where it does not stream the response, but returns it all at once is if any function declarations are present. If you prefer to show the complete text response in one go instead, you can disable streaming in WP-CLI by using the ai_services_wp_cli_use_streaming filter. add_filter( 'ai_services_wp_cli_use_streaming', '__return_false' );

If you prefer to not expose the sensitive controls over the AI service API keys to the site's end users, you can programmatically specify the keys by filtering the relevant service's option value. For example, to enforce an API key to use for the Google AI service, you could use a code snippet like the following: add_filter( 'pre_option_ais_google_api_key', function () { return 'my-google-api-key'; } ); The same approach works for any other services too. Simply use the correct service slug, e.g. openai for the OpenAI integration and anthropic for the Anthropic integration.

Please see the documentation article on customizing the available plugin capabilities.

Most certainly at some point, in some form. But maybe not yet. While generative AI has been around for a few years, in the grand scheme of things we are still only scratching the surface of what's possible. But most importantly, the lack of standardization makes it difficult to consider built-in AI support in WordPress Core. WordPress Core rarely adds support for features that rely on third party services. An exception is oEmbed support for many popular services, however via the common oEmbed endpoint that each service implements there is a standard way to have it work correctly without having to individually maintain each integration. Doing so would be a maintenance burden and it would make it almost impossible to stay on top of everything: Imagine one of the services makes a change - not only would this require to manually update the WordPress Core integration, but it would also require to quickly ship a new release ASAP because otherwise the WordPress sites using the service would break. Unfortunately, there is no such standard for how generative AI APIs provided by third party services should work. In other words, if you implement support for a generative AI API in your plugin, that implementation is subject to the same concern, and it applies to the AI Services plugin too. However, by centralizing the implementation in one plugin, the problem surface is greatly reduced. And differently from WordPress Core, it's more straightforward and more reasonable to ship a quick hotfix for this plugin. The other reason that integrating generative AI in WordPress Core would be difficult is because (almost all) the services that make those APIs available require paid subscriptions. This is not well aligned with WordPress's FOSS philosophy. A promising development that may change that situation is the increasing availability of on-device models including browser built-in AI models, such as Chrome built-in AI (which is also supported by the AI Services plugin). Until the time is right for built-in AI capabilities in WordPress Core, you can use a plugin like this one. While it is for now not a WordPress Core feature plugin, it is built to potentially become one and could be considered a canonical AI plugin for WordPress: It is free, and always will be. It follows the WordPress Core philosophies. It uses WordPress UI components as much as possible. It is neutral and does not favor one AI service over another.

For regular support requests, please use the wordpress.org support forums. If you have a technical issue with the plugin where you already have more insight on how to fix it, you can also open an issue on GitHub instead.

If you have ideas to improve the plugin or to solve a bug, feel free to raise an issue or submit a pull request in the GitHub repository for the plugin. Please stick to the contributing guidelines. You can also contribute to the plugin by translating it. Simply visit translate.wordpress.org to get started.