Everyone building with AI right now asks the same question at some point: what’s the cheapest AI API I can get away with using? The honest answer is that the model with the lowest sticker price is rarely the one that actually saves you the most money once you factor in retries, wasted tokens, and the engineering hours spent babysitting a model that isn’t quite good enough for the job. I’ve watched teams chase a $0.02 per million token model, only to burn three times that in failed function calls and manual cleanup. Price per token is the easy number to compare. It’s also the least useful one on its own.
This isn’t a spreadsheet dump of every rate card on the market, those change too fast for that to stay accurate for more than a few weeks anyway. It’s a breakdown of how the pricing actually works, which providers are genuinely worth using at the low end, and where cheap turns into expensive once you look past the headline number.
How AI API Pricing Actually Works
Every major provider, OpenAI, Anthropic, Google, DeepSeek, Mistral, and the open weight hosts like Together and Groq, charges per token, split into input and output. Input is what you send the model: your prompt, your system instructions, any context you’re feeding it. Output is what the model writes back. Output almost always costs more per token than input, often two to five times as much, because generating each token requires a full pass through the model while reading input can be batched more efficiently on the provider’s side.
A token isn’t a word. It’s roughly three quarters of a word in English, so a thousand word document runs somewhere around 1,300 to 1,500 tokens depending on how much technical vocabulary or punctuation it contains. That distinction matters when you’re estimating monthly costs, because people routinely underestimate token counts by assuming word count and token count are close enough. They’re not, especially with code or non English text, which tokenizes less efficiently than plain English prose.
Why the “Per Million Tokens” Number Is Misleading on Its Own
Providers quote prices per million tokens because the actual per request cost is a fraction of a cent and looks meaningless on its own. But that framing hides a real gap between models. A flagship model might run five dollars per million input tokens and twenty five per million output. A small, fast model from the same provider might run a nickel and twenty cents. That’s a hundred fold difference, and it’s exactly why so many teams now route easy tasks to a cheap model and only send the hard ones to something expensive, rather than defaulting every request to whatever model they started the project with.
Which Providers Are Actually Cheap Right Now
Open weight models hosted by providers like Together AI, Groq, and Fireworks tend to sit at the absolute floor of the market, sometimes just a couple of cents per million input tokens for smaller models like Llama 3.1 8B or similar lightweight variants. These are genuinely useful for high volume, low complexity tasks: classification, simple extraction, basic summarization where the accuracy bar isn’t demanding.
Above that tier sits a cluster of small models from the major labs themselves, things like GPT’s nano tier, Gemini’s Flash-Lite line, and DeepSeek’s smaller checkpoints, usually landing somewhere between five and twenty cents per million input tokens. This is the tier most production apps should actually be running on for the bulk of their traffic, because it pairs low cost with enough reasoning ability to handle real customer facing tasks without embarrassing mistakes.
Flagship models, the ones people mean when they talk about frontier quality, are a different category entirely and shouldn’t be compared on the same axis. These run anywhere from a couple of dollars to ten dollars or more per million input tokens, with output priced several times higher again. Paying that rate makes sense for genuinely hard reasoning tasks, complex coding, or anything where a wrong answer is expensive. It’s overkill for a chatbot answering FAQ questions.
The Free Tier Trap
Google’s AI Studio and a handful of other platforms offer free tiers with zero cost input and output on select models. It’s tempting to build on these and call your API bill solved. Read the terms first. Free tier usage is frequently used to improve the provider’s own models, which is a dealbreaker if you’re processing anything confidential, whether that’s customer data, internal documents, or proprietary code. Free tiers also tend to come with tight rate limits that make them unworkable once you have real traffic. Treat them as a place to prototype, not a place to run production.
What Actually Drives Your Real Bill
The single biggest lever most teams ignore is prompt caching. If you’re sending the same system prompt, the same document context, or the same few shot examples on every request, caching lets the provider charge you a fraction of the normal input rate for the repeated portion. Depending on the provider, that discount runs anywhere from fifty to ninety percent off the cached tokens. For an app with a long, stable system prompt and short, varying user messages, caching alone can cut the bill dramatically without touching the model choice at all.
Batch processing is the second lever, and it’s underused because it adds latency. If your workload doesn’t need a real time response, overnight report generation, bulk content tagging, data enrichment jobs, most providers offer a flat discount, often around fifty percent, for submitting requests asynchronously in batches instead of one at a time. Teams running large offline jobs and still paying real time rates are leaving money on the table for no reason.
Then there’s the model routing question, which is really the heart of cost control. Instead of picking one model for your entire application, route requests based on difficulty. A cheap, fast model can handle intent classification, simple lookups, and formatting tasks. Anything that needs deep reasoning, multi step planning, or nuanced judgment gets escalated to a stronger, pricier model. This hybrid approach is how most serious production systems actually keep costs down, and it consistently beats picking a single “good enough” model for everything.
Where People Get Burned Chasing the Lowest Price
The cheapest model on paper is often the one that requires the most retries. If a small model gets the output format wrong, misses a step in a multi part instruction, or hallucinates a detail, you end up paying for that failed attempt and then paying again for the retry, plus whatever manual review catches the mistake before it reaches a user. Three failed calls at a fifth of the cost can easily add up to more than one successful call on a pricier model, and that’s before you count the engineering time spent debugging why the cheap model keeps failing.
Quality also varies by task type in ways a flat price comparison won’t show you. A model that’s excellent at summarization can be mediocre at structured data extraction or code generation. Benchmarks that rank models on a single aggregate score hide this. If your workload leans heavily on one specific capability, run your own small test set against a few candidate models before committing, rather than trusting a leaderboard built on generic tasks that may not resemble yours at all.
One more thing worth flagging directly: prices in this market move fast, sometimes monthly, sometimes with a scheduled increase announced weeks in advance. A model that’s the cheapest option this quarter might not hold that position by the time you’ve built your app around it. Whatever number you’re looking at right now, treat it as a starting point for evaluation, not a permanent fact, and check the provider’s own pricing page before finalizing a decision.
Multimodal Changes the Math Too
Everything above assumes plain text in and text out, which is still most of the market but not all of it. Once you add images, audio, or video to a request, the pricing model shifts and the cheapest text model on your shortlist might not even support the input type you need. Image tokens are typically calculated based on resolution and count as a chunk of tokens per image rather than a simple per character rate, so a single high resolution screenshot can eat more of your budget than several paragraphs of text. If your app needs to read receipts, screenshots, or scanned documents, compare providers specifically on their vision pricing rather than assuming their text rate tells you anything useful about that workload.
Audio transcription and generation follow a similar pattern, priced per minute rather than per token in most cases, and the gap between providers here is often wider than it is on text. A provider that’s dirt cheap for text generation might charge a premium for speech to text, or not offer it at all and force you to bolt on a separate vendor. If your product genuinely needs multimodal input, price the whole pipeline end to end before picking a primary provider, since splitting text and vision across two vendors adds latency and complexity that a single provider handling both might avoid.
Reading a Rate Card Without Getting Fooled
A few details buried in the fine print change the real cost more than the headline number does. Check whether the quoted price includes or excludes system prompt tokens, since some tools count your instructions against your budget and others don’t clearly disclose it until you’ve already run up a bill. Check whether there’s a minimum charge per request that makes very short calls disproportionately expensive, which matters if your app fires off a lot of small, quick queries rather than long conversations.
Rate limits matter just as much as price per token once you’re past the prototype stage. A provider can offer the lowest price on the market and still be useless for your app if their requests per minute cap forces you to queue traffic during peak hours. Check the published limits for your account tier, not just the model’s list price, before you commit engineering time to an integration you might have to rip out three months later because it can’t handle your actual traffic.
A Practical Way to Choose
Start by mapping your actual workload into rough difficulty tiers rather than picking a model first and figuring out the use case later. Simple, high volume tasks go to the cheapest model that reliably produces correct output in your own testing, not the cheapest model on the rate card. Complex, low volume tasks go to a stronger model where the per call cost barely matters because you’re not making millions of those calls.
Once you’ve got that split, estimate your monthly token volume honestly, including a buffer for retries and for the fact that real users write longer and messier prompts than your test cases did. Multiply that against the rates for your shortlisted models, factor in caching if your prompts have a stable, repeated portion, and you’ll have a realistic monthly number instead of a headline price that never reflects what you actually pay.
Frequently Asked Questions
Is the cheapest AI API always the best choice for a new project?
Not usually. It’s the right starting point for prototyping and for simple, high volume tasks, but production apps almost always end up mixing at least two tiers of model once real usage patterns show which requests are actually hard.
Do output tokens really cost that much more than input tokens?
Yes, and it’s not a pricing gimmick. Generating output requires a full forward pass per token, while input processing can be handled more efficiently in batches on the provider’s infrastructure. Expect output to run two to five times the input rate on most models.
Can I switch providers easily if prices change?
Technically yes, since most APIs follow a similar request and response structure, but prompt behavior differs between models even when the interface looks the same. Budget time to retest your prompts after a provider switch rather than assuming a drop in replacement will perform identically.
Should I self host an open model instead of paying per token?
Only if your volume is genuinely high, generally tens of millions of tokens a day or more. Below that threshold, the fixed cost of GPU infrastructure outweighs what you’d save compared to a pay as you go API, even a cheap one.
The lowest price per token will keep changing hands between providers every few months, and chasing that number alone is a losing game. Build your cost model around your actual task difficulty and volume, use caching and batching wherever your workload allows it, and pick the cheapest model that passes your own quality bar rather than the cheapest one on the leaderboard. That’s the version of “cheap” that actually holds up once real traffic hits your app.
