Every AI feature has a real, variable cost behind it: a call to Claude, GPT, or Gemini through the PHP AI Client SDK costs the provider money per token, and someone has to pay that bill. Traditional WordPress plugins mostly don’t have this problem, a form builder or an SEO plugin costs you the same to run whether one customer uses it or ten thousand. An AI feature doesn’t work that way, and the pricing model you choose is really a decision about who carries that variable cost and how much friction you’re willing to add to shift it. This lesson lays out the four common patterns honestly, without pretending one is universally correct.
This lesson assumes you’re pricing a real feature, not a hypothetical, and that you’ve already worked through Lesson 1’s productizing checklist. Nothing here requires new code, this is a business decision that then shapes the licensing system in Lesson 3.
Step 1: The four models, compared honestly
| Model | How it works | Who bears AI cost risk | Setup friction |
|---|---|---|---|
| Usage-based | Customer pays you per action or per unit of usage (per call, per generated item), you pay the AI provider and take a margin | You, until you set pricing high enough to absorb variance | Low, customer just pays and uses it |
| Credits | Customer buys a prepaid bundle of credits that abilities consume at defined rates, you pay the provider as credits are spent | You, but bounded, since credits are prepaid and revenue arrives before the cost does | Low to moderate, customer needs to understand what a credit “costs” in real usage |
| Bring-your-own-key (BYO-key) | Customer supplies their own API key for Anthropic, OpenAI, or Google, your plugin calls the provider directly with the customer’s key and credentials | The customer, entirely, they pay the provider directly | Higher, the customer has to create a provider account, generate a key, and manage their own billing with that provider |
| Managed / flat-fee | Customer pays one flat license fee (one-time or subscription) regardless of how much AI usage they generate, you cover all provider costs from that revenue | You, fully, with no per-use ceiling unless you build usage limits into the product itself | Lowest, the customer pays once and it just works |
This is the same “who bears the cost, and how much friction does shifting it create” tradeoff that shows up throughout SaaS and API-driven products generally, applied here to a WordPress plugin specifically.
Step 2: Why BYO-key is popular for developer-facing plugins
Bring-your-own-key shifts cost risk entirely onto the customer: they create their own Anthropic, OpenAI, or Google account, generate a key, and every API call your plugin makes on their behalf bills directly to their own provider account. This is exactly the pattern the PHP AI Client SDK is built around (Course 5 covered the setup in detail), and it’s a natural fit for a plugin sold to developers or technical site owners who are already comfortable managing an API key. The tradeoff is setup friction: a customer who has never used an AI provider’s console before now has an extra step between “installed the plugin” and “saw it work,” which is exactly the kind of friction Lesson 1 flagged as a real onboarding risk. It also means your own margin isn’t tied to AI cost at all, you’re purely selling the plugin’s functionality, workflow, and interface, not reselling tokens.
Step 3: Why managed/flat-fee is popular for non-technical audiences
A managed model removes that friction entirely: no key to create, no provider account, one price, it works. This is the model most non-technical WordPress users expect, since it matches how they already buy every other plugin or theme. The real exposure is yours: if a customer runs an unusually high volume of AI calls (or if a bug in your plugin causes runaway calls, exactly the kind of failure Course 4’s rate-limiting patterns exist to prevent), you’re paying the provider bill for that regardless of what the customer paid you. A managed model without usage limits, or without the underlying rate limiting already built for security reasons, is a real financial risk, not just a security one.
If you followed Course 4’s custom rate-limiting patterns because the MCP Adapter doesn’t ship them, you already have most of what a managed pricing model needs to stay financially safe. Rate limiting isn’t just a security control here, it’s a cost control, and a managed-pricing product without it is exposed to unbounded usage from a single customer or a runaway agent loop.
Step 4: Usage-based and credits sit in between
Usage-based pricing (pay per call, or per generated item) and credit bundles (prepay for a set amount of usage) both let you pass AI cost through to the customer while keeping the AI provider relationship on your side, so the customer never touches an API key. Credits in particular give you a natural, visible unit customers can reason about (“this bundle covers roughly this many summaries”), and they front-load revenue before the cost is incurred, which is friendlier to your cash flow than pure usage-based billing where you cover the AI cost immediately and invoice or charge later.
Recap
There’s no universally correct pricing model for an AI feature, only a real tradeoff between who bears the variable AI cost and how much setup friction the customer accepts. BYO-key shifts cost to the customer at the price of setup friction and fits technical audiences well. Managed/flat-fee removes friction entirely but exposes you to variable cost and needs the rate limiting Course 4 already gave you good reasons to build. Usage-based and credit models sit between these two extremes and are common patterns for products selling to a broad audience. Many real products end up offering more than one tier rather than forcing every customer through the same model.
Resources & further reading
- The PHP AI Client SDK for WordPress, this track, provider setup and cost-relevant call patterns
- MCP Security & Authentication for WordPress, this track, the rate-limiting patterns referenced above