Payload AI Plugin puts generation on the field, with a roadmap in the feature list

AI editing actions placed inside the CMS admin interface

This plugin adds generation and editing actions to Payload CMS, so that composing, translating or rewriting a field happens inside the admin interface rather than in a separate tool. It also adds generation for upload fields, producing images and voice audio in place.

The reason to want that is workflow rather than capability. Every model this plugin calls is reachable from a browser tab already, and an editor who drafts in one and pastes into another loses the connection between the prompt and the field it was written for. Putting the action on the field keeps the context, and it means the prompt can be configured per field by whoever set up the collection rather than re-typed by whoever is writing.

The audience is a team already committed to this CMS. Nothing here is usable elsewhere, and the plugin's value is entirely a function of how much content passes through that admin interface.

Read the feature list carefully, because it mixes three states

The capability list is presented as one set and describes three different things, and the distinction is the most useful thing a prospective user can take from it.

Some actions are shipped and unmarked: generating content from scratch, and translating. Some are shipped and explicitly marked as beta: proofreading and rephrasing. And a third group is labelled as coming, including expanding, summarising and simplifying text.

A second roadmap block lists five more: document analysis, fact checking, automated workflows, editor suggestions and a chat assistant. None of those exist yet.

This is disclosed rather than hidden, and the markers are right there in the list. It still means a reader skimming the feature section can come away believing the plugin does roughly twice what it does. Anyone evaluating should count only the unmarked entries as dependable, treat the beta pair as usable with supervision, and treat everything else as intent.

The whole plugin carries a beta notice of its own, stating that it is actively evolving and naming the specific CMS version it was tested against.

Installing it and wiring two pieces of configuration

Installation is one package, published under a scoped name that differs from the repository name, which is worth knowing when searching for it.

pnpm add @ai-stack/payloadcms

Configuration happens in two places, and both are required before anything appears in the interface. The first registers the plugin and names which collections it applies to, so the capability is opted into per collection rather than switched on everywhere.

import { payloadAiPlugin } from '@ai-stack/payloadcms'

export default buildConfig({
  plugins: [
    payloadAiPlugin({
      collections: {
        [Posts.slug]: true,
      },
      debugging: false,
    }),
  ],
})

The second adds a feature to the rich text editor on the fields that should carry the actions, which is what puts the controls in front of the editor.

import { PayloadAiPluginLexicalEditorFeature } from '@ai-stack/payloadcms'

After both, the generation actions appear on the configured fields. Requiring the editor feature separately is a sensible design rather than an inconvenience, since it means a collection can be enabled without every rich text field in it acquiring buttons.

The README recommends starting from the CMS project's own website template for the smoothest first run, which is a fair way of saying that integration into an unusual existing setup may take longer.

Model choice is yours, and keeping up with it is the maintenance burden

The plugin supports bringing your own model rather than locking to one vendor, and the shipped integrations span several providers: image generation and voice through two commercial services, and text through the providers shown in the README's own provider image.

That flexibility comes with a cost the release history makes visible. One recent release exists to fix outdated model options for one provider. That is the recurring maintenance task for any tool that wraps several model vendors: the models are renamed, deprecated and replaced on the vendor's schedule, and a plugin that hardcodes a list of options goes stale without anything in its own code changing.

For a prospective adopter this is the question to ask about any wrapper of this kind. How quickly does the list refresh when a provider moves, and what happens to your editors in the gap. The evidence here is encouraging, since the fix arrived as its own release within the last month, but the pattern will recur.

The other releases in that stretch are dependency alert fixes, which is unglamorous and exactly what you want to see in a plugin that will sit inside your content system.

The costs and constraints worth stating plainly

API keys and per-use billing are the first. Every action calls a commercial model, so content generation has a running cost that scales with how much your editors use it, and the repository does not discuss pricing. Access control is provided as a feature, which is the correct lever, since limiting who can trigger generation is also limiting the spend.

Version coupling is the second. The plugin is tested against a named version of the CMS, and the plugin's own version numbering tracks that major line. A CMS that moves quickly means a plugin that has to move with it, and an upgrade to either side is a joint decision rather than an independent one.

Third, the licensing is stated inconsistently. The package manifest declares permissive MIT terms, while the repository's licence file is not recognised by the host's own detector, which is why the project shows no identified licence. The most likely explanation is a file the detector cannot match, and the practical consequence is that a compliance reviewer sees an unidentified licence rather than a clean one. Reading the file directly is the way to resolve it.

Fourth, the README is written in a heavily promotional register, which sets expectations above what the feature markers support.

The repository itself is better evidence than its README: it carries browser and unit test configurations, linting, formatting, a development application and a separate customisation guide.

Calling the provider yourself is the alternative

The alternative for any team with developers is calling the model provider directly from a CMS hook or a custom field component, which the CMS supports as a first-class extension mechanism.

The difference in approach is how much interface you are willing to build. Going direct gives you exact control over prompts, providers, retries, cost accounting and where results land, and no dependency that has to track the CMS's releases alongside your own. What it does not give you is the admin interface. The controls on the field, the prompt editor, the access control integration and the multilingual handling are all work you would repeat, and interface work inside someone else's admin framework is slower than it looks.

There is also a maintenance asymmetry worth weighing. Direct integration means you own model deprecations, which is a small recurring task. Using the plugin means you inherit someone else's handling of them, which is faster when they are attentive and blocking when they are not.

Take the plugin when editors are the users and the value is in what they can do without leaving the page. Write it yourself when generation is a background step in a pipeline rather than a button someone presses, because in that case the interface the plugin provides is the part you do not need.

Editorial conclusion

This plugin fits a team already on Payload CMS whose editors write enough content that moving between the admin interface and a separate model tool costs real time, and who can absorb per-use API billing controlled through the plugin's access settings. It is the wrong choice when generation belongs in a pipeline rather than under an editor's cursor, where calling the provider from a hook avoids a dependency that must track the CMS. Count only the unmarked entries in the feature list as dependable, since proofreading and rephrasing are marked beta and eight further capabilities are listed as coming, and read the licence file directly, because the manifest declares MIT while the host reports no identified licence.

Frequently asked questions

Official sources

1. ashbuilds/payload-ai on GitHub
2. Issues
3. README
4. Releases