LLM API pricing: I compared 198 listings in 9 families

Methodology: a dated catalog, explicit filters, and three token mixes

I used the saved response from the public OpenRouter models API, collected on 6 October 2026, as the source of the catalog records. The preserved response contains 464 entries before this study’s filters. I read the raw catalog alongside the derived row file and family summary, rather than treating the summaries as a substitute for the underlying entries. This is one cross-sectional snapshot. It is not a daily price history, a longitudinal experiment, or a measurement of transactions completed at those prices.

I restricted the study to these nine exact developer namespaces: openai, anthropic, google, mistralai, deepseek, x-ai, cohere, amazon, and qwen. The namespace is the segment before the slash in the model ID. It is a grouping key, not proof of which infrastructure operator would serve a request. All prices came through OpenRouter’s catalog. Calling these nine direct providers would misstate the collection method: I did not independently retrieve each developer’s own API pricing schedule, commercial agreement, or regional rate card.

The inclusion rule required the catalog’s output modalities to be exactly text, positive listed prompt and completion rates, and an ID without the free or batch suffixes excluded from this comparison. Text-only output does not necessarily mean text-only input: a retained model may accept another input modality. Models listing image or audio output alongside text were outside scope. Reapplying these conditions to the saved raw response reproduced the 198 retained IDs exactly, with no missing or additional IDs. The retained dataset also contains 198 unique IDs.

I kept catalog IDs as the unit of observation. Different versions and variants remain different rows when OpenRouter gives them different IDs. I did not collapse them into an assumed underlying architecture or declare every row a unique base model. That choice is useful for someone comparing selectable listings, but it influences the distribution. A namespace with many historical variants contributes more observations than a namespace with a short catalog. It does not contribute more users, more revenue, or more independently trained systems.

For each retained entry, I used the prompt and completion values in the raw pricing object. Those values are dollars per token. I multiplied each by one million to obtain separate input and output prices in dollars per million tokens. I preserved the model ID, namespace, context length, model-card URL, and optional intelligence index in the derived dataset. Additional pricing fields, where present, were not folded into the base token formulas. The output is therefore a standardized prompt/completion comparison, not a reconstruction of a complete invoice.

I then calculated three hypothetical mixes of one million total tokens. If P is the listed input price per million and C is the listed output price per million, the 80/20 result is 0.8P + 0.2C; the 50/50 result is 0.5P + 0.5C; and the 20/80 result is 0.2P + 0.8C. The first number always denotes the input share. These scenarios contain the same total token volume, so the difference isolates the listed price sensitivity to composition. They do not represent three observed customer workloads.

This denominator needs care. One million input tokens plus one million output tokens is two million total tokens, not the 50/50 scenario shown here. Nor do the shares refer to words, requests, or wall-clock time. Tokenization can differ between models, so equal token counts do not guarantee equal amounts of underlying text. For an actual application, I would count input and billed output using its own request records and then apply the two prices separately. The scenario table is a planning aid when those records are unavailable.

I checked every stored scenario value against its weighted input/output calculation. All 198 entries passed that arithmetic check across all three mixes. I also checked the nine family counts against the retained IDs. Family medians are medians of the individual listing costs at the stated mix; they are not usage-weighted prices. For an even-sized family, the midpoint averages the two central sorted listing costs. I display readable decimal amounts in the prose rather than exposing floating-point artifacts such as a trailing string of zeros.

The family summary uses 80/20 as its reference mix. The other scenarios remain available at row level because an input-heavy median should not masquerade as an output-heavy budget. I use exact named rows when explaining a cost change, and attach their OpenRouter model cards so readers can inspect the listings. Those cards are primary sources for the catalog entries, but they are live pages. A later visit may show a changed price; the saved snapshot and downloadable derived rows are the evidence for this article’s date.

The optional intelligence index comes from third-party benchmark metadata relayed by the catalog, specifically its Artificial Analysis field. I did not run that benchmark, validate its testing conditions, or treat absent values as zero. I do not calculate intelligence per dollar, infer that price causes capability, or rank application quality from that field. Finally, I made no inference calls during this study. There are no measured latency, throughput, reliability, or task-success results here. Reproduction means rebuilding the filtered price calculations, not claiming to reproduce model performance.

Finding 1: catalog breadth makes an overall “average family” misleading

The retained counts are OpenAI 60, Qwen 53, Google 20, Mistral 19, Anthropic 15, DeepSeek 14, xAI seven, Cohere five, and Amazon five. These are counts of listings under the exact namespaces, not counts of serving companies. OpenAI and Qwen together account for about 57.1% of the retained rows. An overall listing statistic would therefore lean heavily toward those two catalogs simply because they contain more eligible entries.

I prefer family summaries followed by named rows. Giving every namespace equal weight would answer a different question, while weighting by real traffic would require usage data I do not have. Neither method is automatically the “market price.” The denominator must match the decision: selecting a listing, comparing catalog composition, and predicting a customer invoice are distinct exercises.

There is another trap in the family labels. The openai/gpt-oss-20b listing and the openai/o1-pro listing share a namespace but occupy very different price positions. A family bucket is not a contract, deployment mode, or performance tier. Our open versus closed AI analysis covers that separate distinction; the catalog calculation should not flatten it into a brand score.

Finding 2: the 80/20 medians are useful shortlisting signals, not quotes

For one million total tokens at 80% input and 20% output, I calculated these family medians: DeepSeek $0.349, Mistral $0.3918, Qwen $0.44, Cohere $0.54, Amazon $0.74, Google $0.74, xAI $1.50, OpenAI $3.40, and Anthropic $9.00. Every amount describes the middle of that family’s retained OpenRouter listings at this particular token mix.

The equality between Amazon and Google illustrates why a median is insufficient for choosing a model. The Nova Micro row costs $0.056 in this scenario, whereas Nova Premier costs $4.50. Google’s Gemma 3 4B row is $0.06, while Gemini 3.1 Pro Preview is $4.00. Equal medians do not imply interchangeable portfolios.

I would use the summary to identify where to inspect, then consult exact rows for a budget proposal. It is not defensible to insert the median into a purchase order unless the chosen listing actually has that price. The table below also makes the unequal family sample sizes visible, so a five-row midpoint is not mistaken for evidence with the same catalog breadth as a sixty-row midpoint.

Finding 3: cheap rows and expensive rows coexist inside the same namespace

The OpenAI namespace spans $0.0324 for gpt-oss-20b to $240 for o1-pro at 80/20. Anthropic’s retained range runs from $1.80 for Claude Haiku 4.5 to $27 for Claude Opus 4.1. Those endpoints are snapshot price facts, not a recommendation to adopt the cheapest endpoint or proof that the most expensive endpoint delivers a corresponding quality gain.

The same issue appears outside those namespaces. Mistral Nemo is $0.0212 at 80/20, compared with $2.80 for Mistral Large. Within Qwen, Qwen3.7 Flash is $0.05, while Qwen3.8 Max Prime is $5.60. A blanket claim that an entire namespace is cheap misses both the range and the actual selectable option.

My practical response is to retain an exact ID in every cost discussion. I would also record why that row passed the task’s requirements before comparing rates. Our ChatGPT, Claude, Gemini, and DeepSeek comparison addresses a broader product choice. This dataset cannot replace that choice with an unqualified price ordering, especially when a product interface and an API listing are different things.

Finding 4: output-heavy work exposes a different budget

The token mix changes the answer without changing the model. Claude Haiku 4.5 has listed input/output rates of $1 and $5 per million respectively. Its calculated cost moves from $1.80 at 80/20 to $3 at 50/50 and $4.20 at 20/80. Gemini 3.1 Pro Preview has rates of $2 and $12, producing $4, $7, and $10 across the same scenarios. These are weighted calculations, not prices observed in paid requests.

For a hypothetical workload of 100 million total tokens, those endpoints imply $180 versus $420 for Haiku, and $400 versus $1,000 for Gemini, as the mix moves from input-heavy to output-heavy. Those estimates hold total tokens fixed and include only the modeled token charges. I would not describe either figure as a monthly invoice without specifying that the 100 million tokens are a hypothetical monthly volume and that other billable items remain outside the calculation.

Long explanations, generated reports, and repeated revisions are reasons to investigate output share, not evidence that a particular business necessarily has an output-heavy workload. Conversely, a short extraction answer from a large document suggests a different planning scenario. Our prompt-engineering guide is relevant here: specifying the required output can influence the tokens your system requests, but I have not measured the savings from any prompting technique.

Finding 5: lower price sensitivity is a separate property from lower price

I compared both the starting cost and the movement across mixes. DeepSeek V4 Pro has input/output rates of $0.2088 and $0.4176 per million. Its three scenario costs are $0.25056, $0.3132, and $0.37584. At the hypothetical 100-million-token scale, the input-heavy and output-heavy estimates become $25.056 and $37.584. The calculation is comparatively insensitive to composition because the two listed rates are closer together.

Grok Build 0.1 similarly moves from $1.20 to $1.50 to $1.80, using input/output rates of $1 and $2. By contrast, Grok 4.5 moves from $2.80 to $4 to $5.20. These examples distinguish price sensitivity from namespace identity. They do not establish which model would generate fewer tokens for the same useful answer.

I would treat a narrower scenario spread as easier to budget when composition is uncertain, not as a quality score. A low spread can coexist with a high absolute rate, and a low absolute rate can coexist with expensive retries. The scenario chart gives a bounded view of rate sensitivity; actual token demand still requires application evidence. That boundary prevents a spreadsheet property from becoming an unsupported recommendation. Our fine-tuning decision guide addresses another possible intervention: changing the model or its adaptation strategy requires a separate evaluation and cost model, not an assumed discount applied to these catalog rows.

Finding 6: a sub-dollar shortlist is broad, but still needs task gates

At the 80/20 mix, 106 of the 198 retained entries cost no more than $1 per million total tokens. That is a catalog threshold count, not a count of acceptable substitutes for a production model. It tells me a tight token budget does not automatically reduce the search to one namespace. It cannot tell me how many candidates meet a language requirement, return reliable structured output, or satisfy an organization’s data handling rules.

For example, Command R7B 12-2024 is $0.06 at 80/20, while Command A is $4.00. Neither number certifies retrieval performance. Amazon’s Nova 2 Lite is $0.74 at 80/20 but $2.06 at 20/80. A shortlist built around an input-heavy ceiling must be rebuilt if the intended workload is mainly generation.

I would first define pass/fail requirements, then price only the passing candidates. Our AI coding tools benchmark-source comparison explains why workload-specific evidence matters. For this study, no candidate passed a measured application test because no such test was run. The threshold is an invitation to evaluate more precisely, not a list of endorsed models.

Finding 7: context length is a constraint, not a cost allowance

The dataset preserves catalog context length because it can eliminate an otherwise attractive candidate. Qwen3.7 Flash lists 1,000,000 tokens of context alongside a low base rate, while DeepSeek V4 Pro and Gemini 3.1 Pro Preview list 1,048,576. That metadata describes a catalog capacity field. It does not mean a request can use that entire amount as output, or that every route and every setting provides identical practical behavior.

A larger context also does not provide free input tokens. If an application sends more text, its input bill depends on the billed token volume and applicable rate. My fixed one-million-total-token comparison does not model a different request size for each model. Nor does it establish whether using a longer context helps a particular answer enough to justify the additional input. That would require a controlled task comparison.

I would consult the listing’s endpoint details and output limits before adopting a long-context candidate, then measure whether the application needs that capacity. Our context-window engineering guide is a useful companion. A context field, a price field, and successful retrieval from a long document are three separate claims. Only the first two are represented in this catalog analysis.

Finding 8: price per successful workflow needs evidence this catalog cannot supply

An agent can spend tokens on planning, tool results, conversation history, and repeated attempts before producing an accepted result. The relevant operational denominator may therefore be an approved document or a resolved case, rather than a million tokens. I can calculate the price of the tokens; I cannot calculate that success denominator from a catalog entry. There are no observations here of how often any listed model retries or fails.

For budgeting, I would separate the baseline token estimate from a clearly labeled allowance for uncertainty. I would then record actual billed input, actual billed output, retry reasons, and acceptance outcomes during a pilot. That makes a later comparison possible without assuming that equal prompt lengths or equal model names imply equal completed work. It also identifies whether a price change or a workflow change caused the bill to move.

Our AI agents architecture explainer describes those multi-step systems. The present study contributes a reusable rate layer for such a budget, not a measured agent cost. It would be misleading to multiply a catalog price by an invented number of reasoning steps and present the result as research. Hypothetical assumptions belong in a planning worksheet, visibly separated from observed usage.

Finding 9: an auditable procurement choice starts with the row, not the ranking

My preferred decision sequence is to identify the application’s mandatory capabilities and data constraints, choose exact candidate IDs, estimate its input/output mix, and compare the relevant scenario. Next, I would inspect the available serving routes and their terms, obtain any required approval, and run a separately documented pilot. Only that pilot could support claims about quality, response time, or cost per accepted outcome. The catalog comparison ends before that evidence begins.

The intelligence-index field cannot bridge the gap. It is present for 148 retained entries, but missingness is not a low score, and the supplied values are not my measurements. Combining them with this snapshot’s rates into an “intelligence per dollar” ranking would create a composite metric whose relevance to the buyer’s task has not been established. I therefore leave the metadata separate from the budget decision.

I would also preserve the collection date, formula version, selected row, and route assumptions in an approval record. Our AI privacy guide covers a consideration the price columns cannot settle. A cheaper listing that fails an organization’s handling requirements should not remain in its eligible shortlist. That is a governance constraint, not an unexplained premium to subtract from the pricing analysis.

Limitations: what this study does not establish

This is a snapshot of one intermediary catalog, filtered to nine specified developer namespaces. It excludes other namespaces, free listings, batch variants, and entries with non-text output modalities. The sample is therefore neither the entire OpenRouter catalog nor the entire LLM market. It is also not a random sample of applications or buying decisions. Catalog breadth reflects listing practices, including versions and variants, rather than market share or independent deployments.

The prompt/completion formulas intentionally omit other possible charges and adjustments. They do not incorporate cache behavior, route-specific differences, long-context tiers, tool charges, multimodal billing, discounts, credit fees, taxes, or contractual minimums. Not every excluded item necessarily applies to every row; the point is that this study did not model those items. A live request may also expose billing details unavailable from the two standardized price fields.

I made no model calls. Consequently, I cannot establish answer quality, useful output length, billed reasoning behavior, latency, throughput, uptime, or the rate of successful completion. Equal total tokens are a controlled arithmetic assumption, not proof of equal work. Different tokenizers, different prompting requirements, and different retry patterns could change a real comparison. A cheap row in the table may be unsuitable for a task, while an expensive row may or may not justify its cost.

The context and intelligence metadata were carried through from the catalog, not independently validated. Third-party scores may have different evaluation coverage and timing; missing values remain missing. Live model cards and the API may change after the collection date, so current prices should be checked before procurement. Finally, the article is an automated research-desk draft with editorial review pending, not a claim of expert credentials or a completed human review. Its strongest evidence is the preserved source, transparent filters, and arithmetic that another reader can recompute.

Frequently asked questions

1. Did you compare nine direct API providers?

No. I compared listings under nine developer namespaces inside OpenRouter’s catalog. The family labels identify the model-ID grouping, not nine independently collected rate cards or nine measured serving systems. A direct developer API may have different prices, features, discounts, and terms.

2. What exactly does the 80/20 price mean?

It means 800,000 input tokens and 200,000 output tokens, totaling one million. I multiply the input price per million by 0.8 and the output price per million by 0.2, then add them. It is a scenario cost in dollars, not a blended rate for an observed customer.

3. Which family is cheapest?

DeepSeek has the lowest retained family median at the 80/20 mix, $0.349. That does not make every DeepSeek listing cheaper than every alternative. Mistral Nemo, for example, is $0.0212 in that scenario. The row, task requirements, and workload mix matter more than a family-level slogan.

4. Does a lower listed price mean better value?

Not by itself. This study measures neither task success nor the number of tokens needed for a useful result. A value comparison needs a relevant application test and an acceptance rule. I can help estimate token charges, but I cannot certify cost per successful outcome from these records.

5. Did you test speed or model intelligence?

No inference calls were made and no latency was measured. Any intelligence index in the downloadable rows is third-party metadata relayed by OpenRouter, not an AI Made benchmark. I did not turn it into a price-adjusted ranking or infer a causal relationship between capability and rates.

6. Are these the costs of ChatGPT or Claude subscriptions?

No. These are metered API catalog rates for named listings, expressed through token scenarios. Consumer subscriptions can bundle interfaces, limits, and features that this dataset does not describe. The earlier pricing guide addresses that broader purchasing context; this appendix is for reproducible catalog arithmetic.

7. Can I use the table to estimate a production budget?

Use it as a baseline, then replace the scenario shares with your actual billed input and output volumes. Check the chosen route and all applicable charges. Add measured retry and workflow behavior when you have it. Do not use a family median as the quoted price of an exact model.

8. How can I reproduce or update the comparison?

Preserve a dated API response, apply the namespace, modality, paid-rate, and suffix filters, and recompute the three weighted costs for every retained ID. Recount the rows and medians before charting. A new snapshot is an updated study; it should not silently overwrite the evidence for this date.

Full data appendix: every retained listing, not just the examples

The appendix table contains all 198 retained rows. Each row identifies the exact catalog ID and developer namespace, separate input and output prices per million tokens, the 80/20, 50/50, and 20/80 scenario costs, catalog context length, optional third-party intelligence metadata, and its source model-card link. The summary and examples are navigation aids; they are not substitutes for this complete listing.

The data download supports checking an individual calculation, building a task-specific shortlist, or comparing this snapshot with a future collection. Preserve the date when reusing a number. If a live model card differs from a saved row, distinguish a subsequent catalog change from an arithmetic mistake before drawing conclusions.

Get the data: Download the 198-row CSV and the original 464-entry API response and reproduction script (ZIP).

Conclusion: budget the workload, then validate the candidate

I found a wide range of listed token costs across 198 OpenRouter entries, with substantial variation inside developer namespaces as well as between their medians. The three token mixes make the budget sensitivity visible without pretending to measure real application behavior. The resulting dataset is useful precisely because its claim is limited: it explains a dated catalog and a reproducible calculation.

My concrete advice is to carry an exact ID into the budget, keep input and output separate, check the current route and terms, and evaluate success on your own task before committing. Use the full appendix rather than a family slogan. Our AI readiness assessment offers the broader organizational check before that commitment. This research supplies the price baseline; deployment readiness and measured value remain work to do.