I tossed out a question on X this week, and it clearly hit a nerve.
In the tweet I shared, I basically asked a simple question with a messy underside: if WordPress is going to make AI Connectors feel native, what happens when site owners connect a provider once … and then multiple plugins can quietly start using it?
The replies rolled in fast. People brought up Google Maps, Elasticsearch, kill switches, constants, filters, permissions, logging, and the usual WordPress tension between power and protection. Fair enough. But after reading through the thread, I keep landing in the same place:
WordPress AI Connectors need more friction, not less.
The problem isn’t that AI costs money
That part is obvious. Plenty of things in WordPress can cost money. APIs have always existed. Usage-based billing is not some shocking new invention.
What feels different here is the shared connection layer. Historically, if a plugin wanted to use a paid service, you usually connected that plugin directly. One plugin. One settings screen. One API key. One pretty clear line between the feature and the bill.
AI Connectors change that mental model.
Now the pitch is: connect OpenAI, Anthropic, or Google/Gemini once, and plugins can hook into that shared layer. Cleaner UI? Sure. Better standardization? Probably. Less duplicated setup work for developers? Absolutely.
But that convenience comes with a cost … and I don’t just mean tokens.
Abstraction is doing a little too much work here
The more “native” this feels, the easier it becomes for site owners to assume WordPress is handling the scary parts for them.
That’s the danger.
If I paste an API key into a plugin-specific screen, I understand the bargain. I am enabling that plugin to use that service. If something goes sideways, I know where to look.
If I connect an AI provider in a centralized WordPress screen, the relationship gets fuzzier. It starts to feel like infrastructure. And infrastructure is exactly where hidden usage gets expensive fast.
That’s especially true if a trusted plugin updates later and suddenly starts using AI under the hood. Maybe it’s helpful. Maybe it’s optional. Maybe it’s barely labeled. Maybe it ships through auto-updates and the site owner has no real idea their existing connector is now being tapped.
That is not a paranoid scenario. That is a normal-product-behavior scenario.
I don’t want magic here. I want receipts.
This is the part I think matters most.
If WordPress wants to normalize AI inside the admin, it also needs to normalize visibility. Site owners should be able to answer a few dead-simple questions without spelunking through logs, docs, or dev hooks:
- Which plugin made this AI request?
- Which provider did it use?
- Which model did it use?
- How many tokens or requests did it burn?
- Did this happen in wp-admin, on the frontend, or on a cron job?
- Can I stop one plugin without turning off the whole thing?
That’s not an advanced enterprise wishlist. That’s basic stewardship.
And yes, some people in the discussion pointed out that there’s already a broad kill switch. Good. There should be. Some also mentioned constants, filters, and the ability to programmatically get more granular. Also good.
But let’s be honest: “there’s a filter for it” is not a product strategy.
The missing layer is permission
I’m not arguing for obnoxious confirmation popups every time something wants to generate alt text or summarize a post. That would be useless. People would click straight through it and hate WordPress for making them do it.
I am arguing for a clean permission layer.
Something closer to:
- Allow Plugin A to use connected AI services
- Deny Plugin B
- Allow AI in wp-admin but not on the frontend
- Allow manual actions but not cron-based actions
- Set a budget threshold or at least a warning threshold
- Show me what used what, when, and why
That’s the kind of friction I want.
Not because I’m anti-AI. Not because I think site owners need bubble wrap. But because once WordPress creates a shared system for connecting paid AI services, it also creates a shared trust problem. And trust problems do not get solved with smoother onboarding screens.
Core doesn’t get to act surprised later
If WordPress core is going to encourage a standard connection layer for AI providers, then core is also taking on some responsibility for the admin experience around cost, attribution, and control. Not all of it. But definitely some of it.
You can’t centralize the convenience and then decentralize the consequences.
If the platform says, “Here’s the official-ish way to connect AI services inside WordPress,” site owners will reasonably assume WordPress has also thought through the obvious failure modes. Hidden spend is an obvious failure mode. Shared access without visibility is an obvious failure mode. Plugin updates introducing AI usage without meaningful awareness? Also pretty obvious.
That doesn’t mean core has to solve every provider’s weird billing model. It does mean core should take the basics seriously: logging, attribution, permissioning, clear defaults, clear documentation, and real owner-facing safeguards.
This isn’t a reason to kill AI Connectors
To be clear, I’m not arguing that the whole idea is bad. I actually like the idea of standardization. I like less duplicated plugin UI. I like the possibility of plugins integrating with AI in a more coherent way.
What I don’t like is pretending the current abstraction is neutral.
It lowers setup friction on the front end while potentially raising billing and trust friction on the back end. That tradeoff should be discussed out loud, not hand-waved away as “well, APIs have always had costs.”
Sure. But WordPress-native shared connectors change the blast radius.
My take
If WordPress wants AI Connectors to work, they need guardrails before growth.
Give site owners a dashboard. Give them logs. Give them plugin-level permissions. Give them budget awareness. Give them visibility into provider and model selection. Give them confidence that connecting one service doesn’t mean silently funding every plugin that wakes up with AI ambitions next month.
Because if the answer is “just trust the ecosystem”… that’s not a strategy. That’s a future support thread.
And probably an expensive one.