LLM model pricing comparison

An LLM model pricing comparison looks easy at first glance. LLM stands for large language model, the type of AI behind tools like ChatGPT and Claude, and every vendor publishes a price list. One model has a lower rate for the text you send. Another can read more text at once. A third looks cheaper when bought through a reseller or cloud marketplace. Then real usage arrives, requests and answers get longer, and the cheap option can turn out to be the expensive one.

To compare models in a way that helps you choose, look at the whole request: what you pay for text going in and coming out, discounts on repeated text, how much text each request carries, the quality of the answer, where you buy the model and which tasks it suits. That is how you compare OpenAI, Anthropic, Google, Mistral, DeepSeek, Qwen, hosted Llama variants, Bedrock, Azure, Vertex, OpenRouter and other AI platforms on fair terms.

This guide is written for the people who sign off on that spend. Engineers usually run the comparison, while finance leaders approve the vendor and own the budget it is charged to. It covers what moves your bill, a framework to estimate real cost, and the pricing mistakes and hidden costs that eat into margin.

Key terms in LLM pricing

LLM pricing uses a handful of technical terms that decide how big the bill gets. These are the ones this guide relies on.

• Token: the unit AI vendors bill by, a small chunk of text of roughly three quarters of a word. Prices are usually quoted per 1 million tokens.
• Input and output tokens: input is the text you send to the model, meaning the question plus any instructions or documents. Output is the answer it writes back. Most vendors charge more for output.
• Prompt: the full package of text sent with each request, including standing instructions the user never sees.
• Context window: the maximum amount of text a model can read in one request.
• Prompt caching (cached input): a discount on text you send again and again, such as standing instructions.
• API: the connection your product uses to send requests to a model and receive answers. Buying "direct" means paying the model maker through its own API.
• Router: a service that lets a product reach many models through one connection and switch between them.
• Open models: models whose underlying files are published, such as Llama, Qwen or DeepSeek, so anyone can run them on their own servers or buy access through a hosting provider.

Why headline token prices mislead

Headline token prices mislead because they show one rate, usually the cost per 1 million input tokens, while your bill depends on how each request behaves from start to finish.

A model with a low input rate can still cost more if its output rate is high. A stronger model can look expensive on paper and still cost less in production if it solves a task in one attempt where a cheaper one needs three. A large context window sounds useful, but if your product sends whole documents with every request, you pay for the model to reread the same text again and again.

Where you buy matters too. The same family of models can be sold directly by its maker, through a large cloud provider such as Microsoft Azure or AWS, or through a router, and the features, caching, speed and effective price can differ on each. Add images, audio, connections to other software or step-by-step reasoning, and the cost picture changes again. The list price is a starting point, and your invoice shows what the model really costs to run.

• A low input rate helps little if the model writes long answers.
• A premium model may reduce retries, backup calls to other models and human review.
• A larger context window raises how much you can send per request, and the value depends on whether the task needs that much text.
• Prompt caching discounts can change the cost of high-volume workloads significantly.
• A model with the same name can come with different commercial terms on its maker's API, Azure, Bedrock, Vertex or a router.

How to compare LLM pricing on a like-for-like basis

Compare providers on the requests you actually run. Most serious pricing pages quote rates per 1 million tokens, which is a useful starting point, and the comparison becomes fair once you model your own workload against those rates.

Build a normalized request profile

Create one typical request for each important product flow, such as support chat, code generation, document analysis or agentic workflows, where AI completes a multi-step task on its own. Compare each flow separately, because each uses a different amount of text and needs a different level of quality.

Simple cost formula

Use this baseline formula for every candidate model:

Estimated request cost = (input tokens × input rate) + (output tokens × output rate) + (cached tokens × cache rate) + any platform fee or markup

If the workflow includes retries, tool calls, images or audio, add those as well, or the comparison will understate the real cost.

Minimum dataset to collect

Ask your engineering team for these numbers for each flow:

• Average input tokens per request
• Average output tokens per request
• Share of the prompt that repeats and could be cached
• Retry or fallback rate: how often a request fails and is sent again, or passed to a second model
• Whether the flow uses tools, images, audio or structured output (answers in a fixed format another system can read)
• Required speed, volume and uptime

Set a quality floor before you rank by price

Before comparing prices, agree a minimum standard the model has to meet: task success rate, code that passes tests, correct formatting, answers that stay faithful to the source documents, or the share of answers a human accepts. Public benchmarks such as MMLU and GPQA (standard tests of general knowledge and reasoning) and coding scores help build a shortlist, but results on your own tasks matter more.

Only compare cost between the models that clear that bar. A cheap model that gets the task wrong moves the cost elsewhere, into retries, corrections and unhappy customers.

Compare the full buying route, not only the model name

Many teams compare model families and ignore where they buy them. A model maker's own API price tells one story. The same or a similar model through Azure, AWS Bedrock, Google's Vertex AI, OpenRouter or another host may cost more or less, because of platform markup, regional versions, built-in governance features or different caching rules.

What to normalize in your comparison

• Input price: cost per 1 million input tokens. Matters most for long prompts, document-heavy workflows and RAG (retrieval-augmented generation, where the product looks up relevant documents and sends them to the model with the question).
• Output price: cost per 1 million output tokens. Often the bigger driver in chat, content generation and reasoning tasks.
• Cached input: the discounted rate for repeated text at the start of a prompt. Can lower spend significantly in high-volume products with stable prompts.
• Context window: the maximum prompt size. Valuable only if you need large context and can afford it.
• Max output: the maximum answer length. Matters for long documents and multi-step reasoning.
• Task quality: success rate, coding accuracy and reliability of structured output. A better model can reduce retries and human cleanup.
• Deployment route: direct API, cloud platform, router or host. The same model family can carry a different effective cost and different controls on each.
• Compliance fit: region, data handling and procurement rules. The cheapest route may not meet enterprise or EU requirements.

Same model, different bill: direct APIs, clouds and routers

The same model can produce a different bill depending on where you buy it, because LLM pricing is several markets stacked on top of each other: model makers selling direct, managed cloud platforms, routing services and hosts that run open models. Each route changes how pricing, access and governance work.

Common buying routes

• Direct provider API: best for access to the newest models, simpler pricing and fast experimentation. Total cost can rise through separate billing per vendor, fewer controls across providers and no built-in backup if one vendor fails.
• Managed cloud platform: best for enterprise procurement, control over where data is processed, security and governance. Total cost can rise through platform-specific pricing, regional price differences and possible markup.
• Router or marketplace: best for switching models quickly, one connection to many vendors and automatic fallback. Total cost can rise through markup, different rounding and extra monitoring or routing fees.
• Open-model hosting provider: best for low token prices on selected workloads and a wide choice of models. Total cost can rise through uneven quality, missing features and host-specific limits.
• Self-hosted open models: best for predictable high volume and heavy customization. Total cost can rise through hardware costs, servers sitting idle, engineering time and responsibility for uptime.

Direct provider APIs

Direct APIs are usually the cleanest place to start a comparison. Pricing is easier to read, new models arrive there first, and there is no extra commercial layer between you and the model maker. For testing the newest models or moving quickly, this route gives the clearest view of raw model economics.

Managed cloud platforms

Azure, AWS Bedrock, Vertex AI and similar platforms add considerations beyond price. A company may accept a higher rate because the route fits its procurement process, regional deployment, data-handling policy, network setup or existing cloud commitments, such as an annual spend already agreed with AWS. For many finance and compliance teams that trade-off makes sense, as long as it is measured explicitly.

Routers and AI marketplaces

Routers make experimentation easier: one connection, several vendors and automatic fallback when one fails. That speed is valuable, especially for product teams testing several models. Before treating a router as the cheapest route for long-term production, measure its markup, retry behavior and cache support, and how easily you can trace costs back to features, customers and teams.

Pricing factors that move your real cost

Five factors move the real cost of an LLM more than its headline rate: the split between input and output pricing, how much context each request carries, cache discounts, answer quality, and the use of reasoning, tools and images.

Input vs output token pricing

Most teams look at prompt cost first. That makes sense when the product sends long documents or large amounts of retrieved text. For many products in production, though, output cost deserves equal or greater attention, because support bots, content assistants, coding tools and reasoning-heavy workflows often write far more text than the user sends in.

If your product rewards short answers, a model that follows instructions well and has cheaper output can beat a model with a lower input rate. If it encourages long, detailed answers, output pricing quickly becomes a question for the board.

Context windows and long-document workflows

A large context window lets you send more information per request, and it tempts teams to send everything every time. That habit inflates spend without anyone noticing.

For document-heavy workflows, compare two approaches: sending the full document with every request, or sending only the relevant parts through retrieval, splitting documents into chunks, summarizing first or processing in stages. A smaller or mid-tier model with good retrieval often costs less than a premium long-context model and gets the same result. Use the large window when the task genuinely needs it.

Cache discounts and repeated prompts

Repeated text at the start of a prompt is one of the easiest places to save. Standing instructions, policy text, tool definitions, brand rules and reference material often change slowly, and when a provider offers prompt caching, that repeated text is billed at a lower rate.

This matters most in high-volume products where requests follow a predictable structure. A support assistant, a copilot built into a product or an internal knowledge tool may reuse the same instructions thousands of times a day. In that case the cache discount can change the economics more than choosing between two similar list prices.

Quality per dollar beats lowest raw price

The best LLM for the price is the one that clears your quality bar at the lowest total operating cost. That total includes retries, failed safety checks, broken structured output, slower task completion, human quality checks and errors customers see.

Raw pricing tables show token costs cleanly but cannot show what a bad answer costs inside your product. For coding, a stronger model may save developer time. For customer support, a more reliable model may reduce escalations. For back-office automation, more reliable structured output may cut manual correction. Those downstream savings belong in the comparison.

Reasoning, tools, and multimodal inputs

Many products now go beyond text. Tool use (the model calling other software, such as a search engine or a database), structured output, images, audio and multi-step agent flows all change the cost profile, and images and audio are often priced differently from text. So does a model that thinks longer, calls more tools or writes more intermediate steps before its final answer.

When you compare models for agents or complex automation, measure cost per successful task. A slightly pricier model that finishes the job in one pass can beat a cheaper model that loops, retries or makes several tool calls.

Best-value model types by use case

The best-value model depends on the job it does, because each type of workflow rewards a different pricing profile.

Chatbots and customer support

For support and conversational assistants, value usually comes from balanced models with fast responses, reliable instruction-following and reasonable output cost. Predictability matters here, and so does strong prompt caching, because the assistant reuses the same rules and policy text all day.

In many support flows, the winning model is the one that handles common requests well, hands over cleanly to a human and keeps answers short when short is enough. A model cascade often works best: a small or mid-tier model answers first, and a premium model steps in only when needed.

Code generation and developer workflows

Coding changes the calculation. A cheap model that writes plausible but wrong code becomes expensive fast, through debugging time and production bugs, so stronger coding ability, better tool use and more reliable structured output can justify a higher token rate.

Compare models on tasks from your own codebase, such as fixing bugs, writing tests, updating documentation and migrating to new APIs. Measure how often suggestions are accepted, how many retries they need and how long review takes. In engineering workflows, quality per dollar usually matters more than tokens per dollar.

Large document processing

For summarizing, extracting data, classifying, reviewing contracts and other large back-office document pipelines, input cost often dominates. Long-context models, retrieval design and batching (grouping requests to run together, usually at a lower rate) matter most here.

If the task is repetitive and quality requirements are stable, cheaper models or open-model hosts may offer strong economics. If it needs nuance, legal care or complex synthesis, a premium model may still win. The question to ask is whether you are paying for the model to understand the document or to reread the same document more often than needed.

Agentic and multi-step workflows

Agent systems make cost comparisons misleading, because one task the user sees may trigger several model calls, tool calls and retries. The right unit of cost is the completed workflow.

For these systems, compare success rate, speed, tool reliability and error recovery together. A model that is cheaper per token can still lose badly if it fails more often or needs more coordination. Finance, product and engineering need the same view of cost here, because otherwise the bill arrives in one team while the trade-off sits in another.

How to cut LLM spend without hurting product quality

Most teams can reduce LLM spend without harming the product by tightening how it uses models. Once you have compared models properly, this is where expense management and cost control begin.

1. Route simple work to smaller models. Keep premium models for tasks that need deeper reasoning, better coding or stronger reliability.
2. Cap answer length. Many products pay for long answers users never read, and a limit on response length is one of the fastest savings available.
3. Trim unused prompt text. Remove duplicated instructions, oversized examples and retrieved text the model does not need. Small excesses multiply across millions of requests.
4. Cache stable prompt text. Standing instructions, tool definitions and policy text should be billed at the cached rate whenever the provider offers one.
5. Batch background jobs. Tasks that don't need an instant answer can run in slower processing tiers, which vendors often price lower.
6. Track spend by feature, customer and team. A provider invoice at month end only shows overspend after it has happened.

If you pay AI vendors by card, issue vendor- or team-specific corporate cards with spend controls to enforce limits and reduce the risk of overage. For vendors that invoice outside cards, centralize approvals and manage vendor invoices to keep budgets on track. For more ways to control variable, usage-based spend, see improving spend management.

From price tables to business decisions

A pricing table helps you buy a model. Once AI is in production, running a business on that model raises different questions: which feature drives spend, which customer segment is costly to serve, what happens to gross margin if you switch model families, and which team is creating avoidable retries or oversized prompts. For a budgeting framework to evaluate new cost lines like LLM providers, see financial management in start-ups.

That is the gap between comparing models and AI spend management. In most companies, the answers sit across fragmented invoices, vendor dashboards and spreadsheet archaeology. Husk connects AI usage and spend to requests, features, customers and teams in one live view, so the answers come from one place, updated as usage happens.

Husk also answers the question this guide keeps returning to: what a model switch does to margin. Its model-switch simulation shows the effect on your margin before you move a feature to a cheaper or stronger model, and a customer-level AI P&L sets each customer's AI cost against the revenue they bring in.

For founders, that means fewer surprises. For finance teams, it means an AI P&L you can explain to the board. For product teams, it means moving quickly without assuming margin will sort itself out later. To connect these decisions to runway planning and cost discipline, read mastering runway.

FAQs about comparing LLM model pricing

How does LLM API pricing usually work?

Most providers charge separately for input and output tokens, usually quoted per 1 million tokens. Some also discount cached input and charge differently for images, audio, tool-heavy workflows or premium reasoning tiers. The published rate is a starting point: your real cost depends on prompt size, answer length, retry rate and where you buy the model.

Which LLM API is cheapest?

The lowest published rates usually come from smaller models, hosts of open models or aggressive marketplace offers. The cheapest API can still be an expensive production choice, because if quality is too low you pay the difference through retries, poor output or manual review. Decide first what cheap means for your workflow: raw token cost, cost per successful task or cost per satisfied customer.

Why is output pricing often more important than teams expect?

Many products write more text than they receive. A user may send a short question while the assistant returns a long answer, a block of data, a code change or several reasoning steps, and output tokens usually cost more than input tokens. If nobody manages answer length, output size and tool verbosity, a model with a low input rate can still produce a high total bill.

Is OpenAI more expensive than Claude?

There is no single answer. It depends on which model tiers you compare, whether the work is chat, coding, reasoning or document analysis, and whether cached input applies. It also depends on where you buy: a comparison between the two companies' own APIs may look different from one through Azure, Bedrock or a router. Compare matched tiers on the same workload before calling either family cheaper.

Is DeepSeek cheaper than OpenAI?

On raw token pricing, DeepSeek and hosts serving cost-competitive open models often look cheaper than premium frontier APIs, meaning the most advanced models from the leading labs. That can be a strong advantage for bulk processing, experimentation or cost-sensitive internal tools. Before moving production traffic, also compare speed, reliability, structured output quality, support for the features you need and the governance you require.

Are open models always cheaper than closed models?

No. Open models can be cheaper, especially for high-volume text workloads or with an efficient hosting provider. Once you add hosting, engineering time, tuning, monitoring, uptime responsibility and lower success rates on harder tasks, the cost advantage can shrink or disappear. Open models work best when the workload is well understood, repeatable and large enough to justify the setup.

Should I buy direct from a provider or through Azure, AWS, Vertex, or a router?

Buy direct when you want the clearest raw economics and the fastest access to new models. Choose a managed cloud route when procurement, regional deployment, security controls or your existing cloud setup matter more than the list price. Use a router when flexibility and fallback between vendors are strategically valuable. Whichever you pick, compare the route you can actually deploy, govern and reconcile.

How do I forecast monthly LLM spend?

Start with workload volume. Estimate requests per day, average input tokens, average output tokens, retry rate, the share that can be cached and any overhead from images or tool use. Multiply that into a monthly model, then add a buffer for traffic growth and experimentation. Most teams should also forecast by feature and customer segment, which gives better financial insights in real time.

What is the best LLM for price overall?

No single model wins across all workloads. For high-volume support, a fast, balanced model with good caching may offer the best value. For coding, a stronger model can justify a higher rate by cutting review time and retries. For document-heavy back-office work, input cost and how much text you send matter most. The best-priced model is the one that meets your quality bar at the lowest total cost of delivering the outcome you care about.

‍