I was curious about something while testing WordPress AI features:
What happens if the AI provider I want to use is not one of the default providers?
WordPress AI can connect to supported providers directly, but many AI services today expose an OpenAI-compatible API instead of being officially supported one by one.
That includes things like:
At first, I assumed that if an API follows the OpenAI format, I could just paste the endpoint somewhere and call it a day.
Turns out, not always.
So I tested a bridge approach using a WordPress plugin called Koneek to connect an OpenAI-compatible API provider to WordPress AI.
Here is what I found.
The question was simple:
Can WordPress AI use an OpenAI-compatible provider even if WordPress does not support that provider directly?
In my test, I used OpenRouter as the provider because it exposes an OpenAI-compatible endpoint and also has free models available.
The goal was not to build a custom integration from scratch.
I wanted to see whether WordPress AI could use a third-party compatible API through configuration only.
This part surprised me a little.
Even when a provider says it is OpenAI-compatible, it does not mean every app can automatically use it.
Different providers may use:
So even if the request and response format is mostly compatible, WordPress still needs a way to know:
That is where the plugin comes in.
For this test, I prepared:
For OpenRouter, the base URL I used was:
https://openrouter.ai/api/v1
For the model, the original test used:
cohere/north-mini-code:free
The exact model can change depending on what is available from your provider, so I would not hardcode that forever. Always check the provider's model list before configuring it.
After installing and activating the required plugins, I went into:
Settings > Koneek
From there, I added a new provider configuration.
The fields were pretty straightforward:
Name: Any label you want
Provider: OpenAI-Compatible
API Key: Your provider API key
Model: The model name from your provider
API URL: The OpenAI-compatible base URL
Timeout: Optional
For OpenRouter, the important values looked like this:
Provider: OpenAI-Compatible
Model: cohere/north-mini-code:free
API URL: https://openrouter.ai/api/v1
I left the timeout empty at first because I wanted to see whether the default behavior was good enough.
If the provider is slow or the model takes longer to respond, setting a custom timeout may be worth testing.
One thing I liked about this workflow is that I did not have to blindly save the config and hope it worked.
Before saving, I tested the connection.
This is important because there are several small things that can break the setup:
In my case, once the connection test returned successfully, I saved the configuration.
That small test step saves a lot of guessing.
After the provider was connected through Koneek, the next step was enabling the AI features from:
Settings > AI
This part depends on the WordPress AI plugin configuration.
Once enabled, WordPress AI could use the configured provider for features like:
That was the moment where the setup actually felt useful.
The provider was not just saved somewhere in settings. It became usable inside WordPress.
The biggest win is flexibility.
Instead of waiting for WordPress AI to support every provider directly, this setup makes it possible to connect providers that expose an OpenAI-compatible API.
That opens the door to testing different backends, such as:
For developers, that is useful because AI providers change fast.
Today you may want OpenRouter. Tomorrow you may want a local Ollama setup behind an OpenAI-compatible proxy.
The WordPress side does not need to care too much as long as the bridge configuration works.
This setup is convenient, but I would not treat it as magic.
There are still a few things to watch:
OpenAI-compatible providers often use their own model naming format.
For example, OpenRouter model names usually look different from OpenAI model names.
If the model name is wrong, the connection may fail even if the API key and base URL are correct.
If you use a free model, do not assume it will stay available forever.
This is fine for testing, but for production workflows, I would use a stable paid model or at least have a fallback plan.
Some models respond slower than others.
If WordPress keeps failing while the provider works elsewhere, timeout settings are one of the first things I would check.
According to the Koneek plugin information, API keys are stored using AES-256-CBC encryption with the encryption key derived from WordPress secret salts in wp-config.php
.
That is better than storing plain text secrets, but I would still treat API keys seriously:
wp-config.php
secureI would use this setup when I want WordPress AI to work with a provider that is not directly supported yet.
Good use cases:
I probably would not use a random free provider for serious production content automation unless I had already tested its reliability, latency, and privacy policy.
The interesting part is that "OpenAI-compatible" is more of a compatibility layer than a universal guarantee.
It gives you a common API shape, but the app still needs to know the provider details.
Once those details are configurable, WordPress AI becomes much more flexible.
The setup that worked for me was:
WordPress AI
↓
Koneek provider configuration
↓
OpenAI-compatible API endpoint
↓
AI provider/model
That is a pretty clean flow.
I went into this assuming the hardest part would be the API itself.
It was not.
The real trick was making WordPress AI aware of the provider's base URL, model name, and authentication details.
Once that bridge existed, the rest felt surprisingly simple.
While researching this setup, I also came across an Indonesian article that walks through a similar configuration: Cara Menghubungkan OpenAI-Compatible API ke WordPress AI
I am curious how other WordPress developers are approaching this.
Are you using official AI providers only, or are you routing everything through OpenAI-compatible gateways like OpenRouter, LiteLLM, Ollama, or OpenWebUI?