AI API Cost Comparison: How LLM Pricing Really Works

How LLM API pricing actually works

Almost every comparison of AI API costs quotes one number per model, and that number is almost always the input price. It is the least useful of the four numbers a provider publishes. A model bills on separate meters: tokens you send in, tokens it writes back, tokens read from a cache, and — with some providers — tokens written into that cache. Each meter has its own rate, and the rates are not close to each other.

A token is roughly three-quarters of an English word, so a million tokens is somewhere near 750,000 words. Prices are quoted per million tokens because individual messages are so cheap that per-message pricing would be all zeroes. That framing hides how quickly the meters add up in a real conversation, where every turn resends everything said before it.

The table below shows all four meters for a handful of models, taken from the same metadata feed that powers the model picker and the cost calculator on this site. Note how little the input column tells you: two models with the same input price can differ by a factor of three on output, which is the meter that moves most.

• Input — everything you send: your message, the conversation so far, any system prompt, any attached text.
• Output — everything the model writes back, including reasoning tokens on models that produce them.
• Cached input read — repeated context the provider has already seen, billed at a much lower rate than fresh input.
• Cache write — what some providers charge to place that context into the cache in the first place.

Output tokens are the expensive half

The single most reliable pattern in LLM pricing is that writing costs more than reading. To put a number on it rather than an impression, we took every text model in Oriveo’s metadata feed that publishes a per-token price — across all 15 providers — and compared each model’s output rate with its own input rate, as of 24 July 2026.

The median model charges exactly four times more for output than for input. Around one model in ten charges the same for both or less for output, which is typical of open-weight models served by inference hosts. At the other end, roughly one in seven charges more than six times, with the widest gap in the feed at twelve times.

This has a direct consequence for how you spend. Trimming your prompt is the optimisation everyone reaches for first, and it is usually the smaller lever. Asking for a shorter answer, capping output length, or choosing a model that does not think out loud at length will move a bill further than shaving a paragraph off the question. Reasoning models are worth a second look here, because the thinking tokens they generate are billed as output even when you never see them.

What actually drives your bill

People are usually surprised by their first API invoice for one of four reasons, and none of them is the headline price of the model. The mechanics below are true of every provider, because they follow from how chat APIs work rather than from any vendor’s policy.

The biggest one is context resending. An API call is stateless: the model has no memory of your previous turn, so the client has to resend the entire conversation with every message. A thread that has run for forty turns sends forty turns of history as input on turn forty-one. The cost of a conversation therefore grows roughly with the square of its length, which is why one long thread can cost more than twenty short ones covering the same ground.

Prompt caching is the counterweight, and it is worth understanding before you dismiss it. Providers that support it let repeated context be billed as a cached read instead of fresh input. In the feed we measured, about one model in five publishes a cached-read price, and where it exists the cached rate sits at a median of 10% of that model’s own input price — the lowest we found is under 1%, the highest around 58%. Some providers also charge to write the cache, typically at a premium over normal input, so caching pays off when the same context is reused several times and not when it is used once.

• Conversation history — resent in full on every turn, so long threads cost disproportionately more.
• System prompts and presets — reusable instructions are prepended to every single message, quietly multiplying their token count.
• Attachments — a document or image dropped into a chat becomes input tokens, and stays in the context for every later turn in that thread.
• Reasoning tokens — billed as output on models that generate them, whether or not the reasoning is displayed.
• Retries and regenerations — a regenerated answer is a second full billed request, not a free correction.

The price landscape across 15 providers

The table below is a snapshot of the published input-price range at each of the 15 providers Oriveo connects to. It counts only text models that publish a per-token price, and shows the cheapest and the most expensive of them at that provider. It is a map of where each provider sits, not a recommendation: the cheapest model at a provider and the most expensive one are rarely substitutes for each other.

Source and method, so you can check it: every number comes from Oriveo’s production metadata feed at api.oriveoai.com/api/metadata, contract version 47, generated 2026-07-24T01:00:09Z — the same feed the app uses to price messages and the same one behind the cost calculator on this site. Prices are in US dollars per million tokens, as of 24 July 2026. Image-generation models and models the provider prices per request rather than per token are excluded, because a per-token figure would be meaningless for them.

Two things stand out. The first is the spread: the cheapest input price in the whole feed is $0.01 per million tokens and the most expensive is $150, a factor of fifteen thousand between two rows in the same picker as of 24 July 2026. The second is that breadth of catalogue and cheapness are different axes — the aggregators carry the widest range because they resell many vendors, while single-vendor providers cluster tightly around their own tiering.

Treat every number here as perishable. Providers reprice, launch cheaper tiers, and retire models continuously; several of the rows below changed within the past quarter. Any article quoting model prices is a photograph, which is why the live feed and the calculator exist and why this page states its capture date instead of implying the numbers are permanent.

Why the same model has more than one price

Open two model directories and you will find the same model listed at different rates. That is not usually an error. Open-weight models are served by several inference hosts, each with its own hardware, throughput and margin, so a model can legitimately cost one thing on one host and something else on another. In the feed above, the same open-weight family appears at several providers at genuinely different rates.

The second reason is the layer you buy through. Aggregators sit between you and the underlying provider and have to fund that position somehow — through a spread on token prices, a top-up fee, a percentage on requests, or a credit system whose conversion to tokens is defined by the platform rather than by the provider’s price list. None of those is inherently bad; what matters is whether the mechanism is published. OpenRouter, for example, documents its terms openly: as of 24 July 2026 its published policy is a 5.5% fee on card top-ups with a $0.80 minimum, and for keys you bring yourself, the first million requests each month at no charge with 5% of the model’s normal price deducted in credits beyond that.

When you compare platforms, the question worth asking is not "how much is a credit" but "what is the published route from a provider’s list price to what I am charged". If a platform prices in credits and does not publish that conversion, the comparison you are making is not with the model’s price — it is with the platform’s pricing policy, and that policy can change without the model’s price changing at all.

Subscription or pay-as-you-go: which is cheaper for you

This is the question most people actually arrive with, and it does not have a general answer. A flat monthly subscription and metered API access cross over at some volume of usage, and that crossover point depends on your own messages: how long they are, how long the answers are, which model you pick and how long your threads run. Anyone who quotes a percentage saving without your numbers is guessing.

You can work it out in about five minutes, and the arithmetic is not hard. Take a genuinely typical week rather than your busiest one. Count the messages. Estimate the average length of the answers you get in words and multiply by roughly 1.35 to get tokens. Add the input side, remembering that each turn resends the thread so far. Multiply by the model’s published input and output rates, and compare that with the monthly fee you are considering. The cost calculator on this site does this against live prices so you do not have to keep the rates yourself.

A few structural patterns are stable enough to state without inventing numbers. Metered access tends to win when usage is light or spiky, when you use several models occasionally rather than one heavily, and when much of your work is short questions with short answers. Subscriptions tend to win at consistently high daily volume, and they have a real non-financial advantage: a predictable bill. Metered access with no visibility into per-message cost is the worst of both, which is exactly the failure mode a cost estimate on each message is meant to prevent.

How to actually reduce what you spend

Once you can see the meters, most of the savings come from a small number of habits rather than from hunting for the cheapest provider. In rough order of how much they move the number, for a typical chat workload:

What does not usually work is switching everything to the cheapest model in the catalogue. A model that needs three attempts to get an answer right at a fifth of the price is not a saving, and it costs you the time as well. The useful version of this advice is to match model to task — cheap models for extraction, formatting, summarising and translation, expensive ones for the work you would have paid a person to do.

• Start a new conversation for a new topic. This is the single largest lever, because it stops you paying to resend an irrelevant history.
• Ask for shorter answers when you want a shorter answer. Output is the more expensive meter on about nine models in ten.
• Match model to task instead of defaulting to the strongest one for everything.
• Keep system prompts and reusable presets tight — they are billed on every message that uses them.
• Use prompt caching where the provider supports it and you reuse the same long context repeatedly.
• Remove attachments from a thread once you are done with them, rather than carrying them through every later turn.
• Check the estimate on a message before repeating that pattern a hundred times.

How Oriveo shows you the cost

Every message in Oriveo carries an estimated cost, calculated from the provider’s published token pricing and the tokens actually reported, the moment the answer finishes. That estimate is available on every tier, including the no-sign-in one, because a cost you can only see on a paid plan does not help you decide whether to pay for anything. The same metadata feed used in the tables above is what supplies those prices, which is why the app does not need you to maintain a price list.

It is an estimate and it is labelled as one. Providers apply their own rounding, minimum billable units, per-account rates and occasional promotional pricing, and token counts are reported by the provider after the fact. The estimate is there to steer decisions during the month; your provider’s invoice is the final word, and when the two disagree the invoice is right.

Deeper analysis sits behind the paid plans. Usage Insights — spend broken down by provider and model, monthly trends and budget alerts — is part of Pro and Lifetime, which cost $9.99 a month, $59.99 a year or $149.99 once as of 24 July 2026. Those plans buy software features only: they include no AI usage, no model credits and no provider subscription, so the price of the app and the price of your tokens never get bundled into one number you cannot take apart.

What these numbers cannot tell you

A price table is a starting point, not a decision. Three things it leaves out are worth saying explicitly, because they routinely reverse a comparison that looked settled on price alone.

The first is tokens per task. Two models at the same rate can differ substantially in how many tokens they spend reaching the same answer, and a verbose cheap model can cost more per finished job than a terse expensive one. The second is the retry rate: an answer you have to regenerate is billed twice. The third is everything outside the token meter — rate limits, latency, context window, availability in your region, and whether the model can read the file formats you work with.

The honest way to use a comparison like this one is as a shortlist filter. Rule out the rows that are clearly outside your budget, try two or three candidates on your own real work, and look at what a finished task costs rather than what a million tokens costs. The per-message estimate exists precisely so that this experiment takes a day rather than a billing cycle.