What a credit-based plugin really costs over a year

A plugin that sells artificial intelligence almost always displays two things: a price per month, and a number of credits. The first is clear. The second is not — and it is the one that decides what you will actually pay after a year.

This article compares no product and names no brand. It does something else, which nobody does for you: it sets out the calculation. You will redo it with your own figures, and it will still hold in six months, once the price lists have changed.

It takes four steps and one question. The question matters most, and it is the one that almost never has a published answer.

Contents

• What we are comparing, and what we are not
• Step 1. Measure your real usage, not the plan's
• Step 2. The price of the raw material
• Step 3. The one unknown in credit pricing
• Step 4. The twelve-month total
• The three places where the calculation goes wrong
• The table to fill in
• Frequently asked questions
• What is left to do

What we are comparing, and what we are not

There are two ways to bill you for AI, and they do not compare line by line.

The credit model: you pay the vendor, the vendor pays the model provider, and keeps the difference. Your bill depends on what you consume.

The own-key model: you pay the software licence to the vendor, and the consumption directly to your provider, at your provider's price. Your bill splits into two lines, one of which does not move. The principle is set out in what the BYOK model is.

⚠ This is not "expensive versus cheap". A credit model can perfectly well come out cheaper than a licence, on a small volume and over a short period. What changes is the shape of the curve: one rises with your activity, the other does not. The only way to know which costs you less is to plot it over twelve months — not over the trial month.

Step 1. Measure your real usage, not the plan's

The plan shows a number of credits. That number tells you nothing until you know what you are going to do with it. Start the other way round: count the acts.

A shop generating product descriptions counts product pages per month. A blog counts articles. A support desk counts replies. Take the unit that means something to you, and record last month's real figure — not the one you are hoping for.

Then convert that act into tokens, the unit every model provider bills in. A token is roughly three quarters of a word in English. Each act consumes two things:

• what you send to the model: the instruction, the context, the existing page;
• what the model returns: the produced text.

The two are not priced the same, and the gap is wide — output costs several times input. That is why a calculation that does not separate them is wrong every time.

Let us take an assumption, and say so plainly: a product description generated from a title, a few attributes and an instruction is roughly 600 tokens sent and 400 tokens returned. If you produce 200 per month:

• sent: 200 × 600 = 120,000 tokens
• returned: 200 × 400 = 80,000 tokens

Those three numbers — 600, 400, 200 — are yours to replace. Everything else follows from them.

Step 2. The price of the raw material

Model providers publish their prices, per million tokens, and they differ between input and output. Here are the ones we show in our own calculator, in dollars per million tokens:

⚠ These prices move, and that is normal. They are given here so the calculation can be checked, not to be copied in six months: take them from your provider's pricing page on the day you do yours.

Back to the step 1 assumption, with the mid-range model:

• input: 120,000 tokens = 0.120 million × $3 = $0.36
• output: 80,000 tokens = 0.080 million × $15 = $1.20
• total: $1.56 per month, that is $18.72 over twelve months

That is the raw-material cost for 2,400 product descriptions in the year. You can redo that multiplication by hand: that is the whole point.

And the same volume on the very small model: 0.120 × 0.10 + 0.080 × 0.40 = $0.044 per month. The choice of model weighs more than the choice of provider — that is the lever covered in optimising your agency's budget.

Step 3. The one unknown in credit pricing

You now have a real cost in tokens. To compare it with a credit-based offer, one thing is missing:

How many tokens is a credit worth?

Without that number, no calculation is possible. "5,000 credits per month" converts into nothing. And it is precisely the figure that is almost never published.

It exists, necessarily: the vendor pays in tokens. The conversion is made somewhere, one way or the other. It is simply not shown.

What you can ask, and what takes one sentence to answer:

1. How many sent tokens and how many returned tokens does one credit correspond to? If there is only one number, ask how the input/output difference is handled — because it exists.
2. Does the rate change with the model used? An act served by a small model and by a large one does not cost the vendor the same. If you are billed the same, the gap is their margin, and that is their right — but you have the right to know.
3. Are unused credits carried over? See the next section: that is where the real bill is decided.

If those three questions get no numeric answer, it is not a communication failure: it is that the unit price is not meant to be known. You cannot compare, so you do not compare. That in itself is information.

Step 4. The twelve-month total

Put the two columns side by side, over the year:

Credit model (plan price × 12) + (estimated overages) + (lost credits)

Licence + own key (licence price over 12 months) + (real token cost × 12)

Three remarks on that sum, and they decide the result:

• The first column rises with your activity. Double your production and it doubles. The second only moves on its variable part, which is the real cost — and you have just calculated that real cost: a few dollars a month in the example above.
• The second column has a fixed part. That is its drawback on very small volumes: paying a licence for ten pages a year makes no sense. The break-even depends on you, and it is calculated with the step 1 numbers.
• Neither column counts your time. A plugin that produces text you then spend twenty minutes correcting costs more than any licence, whatever the table says. That line appears on no invoice.

The three places where the calculation goes wrong

Credits that expire. A monthly allowance that is not carried over is a spending floor, not a usage ceiling. On a seasonal business — a shop that mostly trades in the last quarter — you pay twelve months to use four.

The tier just above. Credit grids are made of steps. Going slightly over yours often costs more than the real difference in consumption, because you do not pay the difference: you change tier. Check the price of the next tier before you get close to the edge, not after.

The rise in usage you are hoping for. This is the most common trap, and the most ironic: if you like the tool, you will use it more. The credit model therefore raises your bill precisely when it is being useful. Do the calculation at your current volume, then do it again at double. If the second answer stops you, you now know the constraint you are buying.

The table to fill in

Copy it as is, with your figures. No cell is pre-filled, and that is deliberate: a table filled in for you is a table that decides for you.

The line that decides everything is the one in the middle: tokens per credit. As long as it is empty, the two totals are not comparable, and nobody — neither you nor us — can tell you which is cheaper.

Frequently asked questions

Is the credit model always the worse deal? No. On low, steady usage it saves you opening an account with a provider and handling a key: that is a real service, and it has a legitimate price. The problem is not the model, it is choosing it without being able to price it.

Is opening an account with a model provider complicated? It is a sign-up, a payment method and a key to copy. We have written the step-by-step for the main ones: Anthropic, OpenAI, Google, Mistral.

What if my provider raises its prices? You will see it, and you will be able to change model or provider without changing plugin. That is the clearest practical difference: with your own key, the increase is visible and you keep control. With credits it is absorbed by the vendor — until the day it is not.

Does it change anything for an agency running several sites? Yes, a great deal: on credits, the cost multiplies by the number of sites. The reasoning at portfolio scale is in what BYOK changes for agencies.

What is left to do

• Record last month's number of acts — the real one, not the estimate
• Estimate the tokens sent and returned for a typical act
• Take today's prices from the provider's pricing page
• Calculate the real monthly cost, then multiply by twelve
• Ask for the tokens per credit from the credit-based vendor
• Redo the calculation at double your volume, and look at both totals

And the question to ask before signing, if only one remains: how many tokens is a credit worth? An offer that answers in one sentence can be compared. An offer that cannot answer is asking you to give up knowing.

That is why our plugins run on your key: why we chose this model, and what it changes for your data. The catalogue is here: our WordPress plugins. Premium versions come with a full refund within 14 days.