@JasonTheAdams @dkotter FYI

Still working on finalizing this (mostly adding some docs), but this is the currently envisioned JS API.

Important consideration: This API should (by default) only be used for features where being able to prompt anything from the client-side is desirable. It is basically unrestricted in what you can do with AI, which is why it's restricted to administrators by default. For actual features in distributed plugins, it's recommended to stick to the PHP-side API and build custom REST API endpoints, in order to "harden" things so that users can't run arbitrary prompts. Due to cost factor, you probably don't want to allow that to users with fewer privileges.

@felixarntz The more I sit on this, the more I'm left wondering what the use case is for someone wanting to make arbitrary prompts from the front-end? As we've discussed, we'll need to lock this down to admins, and even then it's likely folks will make bespoke endpoints and such for specific AI-powered use cases.

Now that we're aiming this for core, I'm more reluctant to add something like this if we don't have clear scenarios in mind.

@JasonTheAdams A few reasons to add this:

1. For client-side AI usage, the DX of using this is vastly superior to having to build all the REST endpoints and JS plumbing manually. Yes, it can still only be used for certain scenarios, BUT (see other points).
2. It will be locked down to admins by default. Sites are welcome to change that and then benefit from the JS API in a more widely accessible way. A few examples:
   • AI features developed by agencies for a specific site in mind can easily rely on this. They can fine tune the capability requirements for the prompt_ai capability as needed.
   • It may be totally reasonable for a site administrator to decide that other users with a lower-tier role are still allowed to prompt AI directly. That could be editors or even lower-tier roles.
   • Many WordPress sites will eventually use some central provider setup, e.g. through hosts. The host, or even individual providers could offer a certain free tier where e.g. only cheap models are offered at a lump sum / monthly subscription payment. In such a situation per-token pricing is not much of a concern, so the site owner could open this up to all registered users.
   • In practice, most WordPress sites in the world only have a single administrator as the sole user. So those sites can use this even out of the box.
3. It is crucial, especially for Core, to set the foundation for using client-side models, as those can be free and offer a way of using AI that is more aligned with the project's philosophy. This JavaScript API, while for now focused on the cloud-based providers, is the foundation for that. We will be able to provide injection points for a client-side model to respond to a prompt, either over a cloud-based model, or as a fallback.
4. A concrete use-case for this API is the AI Playground in the AI Experiments plugin.

In other words: For some features, the JS API is preferable - for other features, the PHP API with REST endpoints and manual JS is preferable.

I'm interested in how people would use this Client Side API. I think because it exists, and because this package likely won't 1 to 1 make it into WP Core v7.0 (like Abilities), it's worth shipping with a note/flag explaining that this is an experimental feature.

Then, we can see how things work, and have a hard deadline of the next Core version to determine if this is useful or not. However it shakes out, for Built-In AI, we'll need some way to handle this as well - this is 100% client side. I can see it taking the path of Abilities Client, where it's a package added to GB out of sync with the first core addition.

At the same time, my concerns lie with the fragmentation of prompt registrations, and why we'd only want to write out these systems in the Client. I think there's some merit to thinking that Agencies could use this ... so let's find out(?)

There's also some client-side element of accepting user messages in a standard way for Command Palette (workflows), Agents, frontend chatbots, et.