A single config option to disable all LLM related features

[romainmrhenry]

We would like to have a single config option to communicate to both WordPress Core and Plugins that we don't want any LLM related features to be enabled.

Plugins can't be forced to respect this preference. But if it doesn't exist then they also won't respect it.

LLM's are not uncontroversial and not everyone wants affordances for these systems in their site software.
Being able to simply disable it with one setting will be very useful.

This PR adds a wp_supports_ai() function, alongside a WP_DISABLE_AI constant, and wp_supports_ai filter.

When false,

• The Connectors screen will be unhooked
• _wp_connectors_get_provider_settings() will return an empty array (shortcircuiting the other functionality)
• WP_AI_Client_Prompt_Builder() will short-circuit the construction with a WP_Error() (wp_ai_client_prompt()` will still return an instance, to allow for fluidity to remain intact.

Priority: WP_DISABLE_AI > add_filter( 'wp_supports_ai', ...), true`

### Not Included

Using wp_supports_ai() to gate the loading of wp-ai-client or php-ai-client _classes_. This is to maintain the current usage for developers, and not require folks to rewrite their compatibility yet again.

Trac ticket: https://core.trac.wordpress.org/ticket/64706

## Use of AI Tools

• GitHub Copilot Autocompletions (GPT-5 mini) via VSCode (primarily for doc blocks)
• OpenAI Codex + GPT-5.3-codex (medium thinking) for code review.

[justlevine]

To me this reads as a bug, since the original planned implementation for WP 7.0 disabled everything - UI included - when no AI Providers were installed. However, the new Connectors screen in https://core.trac.wordpress.org/ticket/64591 in beta2 changes that expectation since discovery is no longer proactive.

I took a stab at adding a function + matching constant (so 3rd-party plugins/malicious actors can't override with a late-priority hook) and filter in ​https://github.com/WordPress/wordpress-develop/pull/11149 . Tried to do it in a way that would be the least disruptive to both wp-ai-client itself, and compliment @gziolo 's ongoing work in https://core.trac.wordpress.org/ticket/64730 , but Fluent APIs aren't really typical in WordPress and I'm open to other suggestions.

Original ref: ​https://github.com/WordPress/wp-ai-client/issues/38

[justlevine]

on todays contributor call, @flixos90 noted the existing filter in the prompt builder class: ​https://github.com/WordPress/wordpress-develop/blob/707fa78322968b590e84b29d0575de65dc785b2c/src/wp-includes/ai-client/class-wp-ai-client-prompt-builder.php#L291 so it's just the UI aspect that needs disabling in the connector screen, which we can wrap and repurpose the same filter for.

Will update my PR accordingly - unless someone beats me to it.

[justlevine]

Related: ​https://github.com/WordPress/ai/pull/268 shows how wp_supports_ai() is used to short-circuit loading Experiments

Even when the constant is defined, should it not still go through the filter? The constant becomes the default value. This would align with WP_POST_REVISIONS is filterable by wp_revisions_to_keep. Likewise, the CONCATENATE_SCRIPTS constant is the default value for the $concatenate_scripts global.

No this is intentionally

Even when the constant is defined, should it not still go through the filter? The constant becomes the default value.

Even when the constant is defined, should it not still go through the filter?

The order here is intentional, as unlike those config examples we don't want a 3rd party to be able to override the value. If I turn AI off, then I don't want SomeSeoPlugin or MyCommerce to override it, and it also offers protection against malicious behavior.

Resolved the merge conflicts from ​https://github.com/WordPress/wordpress-develop/pull/11175 and the new Registry, but didn't have time to update the test. If someone is free and can do it please go ahead.

[chrismcelroyseo]

Yes, please add the kill switch. All I need is for clients to start making changes because they think they "understand" AI.

[sabernhardt]

To be included in 7.0, this should have at least one commit before RC1 next week (for any new translatable string).

[ahortin]

Agree with what others have mentioned, there needs to be a single Kill Switch to completely disable ALL AI functionality. This includes screens like the newly added Settings > Connectors screen added in the recent WP 7.0beta, along with all UI components anywhere else in core (if there are any). A hook or filter that simply restricts a prompt execution, which was mentioned over on the ​wp-ai-client repo, is far from an adequate solution.

If the WP AI Client is being made part of core, then this kill switch also needs to built into the core settings pages as well, rather than forcing people to implement a solution through hooks or filters in a plugin or theme. While a constant in wp-config would also work, ideally, it really should be part of the main Dashboard UI. There are a significant portion of WordPress users who aren't comfortable editing PHP files, even when it's just to add a simple switch. This solution also needs to roll out with WP 7.0 if the AI Client is rolling out in 7.0. It's not good enough to say that it'll be implemented at a later date.

Per today's call I've updated the PR so that the filter can now override the constant, so that we can get this PR (and the new translation strings) merged in time for RC1.

That said, the consensus on the call was that this is invalid and buggy behavior that should be fixed during the RC period, we're just giving @felixarntz and other committers more time to reply. To tl;dr it:

1. The ​request is overwhelmingly to allow users to have the final word regarding whether AI functionality is enabled. If 3rd party code can override explicit user intent, then this requirement is not met.
2. This request holds true whether
   • it's a popular 3rd-party plugin that's eager to add AI functionality alongside existing behavior. If that plugin wants to make AI a prerequisite for _all_ plugin functionality they should do so explicitly, not require the user to notice their config is being ignored and then override it.
   • it's malicious code. The scope, damage, costs are all significantly increased when AI is involved, and the posed risks apply not just to the compromised site but bot swarms of agents with unparalleled exfiltration and self-healing potential that can also eat up thousands of dollars in inherence costs in a day.

Trac ticket: https://core.trac.wordpress.org/ticket/64706

This PR fixes wp_supports_ai() to early-return if WP_SUPPORTS_AI is false, instead allowing the wp_supports_ai filter to switch the value back on even if the user/host has explicitly disabled it.

Follow up to #11149

[!NOTE]
This PR is based on #11149.
Relevant diff: f0c1632e19951a45073bc581294bcca0c2e569fc

## Use of AI Tools

Github Copilot Autocomplete on the doc blocks.

That said, the consensus on the call was that this is invalid and buggy behavior that should be fixed during the RC period,

Restored in ​https://github.com/WordPress/wordpress-develop/pull/11295

[SergeyBiryukov]

In 62067:

AI: Introduce wp_supports_ai() function to control LLM-related features.

This includes a WP_AI_SUPPORT constant and a wp_supports_ai filter.

When false,

• _wp_connectors_get_provider_settings() will return an empty array (short-circuiting the other functionality).
• WP_AI_Client_Prompt_Builder() will short-circuit the construction with a WP_Error(). wp_ai_client_prompt() will still return an instance, to allow for fluidity to remain intact.

Priority: WP_AI_SUPPORT > add_filter( 'wp_supports_ai', ...) > (default: true)

Follow-up to [61943], [61749], [61943].

Props justlevine, westonruter, gziolo, flixos90, romainmrhenry, ahortin, chrismcelroyseo, SergeyBiryukov.
See #64706.

Thanks for the PR! Merged in r62067.

🤮 Make your slop "AI" feature opt in not opt out**

@mateitudor they are opt-in(?) The only way to use AI functionality is to install a plugin/write code that implements AI functionality. What's currently in core are the underlying API primitives, specifically so 3rd parties don't need to reinvent the wheel and 'slop' their own.

The purpose of this hook is to let core and 3rd party code gate even possibly the _mention_ of AI to environments where AI is supported. Just like before AI, the best way to prevent slop and shoddy code then audit plugins before you install them. Forcing people to manually set a constant or filter after they already intentionally installed a plugin (assumedly with the intention to use it) seems unnecessary friction.

Then how come it says here it is opt out: ​https://make.wordpress.org/ai/2026/03/19/ai-contributor-weekly-summary-18-march-2026/

Then how come it says here it is opt out: ​https://make.wordpress.org/ai/2026/03/19/ai-contributor-weekly-summary-18-march-2026/

I just wrote what the "it" refers to: providing a higher-level off switch, even if one of the site admins does opt in and install a plugin with AI functionality, and I see you found the linked GH issue before we moved to trac... perhaps you can clarify which part is still unclear to you?

[johnjamesjacoby]

My first time seeing this ticket and my initial reaction is that I'm not confident if wp_supports_ai() is the ideal function name, or the ideal prefix/pattern to introduce for other similar features to inherit in the future.

It feels unintentionally broad, maybe because we already use _support for APIs & components like themes and post-types?

If we are OK with the broadness, then I almost feel like it should be wp_supports( $feature ) so we can provide the funnel today without needing to deprecate wp_supports_ai() later (unless we anticipate wp_supports_ai() being used as a boolean return in a filter.)

[ahortin]

Have just installed 7.0-RC1 onto a site. I've also defined WP_AI_SUPPORT as false in wp-config.

I'm wondering why the Connectors screen is still showing in the dashboard? I was under the impression that this would also be removed as part of this "kill switch" functionality.

[nilambar]

I'm wondering why the Connectors screen is still showing in the dashboard? I was under the impression that this would also be removed as part of this "kill switch" functionality.

Ditto. I believe it is reasonable expectation that keeping WP_AI_SUPPORT as false would disable all AI additions done.

[ozgursar]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11295

Environment

• WordPress: 7.1-alpha-62161-src
• PHP: 8.5.4
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.5.4)
• Browser: Opera
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Code Snippets 3.9.5
  • Test Reports 1.2.1

Steps taken

1. Edit your wp-config.php and add define( 'WP_AI_SUPPORT', false );
2. Observe Connectors page at /wp-admin/options-connectors.php displays No connectors yet
3. Add the following snippet to your active theme's functions.php or via Code Snippets plugin

add_filter( 'wp_supports_ai', '__return_true' ); // attacker/plugin tries to force AI on

add_action( 'admin_notices', function () {
    $result = wp_supports_ai();
    $color  = $result ? 'red' : 'green';
    $label  = $result ? 'FAIL — filter overrode WP_AI_SUPPORT (bug)' : 'PASS — WP_AI_SUPPORT = false respected, filter ignored';
    echo "<div class='notice' style='border-left:4px solid {$color};padding:10px 14px;'>
        <code>wp_supports_ai()</code> returned <strong>" . var_export( $result, true ) . "</strong> — {$label}
    </div>";
} );

4. View Connectors page again and observe that any plugin can override the kill switch by enabling the AI providers.
5. Apply patch
6. View the Connectors page again and observe it displays No connectors yet as expected even though the snippet tries to enable it via wp_supports_ai filter.
7. ✅ Patch is solving the problem

Expected result

With define( 'WP_AI_SUPPORT', false ) set in wp-config.php:

• wp_supports_ai() should return false, regardless of any wp_supports_ai filter attempting to return true.
• The wp_supports_ai filter is bypassed entirely — the constant takes priority.
• The Settings > Connectors screen should show no AI provider cards, as _wp_connectors_get_provider_settings() short-circuits and returns an empty array.

Priority order is respected: WP_AI_SUPPORT constant > wp_supports_ai filter > default (true).

Additional Notes

• The snippet I shared briefly displays this via admin_notices

Screenshots/Screencast with results

Before

After

[audrasjb]

As per today's bug scrub:

Two questions were raised in the few last comments:

1. Maybe wp_supports_ai() function name is a bit too broad for the real scope of the function, as it doesn't really prevent plugins from using AI tools?

There not really any way to prevent AI tools at 100%, so probably better to stay with a short and clear name.
cc @johnjamesjacoby

2. Should it remove the Connectors settings screen?

From @jorbin: No. The connectors screen can be used for more than AI services.

[justlevine]

FWIW the semantics behind wp_supports_ai() is to check whether the current WordPress environment supports AI functionality.

I'm happy to change it to any short and self-documenting name. It only entered core in beta so it's not like it's a big deal to change. I thought about wp_allows_ai() for a bit, but the semantics didn't feel as good to me. 🤷

Would recommend we avoid scope creeping into a broad wp_supports( $thing ) or current_site_can( $thing ) or other patterns. This is scoped for a specific and important need, and shouldn't block (or be blocked by) progress on defining what sort of $things should theoretically qualify for this new registry.