What AI models actually cost: 50 models, 22 providers, one table

I did not set out to build a pricing tool. I set out to answer a question I kept failing to answer for my own projects: what is this actually going to cost me to run?

The honest version of the story is that I was losing track of my own work. What am I building. What does it take. What do I still need. Which model do I use for this part. What does that part cost at a thousand users instead of ten. I had answers scattered across browser tabs, a spreadsheet I stopped updating, and a mental note I kept losing. Every time I wanted to sanity check a cost I opened eight provider pricing pages, each with a different unit, and did arithmetic I did not trust.

That frustration is where Cafiyn Pulse came from. The Cost Comparator is the piece that fixed the specific question in the title. This post is what fell out of the data once it was all in one place.

What this study is, and what it is not

This is an aggregation, not an experiment. Every provider publishes its prices. Nobody publishes them together, in the same units, in a form you can compare. So the work here was collection and normalization: 50 models from 22 providers across five categories, every price converted to a common unit, in one table.

Being precise about the limits, because a comparison you cannot trust is worse than none:

• These are published list prices, the default rate on a standard API account. Not negotiated rates, not committed-use discounts, not free tiers.
• This is not a quality benchmark. Nothing here tells you whether a model is good enough for your task. Price and suitability are different questions and only you can answer the second one.
• It is a dated snapshot. The set behind this post was verified on 23 July 2026 and is re-checked on a schedule, because AI pricing moves faster than blog posts do. Confirm against the provider before you budget.
• Real bills include things this ignores, notably prompt caching, batch discounts, and minimums. Those move costs down, usually unevenly.

Finding 1: the same workload costs $18 or $3,037

To compare models you need a fixed workload. I used a deliberately ordinary one, roughly a small B2B app with real but modest traffic:

• 500 users a day
• 3 AI calls per user
• 2,000 input tokens and 500 output tokens per call
• 30 days

That is 45,000 calls a month. Nothing exotic. Here is the monthly bill on each of the 21 text models, cheapest first:

A 169x spread. Same traffic, same prompts, same code. The only variable is a string in a config file.

The point is not that you should always take the $18 option. It is that most teams pick a model early, for reasons that have nothing to do with cost, and then never revisit it. If that default happens to be at the wrong end of this table, you are paying a hundred times more than you need to for the parts of your product where it does not matter.

Finding 2: output tokens are the bill

This is the one that changed how I build.

Almost every provider charges more for output than input, and the gap is wide. Across the 21 text models, the median output price is 4x the input price. Fifteen of the 21 charge at least 4x. Gemini 2.5 Flash charges 8.33x. Only one model in the set, Llama 3.1 405B on Together, prices input and output the same.

The practical consequence: output length matters more to your bill than prompt length. That runs against instinct. Everyone worries about long prompts and big context windows. But in the workload above I send four times more input tokens than the model returns, and on 9 of the 21 models output still accounts for the larger share of the bill. On most of the rest it is close to half.

Which means the cheapest optimization available to you is usually not switching models. It is telling the model to be brief. Capping output length, asking for structured fields instead of prose, and not letting a model narrate its reasoning into your production response will cut a bill faster than most migrations.

Finding 3: every category has a different shape

Text gets the attention, but most real products touch more than one category. The spreads are not remotely alike:

This is genuinely useful for deciding where to spend your attention. In speech-to-text the entire market fits inside a 4x band, so shopping around earns you very little and you should pick on accuracy and latency. In text and image, the spread is large enough that model choice is a real budget decision.

Also worth noticing: video is priced per second, and it is the category where a small product decision becomes an enormous number fastest. At Sora Turbo's $0.20 a second, a single 30 second clip costs $6. A feature that generates a hundred of those a day is $18,000 a month.

Finding 4: "premium" is not a price band

The models in this set carry a quality tier. You would expect premium models to cluster. They do not.

The cheapest premium-tier model on our workload is DeepSeek Reasoner at $98.78 a month. The most expensive is Claude Opus 4.8 at $3,037.50. That is a 31x gap inside the same tier. Two premium models, DeepSeek Reasoner and o3-mini, come in below the standard-tier Claude Haiku 4.5 at $202.50.

So "we need a premium model for this" is not a budget decision. It narrows you to a group whose prices still differ by more than an order of magnitude, and the work of choosing within that group is still ahead of you.

What I actually do with this now

Four habits came out of building this, and they have survived contact with real projects:

1. Price the feature before writing it. Not the model, the feature. Requests per day times tokens per request times price. If the answer is uncomfortable, the design is wrong and it is cheaper to learn that now.
2. Estimate output tokens honestly, then budget on that. It is the number that decides the bill and the one everyone lowballs.
3. Do not use one model for everything. Classification, extraction, and routing rarely need a frontier model. Reserve the expensive one for the step where quality is actually visible to the user.
4. Re-check quarterly. Prices fall and cheaper tiers appear. The model that was correct at launch is often not the correct one two quarters later.

The caveat that matters most

Everything above is about cost, and cost is the easy half. A model that is 169x cheaper and cannot do your task is not a saving, it is a rewrite. Nothing in this study tells you which model is good enough, because that depends on your prompts, your data, and your users' tolerance for being wrong.

What it does tell you is the size of the prize. If you know that switching a background step from a frontier model to a mid-tier one takes your bill from $600 to $70 with no user-visible difference, that is worth an afternoon of testing. Without the table, you never know the number is that big, so you never run the test.

That was the whole reason I built it. Not to be clever about pricing, just to stop guessing.