WordPress as the operating system of the agentic web. Who pays for the tokens?
Automattic announced on April 21 2026 in the post WordPress as the Operating System of the Agentic Web that WordPress is the operating system of the agentic web. The post by James Grierson, head of global expansion at the company, lists 8 strengths and 6 weaknesses of that role. It skips a single question. Who covers the cost of AI tokens on the end user’s side. That gap decides who receives the first surprise invoice once WordPress 7.0 ships.
“WordPress’s foundational principles position it uniquely to become the operating system of the agentic web.”
James Grierson, Automattic, April 21 2026
Calling 43 percent of the web an “operating system” of the agentic future is a strong claim. Leaving out who pays for the AI usage that runs through it is an equally strong omission.
What Automattic actually announced on April 21 2026
Automattic positions WordPress as the foundation of the agentic web for three reasons. Open source code, an ecosystem of 61,000 free plugins, and standardised APIs. James Grierson cites Automattic’s own statistics, namely a 43% share of all websites and over 60% of the CMS market. The 90,000 plugin figure includes premium marketplaces.
Full pros and cons from the post
Automattic lists 8 strengths of WordPress as a platform for AI agents. A proven, mass ecosystem. Open source transparency. Peer-reviewed code and community standards. Security through transparency. REST API and MCP connectivity. Commerce extensibility through WooCommerce. Hook and filter architecture. Decades of documentation.
The list of 6 weaknesses is equally specific. Legacy code and technical debt. Inconsistent plugin quality. Abandoned and insecure plugins. Performance overhead. Hook system complexity for agents. PHP perception and the shrinking pipeline of new developers. Fragmentation across hosting environments.
What is missing from the post
The word token does not appear once in Grierson’s post. There is no section on API key ownership. There is no billing model. There is no scenario in which an agent exhausts its planned query pool mid-week. The omission reflects the author’s perspective. The post comes from a company that sells hosting and AI modules as a bundle. A self-hosted operator has different priorities.
A second omission is logging of operations performed by the agent. Each MCP write modifies database state and requires a separate audit log entry, which the post does not address. A third omission is privacy policy, which decides what post or comment data leaves the server and reaches the AI vendor. Those three omissions separate a vision from a deployable product.
Model Context Protocol and Abilities API in practice
Model Context Protocol is a standard that lets AI agents connect to external systems. Automattic rolled MCP into WordPress.com in two phases. Read first, write next. Self-hosted WordPress reaches the same capability via the Abilities API and the WordPress MCP Adapter.
Read-only in October 2025, write in March 2026
WordPress.com enabled MCP in read-only mode in October 2025. Full support for write operations went live in March 2026. From that moment an agent can create a post, publish it, add a comment, and manage media through natural language. Each such operation generates a cost on the side of the model that performs it.
The practical consequence is simple. Activating one plugin that talks to an agent turns every post edit into a request to an external AI vendor. The invoice arrives wherever the API key lives.
What the Abilities API changes for self-hosted
The Abilities API combined with the WordPress MCP Adapter lets plugin authors expose existing plugin features as tools for agents. The adapter bridges plugin abilities to the MCP specification. The author of an existing plugin adds a few lines of configuration. The agent gains access to that feature.
This shortcut lowers the barrier to entry, so the number of plugins with AI features in the WordPress.org repository grows faster than the number of security audits of those plugins. WPPoland has observed this pattern since March 2026 across clients enrolled in our WordPress website maintenance program.
The role of WordPress Playground for agents
WordPress Playground spins up a full WordPress instance in a browser within seconds. Automattic positions this tool as a sandbox for agents. The agent tests a change in Playground, and only the confirmed action returns to production. The design reduces the risk of data damage from a model hallucination. It does not change who pays for the consumed tokens.
The gap in the vision, namely who pays for the tokens
Russell Heimlich, a WordPress developer with 20 years in the ecosystem, asked this question publicly in WordPress AI Features Are Coming. Nobody Is Talking About What They’ll Cost Your Users on April 24 2026. Heimlich, known in the community by the handle russellenvy, points out that Automattic does not mention AI cost once in its agentic-web vision. His point is practical. If a plugin installs itself, asks the user to connect an account at an AI vendor, and then opens a chat panel in the dashboard, the user has no idea that each message costs money.
Russell Heimlich’s argument
Heimlich describes his own case of working with AI models. He uses a monthly subscription with the Claude provider and reaches the weekly query limit despite advanced prompt and workflow optimisation. From this he draws a concrete conclusion. A user without experience operating language models, for example a food blogger who has just launched a site and installed a popular AI-enabled plugin, will exhaust that pool faster and without a clear error message explaining the cause.
“Every interaction between an AI agent and a WordPress site costs tokens.”
“Every single one of those exchanges burns tokens. Real money. Her money. And she has no idea.”
Russell Heimlich, russellenvy.com, April 24 2026
A second Heimlich argument concerns responsibility for user experience. A plugin that introduces an AI feature without a clear cost message shifts the burden of educating the end user onto the site operator and indirectly onto the agency. A third argument addresses the WordPress brand reputation. The first wave of dissatisfaction after surprise invoices reflects on the entire ecosystem, regardless of the fact that the source of the problem is a single plugin.
Three API key ownership models and their consequences
In practice three models for billing AI tokens in WordPress plugins dominate the market.
Bring-your-own-key. The customer creates an account at the AI vendor, generates a key, and pastes it into the plugin’s panel. Costs go straight to the customer. The plugin author does not act as intermediary. The model is transparent in accounting terms and requires the customer to understand how the token pool works at that vendor.
Vendor subscription handled by the plugin author. The plugin charges the customer a fixed monthly fee and settles directly with the AI vendor. The risk of misuse falls on the plugin author, who balances pricing with actual consumption. The model is convenient for the end user and risky for the plugin operator.
Shared metered pool with a monthly limit. All plugin customers share one pool. After exhaustion the pool refreshes the next month or expands in a higher tier. The model simplifies the message to the user and introduces a new effect, namely the neighbour consuming my tokens.
The food blogger from TikTok scenario
Heimlich described this scenario first. A viral blogger sets up a WordPress site, installs an AI-enabled plugin, clicks through the wizard. The wizard asks to connect a Claude, ChatGPT, or Gemini account. The blogger connects the account because the instruction says so. They then treat the AI panel as an ordinary chat. Two days later the weekly pool is gone. The plugin shows an empty loader without a message. The blogger blames WordPress. Every part of this story repeats with real customers today.
What it means for WordPress site owners before the 7.0 release
The WordPress 7.0 release is approaching fast. Release Candidate 2 went live on March 26 2026 on wordpress.org. The general availability date is not yet officially confirmed in project communications. Regardless of the exact date, MCP infrastructure on the self-hosted side matures in parallel. A site operator should make 3 moves before the first wave of plugin updates with AI inside lands.
Audit currently installed plugins for AI features
Check every installed plugin against 3 pieces of information. Whether the product roadmap includes an AI component in the upcoming version. Whether the plugin author has published a token billing model. Whether there is an option to disable AI features without losing the rest of the plugin’s capabilities. Plugins without these answers require monitoring of changelog changes between updates.
In practice 3 plugin categories introduce AI features fastest. SEO plugins, such as Yoast SEO and Rank Math, where a meta description generator uses a language model. Calendar and event plugins, such as The Events Calendar, where an agent generates descriptions of recurring event series. E-commerce and CRM plugins, where an AI assistant proposes product descriptions and answers to customer enquiries. Each of these 3 categories has a different token consumption profile because the length of a single prompt differs.
A full audit pairs cleanly with a WordPress security audit every six months. WPPoland runs that audit as part of its maintenance program and, as of March 2026, adds an AI feature map of installed plugins to the report.
Questions to ask plugin vendors
Three questions for the plugin author before turning on AI mode read concretely. First, where does the API key live and who pays for it. Second, what is the message to the user after the token pool is exhausted. Third, is every action performed by the agent logged in a way that allows reconstructing history. Authors of serious plugins answer within a day. The absence of an answer is itself an answer.
Configure default behaviour when tokens run out
Configure the plugin so that a lack of tokens degrades the feature rather than blocking the dashboard. Three settings solve 80% of problems. A textual message about the cause of the error instead of an empty loader. A local copy of the last successful response visible as a placeholder. The ability to disable the AI module from an editor profile without code edits.
What plugin authors should do
Plugin authors carry greater responsibility than site operators because they shape the end user’s first experience with an AI agent. Three design principles reduce the number of surprised customers after the first invoice.
Cost message before the first request
The first request to an agent is always preceded by a message. The plugin shows what action will be performed, how many tokens will be approximately consumed, and which AI account will be charged. The message appears once and its absence costs the user’s trust at the first surprise. The pattern is proven in popular developer tools, such as GitHub Copilot or Cursor.
Degradation mode instead of an empty loader
Degradation mode handles 4 token pool states. Full access. Low balance warning. Read-only mode where the agent reads data but does not generate content. Disabled mode. Each state has its own user-facing message. An empty loader is not an acceptable state because a user without context interprets it as a platform-wide failure.
Bring-your-own-key vs subscription vs shared pool
The choice of billing model affects 3 areas at once, namely the install message, the settings panel, and the incident response procedure. Bring-your-own-key requires careful customer onboarding. The subscription model requires negotiating volume with the AI vendor on the plugin author’s side. The shared pool model requires monitoring for misuse. The plugin author documents the model choice in user documentation, not only in the privacy policy.
How an agency should prepare its clients
An agency that manages many client sites has 3 things to align with each client before the WordPress 7.0 release. A contract clause covering AI services. A plugin update regime. Communication of an incident after exceeding a token limit.
Contract clause covering external AI services
The clause consists of 4 sentences. The customer covers AI token costs at external vendors directly. The agency informs the customer of every new AI feature in maintained plugins before activation. The customer authorises activation in writing. The agency monitors consumption and reports anomalies within 48 hours. The pattern grows out of established WPPoland experience working with business clients, where unexpected external costs damage the relationship the fastest.
The clause also describes an emergency procedure in 2 steps. First, an automatic pause on agent requests after crossing a threshold defined with the customer. Second, agency contact with the customer in working mode, namely email and phone during the customer’s working hours. An undefined threshold means in practice that the first information about overrun reaches the customer in the AI vendor invoice, which is the most common cause of trust loss in the first quarter of cooperation.
Update regime, namely manual, automatic, or after review
The customer chooses 1 of 3 plugin update regimes. Manual updates, where the agency deploys a new version after testing. Automatic updates with a daily change report. Updates after review, where the agency blocks the introduction of new features until customer approval. The after-review regime protects the customer best during the period of AI feature introduction in plugins.
What goes into the brief for a new project
A new project brief includes 4 new questions relative to a 2024 brief. First, whether the customer accepts the presence of AI features in the editorial panel. Second, who will own API keys at AI vendors. Third, what monthly budget the customer allocates to tokens. Fourth, which user scenarios should not generate agent requests. These 4 questions answer the gaps that Automattic did not close in its vision.
After these decisions a project can safely use MCP infrastructure, the Abilities API, and the plugin ecosystem. The operator knows the costs. The plugin author knows the constraints. The AI agent has clearly defined boundaries. The remaining strengths of WordPress, such as open source code and rich documentation, work without change.
WPPoland has been holding this conversation with every client since March 2026. The full map of practices is covered in detail in the AI and LLM visibility playbook and in the LLMO strategic summary. Visibility for agents is a separate topic, but the foundation is the same, namely understanding where responsibility for the cost of a query begins and ends.
