Use the AI subscription you already pay for to work on WordPress

There is a new category of WordPress plugin that lets an AI read and change your site: write posts, edit layouts, run audits, fix things. They are worth having. Before you install one, two questions decide more than any feature list, and both can be answered in five minutes.

The first is who ends up seeing your content and the words you type. The second is who pays for the AI, and that one has a trap in it. You pay for Claude or ChatGPT every month, you install one of these plugins, and it asks you for an API key. When you go looking for one you find a second account, a second bill, and a balance of zero. It feels like being charged twice for the same thing.

You are not being cheated, and you probably do not need to pay again. This is what is going on, in plain terms, and how to get the work done on the plan you already have. This is Respira's guide, and Respira is included in the comparison below; every competing claim links to the vendor's own documentation.

Jump to a chapter

A subscription is not an API account

These are two different products from the same company.

A subscription (Claude Pro, ChatGPT Plus) pays for you to use their apps and tools. Flat monthly fee, generous limits, no per-message charge.

An API account pays for other software to call the model on your behalf. You top up a balance and every request draws it down by fractions of a cent.

Money on one side does not spend on the other. That is why a plugin cannot use your subscription: the plugin is the thing making the request, and a plugin needs an API account to make it with. It is not a design failure, it is what the plugin is.

Even WordPress core works this way

WordPress 7.0 shipped its own AI layer, and it is the clearest illustration available because nobody is selling you anything. Core bundles no providers at all: the official AI Provider plugins for Anthropic, Google and OpenAI ship separately, and you paste a key into Settings, Connectors, where it is hashed and masked to the last four characters. The Make Core announcement is direct about it: "API keys are managed through the Connectors API", and plugin developers "do not need to handle credentials at all" because the site holds them centrally.

There is no subscription option there, and there could not be. The site is making the call, so the site needs an API account. Every plugin built on the new AI Client inherits that, which is worth knowing before the next wave of them arrives in your admin.

The way round it: let the AI do the reaching

Turn the arrow round. Instead of putting a key inside WordPress so the site can call the AI, let the AI call the site.

You open the AI tool you already pay for, tell it your site exists, and ask for what you want. The thinking happens inside your subscription, where it is already paid for. WordPress is just something the assistant can now reach and change, the way it can reach a folder of files.

The plumbing is a small open standard called MCP, the Model Context Protocol. A plugin on your site publishes a list of things an assistant is allowed to do, and any MCP-speaking assistant can call them. You install it once. The site connection uses browser sign-in or a scoped site access key, depending on the AI client. That key authorizes WordPress actions; it is not an AI-provider key and cannot run up a model bill.

What a coding model is, and why it fits WordPress

The tools worth using here are usually described as coding assistants, which undersells them for this job. A coding model is tuned to read something large, make a plan across several steps, and use tools to carry it out, instead of answering in one go.

That is exactly the shape of real WordPress work. "Fix the spacing on the pricing page" is not one instruction. It is: look at how the page is built, find the right module, change one value, look again. A chat model guesses. A coding model checks.

The useful part is that these are mostly included in an ordinary subscription. You do not need a developer plan to use one, and you do not need to write code to talk to it.

What each plan actually covers

Anthropic, with Claude Pro or Max

Your plan covers Anthropic's own tools: Claude Code, Claude Desktop, and the connectors inside claude.ai. Connect a site to any of those and the subscription pays.

It does not cover other companies' tools, and that is a rule rather than a technical limit. OpenCode's own documentation says so plainly: "There are plugins that allow you to use your Claude Pro/Max models with OpenCode. Anthropic explicitly prohibits this." If a product offers to run your Claude subscription for you, treat that as a reason to ask questions.

OpenAI, with ChatGPT Plus or Pro

Codex is included, and it signs in with your ChatGPT account rather than an API key. It runs in the OpenAI desktop app, in a terminal, or inside an editor. Connect it to a WordPress site and the plan you already pay for does the work, with nothing added to an API balance you may never have opened. ChatGPT also supports MCP-backed custom apps, although availability and write permissions depend on the plan, workspace and surface.

OpenCode, which is free and open source and has a desktop app, also offers a ChatGPT Plus and Pro sign-in, if you would rather not use OpenAI's own tool.

Google, with a Gemini plan

The least settled of the three. Gemini Code Assist has carried a free tier for individuals and Gemini CLI has offered a Google account sign-in, but the terms have changed more than once during 2026 and the published limits differ between editions. Check Google's current documentation before planning around a number, including any number in an article like this one.

Official integrations should connect to Respira for WordPress, not AER

Respira for WordPress is not listed in OpenAI's or Anthropic's directory today. That does not mean ChatGPT, Codex or Claude cannot connect to it. The MCP setup page in the Respira dashboard already provides the direct connection paths, including browser sign-in and scoped site keys. Which route appears depends on the AI product, plan and workspace controls.

The official integrations i want are for Respira for WordPress. Their job is to remove the technical setup: choose Respira in ChatGPT or Claude, sign in, choose a WordPress site, and grant the scope it needs. ChatGPT or Claude remains the place where the conversation runs, and the selected WordPress site remains the place that executes the tools. The integration should not send someone into AER.

Every connected WordPress site has its own MCP endpoint. The AI client calls that site directly. Respira handles the plan and, where browser sign-in is used, the authorization metadata, but the conversation and the WordPress content returned by tools do not pass through Respira's servers. My first OpenAI submission used a template so the listing could accept each customer's own site URL; it was not approved because templated server URLs currently require an established partner relationship.

The answer is not to rename AER or put a Respira proxy in the middle merely to satisfy a fixed-URL listing. That would change the privacy promise. I will pursue the supported template or partner path with OpenAI and the connector review path with Anthropic. OpenAI's current overview of apps in ChatGPT and Anthropic's Connectors Directory FAQ describe those publication routes. Until a listing is approved, the direct connections on the MCP setup page remain available.

Respira AER is a separate hosted product layer: a workspace for planning, running and reviewing work across sites. It has its own disclosed data path because it coordinates the run. It should not be used as a shortcut for publishing the direct Respira for WordPress integration.

A key in wp-admin is a live payment method

This is the part that turns a preference into a decision. If a plugin holds your API key, that key is only as safe as the whole site, and the bill it can run up has no natural ceiling.

WordPress core is refreshingly blunt about what this means. From the Connectors API announcement: "API keys stored in the database are not encrypted but are masked in the user interface", and once saved, every plugin on the site can read it. The masking is for shoulders, not for attackers. Encryption is filed as a follow-up rather than shipped. The same is true of environment variables and PHP constants, as the post points out, and of most plugins that store a key.

So treat a key pasted into WordPress as a payment method you have left in the building. Anyone who gets an admin login, any plugin you install, and anyone who ends up with a database backup can spend against your account until you happen to look.

The containment takes five minutes and it is the same shape at every provider. With Claude:

• Make a dedicated workspace. Do not use the Default one. Anthropic's documentation is explicit that "You cannot set limits on the Default Workspace", which is exactly the workspace most people's first key lands in.
• Cap the monthly spend on that workspace's Spend limits tab, and set an alert below the cap.
• Create the key inside the workspace so it is scoped to it and can reach nothing else.
• Know the kill switch. If the site is ever compromised, archive the workspace. Doing so "archives every API key created for that workspace within seconds". One action, and the spending stops.

OpenAI is the same idea under different names: a project, a budget on that project, and a key scoped to it. Whichever you use, the habits matter more than the vendor. One key per site, never the one you use on your own machine, rotated whenever somebody with admin access moves on. The cap limits the damage and the alert is what tells you it happened at all.

Which points at something worth saying plainly: the safest key is the one you never made. If your subscription can do the work, there is no key in the database to steal and no invoice to be surprised by.

The other question: where do your prompts go

Worth two minutes before you install anything. There are three ways these tools are built, and each one sends your words somewhere different.

• Your site calls the model. The plugin holds your API key and your server makes the request. AI Engine describes it as "Your site makes the calls, on the keys you already own." Your prompt reaches the model vendor and nobody else. The trade is a live key sitting in your WordPress database.
• Your assistant calls your site. The prompt never passes through the plugin, because the plugin sits at the far end of the conversation rather than in the middle of it. Your words go to the AI you already chose, under the terms you already accepted.
• A vendor sits in between. Your site or browser talks to the vendor's servers, and those talk to the model. Every hosted dashboard works this way, and some in-admin plugins do too. Check the vendor's data-flow and retention documentation before deciding whether that convenience fits the work.

None of the three is wrong, and the third buys conveniences the others cannot. The point is to know which one you picked.

There are two keys, not one

So far this has all been about the key that pays for the AI. There is a second one, and it is the more serious of the two: whatever a tool uses to change your WordPress site. A leaked AI key costs you money. A leaked site credential costs you the site.

Where that one lives varies as much as the first. WPVibe is a clear worked example because their documentation is unusually specific about it. They run "a hosted remote server model": your AI client talks to their cloud, and their cloud talks to your site, so "your site needs to be reachable over HTTPS". Your site's application password is held on their servers, and they say how: "Credentials encrypted (AES-256-GCM) at rest with per-site salt", with the important clarification that they never hold your actual WordPress password, only a revocable application password you grant in one click.

Credit where it is due: they also solved the problem this article is about, and say so plainly. "You bring the Claude or ChatGPT you already use, and it works on their free plans too." No AI key changes hands.

So the trade is visible, which is the point. An application password can be revoked from your own admin in seconds, and holding it centrally is what lets a product be easy to set up. Whether you want it held for you is a decision rather than an accident, as long as somebody tells you it is happening. Ask any tool the same question: does my site credential stay on my site, and can I revoke it without asking you.

Four approaches, side by side

Every cell below comes from the vendor's own documentation, linked earlier in this article. Respira for WordPress is highlighted because it is the best fit for the two criteria this guide is testing: use the AI subscription you already pay for, and keep Respira out of the path between your prompt and your site. That is a disclosed product judgment, not a general security score.

Two columns are worth reading together. A tool that runs on your subscription has no API key to leak, which removes the invoice risk entirely. A tool that keeps your prompts off its own servers cannot lose them. Few products manage both, and the ones that do tend to ask something else of you instead, usually that you already have an AI client set up.

Seven questions, five minutes

• Which hosts must my site be able to reach for this to work.
• Where is my API key stored, who can read it, and is it encrypted or only masked.
• Is there a spend cap on the account behind that key, and an alert below it.
• Are prompts and results kept anywhere outside my site, for how long, and can I delete them.
• Does this work with the subscription I already pay for, or only with an API account.
• Does my WordPress credential leave my site, and can I revoke it myself in seconds.
• If the vendor disappears tomorrow, does my site still work.

Where Respira sits

In the interest of not hiding the ball: this is Respira's blog, and Respira is one of these tools. It is a WordPress plugin that publishes a set of things an assistant is allowed to do on your site, across the page builders people actually use, so the AI you already have can do real work rather than hand you code to paste.

What it is: a plugin that lets the AI you already pay for reach your site. Your assistant does the calling, so no prompt passes through Respira's servers, and the subscription you have covers the thinking.

What it is not: a place to put an AI-provider API key. On the plugin and MCP route there is nowhere to paste one, because Respira never calls a model on your behalf. The credential the site connection does use is a scoped token or an OAuth grant you can revoke from WordPress or the Respira dashboard, so a read-only connection cannot write whatever it is asked to do.

Respira AER is a different product shape, so it is deliberately not a second Respira row in this table. AER is the workspace in the Respira dashboard for planning, building, reviewing and operating across connected sites. It runs on a provider key you bring, so prompts and tool results pass through your Respira account and remain with the thread until you delete it. The direct Respira for WordPress route above keeps the AI client connected to the site without that cloud workspace in the middle.

Connect it to Claude Code or Claude Desktop on a Claude plan, to Codex on a ChatGPT plan, or to Cursor, Conductor, OpenCode and a dozen others. Respira for WordPress is at 9.0.0 with this release and the MCP server at 8.3.25. Each has a finished setup on the connection page. If you already pay for one of them, this costs nothing more than the plugin.