ClassifAI: wiring WordPress content workflows to OpenAI, Azure, Gemini, Watson and Ollama

The problem ClassifAI solves is provider plumbing, not intelligence

WordPress has no native concept of an AI provider. If you want an excerpt generated from post content, you either write an HTTP client against OpenAI, Azure OpenAI, Gemini, Grok or a local Ollama endpoint, handle authentication, retries and response parsing, and then repeat that work for every other provider you might switch to, or you install something that has already done it. ClassifAI is that something. The README describes it as integrating "Artificial Intelligence and Machine Learning technologies to lighten your workload", and the feature list is essentially a catalogue of content tasks mapped to provider APIs. The audience is editorial and site teams on WordPress who want these tasks available inside the editor and the admin, not engineers building an AI platform. The plugin's value is the adapter layer and the settings screens, not any model of its own.

One plugin, many providers, and the switching cost is the point

The feature list pairs each capability with several providers. Summaries and titles can come from OpenAI's ChatGPT API, Microsoft Azure's OpenAI service, Google's Gemini API, xAI's Grok or a local Ollama instance. Key takeaways are narrower: OpenAI, Azure OpenAI or Ollama. Article drafting is OpenAI, Azure OpenAI or Ollama. Image generation covers OpenAI's image API, Google's Imagen, Together AI or a local Stable Diffusion server. Transcription uses OpenAI's audio transcription API or ElevenLabs. Text to speech uses Azure, Amazon Polly, OpenAI or ElevenLabs. Classification uses IBM Watson's Natural Language Understanding API, OpenAI embeddings, Azure OpenAI or Ollama. The practical consequence is that the provider is a configuration choice per feature, not a commitment baked into the code. That is the strongest argument for the plugin over hand-rolled integrations: swapping from a cloud provider to a local Ollama endpoint for a given task does not require touching theme or plugin code. It also means the settings surface is large, because every feature carries its own provider selection and credentials.

Embedding features lean on ElasticPress, which is a real dependency

Three of the listed features are not standalone. The smart 404 page, which suggests relevant content based on the URL the visitor tried to reach, requires either OpenAI's Embedding API or Azure OpenAI in combination with ElasticPress. The same pairing applies to suggesting related content based on the currently viewed post. Finding similar terms to merge also uses embeddings plus ElasticPress. This is worth stating plainly because ElasticPress is a separate plugin with its own hosting and indexing requirements. A site without ElasticPress does not get these features by installing ClassifAI alone. The README also notes a specific behaviour on term merging: it only compares top-level terms, and merging a term that has children promotes those children to top-level terms, which it attributes to default WordPress behaviour. That is a data-shape caveat, not a bug, but it affects taxonomy cleanup work.

Getting it running: install the plugin, then configure providers and features

The repository is a WordPress plugin, so the install path is the usual one: place the plugin directory under wp-content/plugins and activate it, or install through the WordPress admin. The README does not spell out a CLI sequence, and I have not run one, so treat any command list as something to confirm against the documentation site at 10up.github.io/classifai rather than as verified steps. What the material does establish is the shape of configuration: credentials for each provider, and per-feature enablement. The README references storing provider setup in the plugin, and WordPress convention for secrets of this kind is either the database or wp-config.php constants, but the supplied material does not name specific constant names, so I will not invent them. The README does point to a WordPress Playground demo blueprint, which lets you load the plugin in a browser sandbox without a local WordPress install. That is the lowest-friction way to see the settings screens before committing to a provider account.

Where ClassifAI is the wrong tool

The plugin is a client for external services. Every cloud-backed feature depends on a provider account, a key, and a network path from your WordPress host to that provider. If your host blocks outbound requests, or if your editorial policy forbids sending post content to a third party, the cloud providers are simply off the table. Ollama and local Stable Diffusion are the escape hatch, and the README lists them for several features, but not all: moderation uses OpenAI's Moderation API, transcription offers OpenAI or ElevenLabs, and the embedding-based 404 and related-content features are described with OpenAI or Azure OpenAI only. So a fully local deployment is not available across the whole feature set. A second limitation is scope. This is not a general AI toolkit for WordPress; it is a fixed menu of content tasks. If your need is a custom classification pipeline, a bespoke chatbot or a retrieval system with your own chunking strategy, you are writing that yourself and ClassifAI will not help. Third, the per-feature provider matrix means operational surface grows with the number of features you switch on. Each enabled feature is another key to rotate and another quota to watch.

Compared with calling the provider APIs directly

The alternative most teams weigh is skipping the plugin and calling OpenAI, Azure OpenAI or Gemini from a small mu-plugin or theme function. The difference is not capability, since ClassifAI is calling those same APIs. The difference is where the work lives. Direct calls give you exact control over prompts, token budgets, retry behaviour and where generated text is stored, and you carry no dependency on a third-party plugin's release cycle. ClassifAI gives you settings screens, editor integration and a provider abstraction you did not write, at the cost of accepting its choices about prompts, storage and which providers are supported. For a single feature on a single provider, direct calls are usually less code than configuring the plugin. For a site that wants excerpts, titles, classification, transcription and text to speech across a team of editors, the plugin's admin surface is the reason to use it. The honest framing is that ClassifAI trades flexibility for not having to build and maintain five integrations.

Maintenance, releases and the GPL-2.0 licence

The plugin is licensed GPL-2.0, the same licence as WordPress itself, which means you can modify and redistribute it under those terms. That is a permissive-enough fit for most WordPress work, but it also means the plugin's own code is not where your proprietary logic should live, since derivative distribution carries GPL obligations. On maintenance, the release history supplied shows 3.8.0 in March 2026 and 3.9.0 in July 2026, with a separate ci-artifacts tag for WordPress Playground testing ZIPs, and the repository's last push is dated 2026-09-10 on the develop branch. The README states the plugin is tested up to WordPress v6.9. Because the plugin is a client for third-party APIs, some upgrade cost is outside the plugin's control: provider endpoints, model names and pricing change on the provider's schedule, and a plugin release is what reconciles that. Budget for periodic updates rather than a set-and-forget install. I am not giving legal advice here; if you redistribute modified versions, read the LICENSE.md in the repository.

Editorial conclusion

Adopt ClassifAI if you run a WordPress site and want AI-generated excerpts, titles, classifications, transcripts or read-to-me audio without writing provider integration code yourself, and if you accept that each feature is bound to a provider account you must keep funded and configured. Do not adopt it if you need a provider the plugin does not list, if you want a single self-contained model with no external service, or if you cannot store API keys in wp-config.php or the database. Verify first: which provider credentials you already hold, whether ElasticPress is present if you want the embedding-based 404 and related-content features, and whether your PHP and WordPress versions match the plugin's tested range.

Official sources

1. 10up/classifai on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases