The Cheapest Frontier Models, Priced Honestly

The open-weight field in 2026 spans a price range that would be absurd in any other component of your stack. The cheapest listed model costs about $0.14 per million input tokens; the most expensive costs $3. On output the spread is wider still, from $0.28 to $15.

That is more than twenty to one on input and over fifty to one on output, for models that all answer the same API shape. The interesting question is not which is cheapest — it is where the extra money buys something you can measure.

The list prices, in order

DeepSeek V4 Flash lists around $0.14 per million input tokens and $0.28 output. It activates about 13B parameters per token, ships a 1M-token context window, and is MIT-licensed. It came from the 23 April 2026 V4 release with a 0731 refresh on 30 July.

DeepSeek V4 Pro, from the same release, lists around $0.44 and $0.87. It is 1.6T total with about 49B active, also 1M context and MIT, and reports 80.6 percent on SWE-bench Verified with an Artificial Analysis index score near 44.

Kimi K2.6 lists around $0.95 and $4.00. It is 1T total with about 32B active, a 256K context window, and it is vision-language. GLM-5.2 lists around $1.40 and $4.40, with roughly 744B total and 40B active, 1M context, 128K maximum output, MIT licensing and an index score near 51.

Kimi K3 sits at the top at $3 input and $15 output, with cached input at $0.30. It is 2.8T total with about 104B active, an index score near 57, first place on Arena Frontend Code at 1,679, and 88.3 on Terminal-Bench 2.1.

MiniMax M3 is the exception you cannot slot into the list. Published rates differ between sources by roughly a factor of two on both input and output, so get a quote from the endpoint you would actually use rather than trusting an aggregator.

Read the input-to-output ratio, not just the level

Price level tells you how expensive a model is. The ratio between input and output pricing tells you which workloads it suits, and it varies enormously across this list.

DeepSeek V4 Flash charges twice as much for output as input. Kimi K2.6 charges roughly four times. Kimi K3 charges five times, and at an absolute level where the multiplier really bites.

So a workload that reads a great deal and writes very little — classification, review, extraction, retrieval over long documents — is cheaper on a model with a flat ratio, and the absolute output price barely matters. A workload that generates long code files inverts that completely. Input versus output token pricing covers how to model your own mix.

Caching moves the input side again. K3's $0.30 cached input rate is a tenth of its standard input price, which matters enormously for agent loops that resend a large stable system prompt on every turn. Prompt caching savings math works through when that changes the ranking.

Cost per completed task is the only ranking that counts

Per-token price is an input to your bill, not your bill. The figure that decides anything is cost per completed task, and it folds in three things the price list does not show.

First, verbosity. Models differ substantially in how many output tokens they spend reaching the same answer. A model at twice the price that answers in half the tokens is the same cost, and there is no way to know which way it falls without measuring your own tasks.

Second, retries. A cheaper model that fails and needs a second attempt has cost you two calls plus the latency, and if a human had to notice the failure it has cost you far more than that. The hidden cost of retries covers how badly this distorts naive comparisons.

Third, turns. In an agent loop, a model that takes forty tool calls where another takes twenty-five has consumed more than the extra fifteen calls, because every turn carries the accumulated context of all previous turns. Token consumption in a loop grows faster than turn count. Why agent costs are unpredictable explains the compounding.

Where the cheap models are genuinely enough

A large fraction of production LLM traffic is bounded work with short answers: routing a request, classifying a ticket, extracting fields from a document, writing a commit message, generating a docstring, summarising one page.

These saturate. Once two models are both correct 99 percent of the time, the more expensive one cannot improve the outcome — it can only improve the bill. Paying fifty times more for output on a task where both models agree is a pure transfer with nothing coming back. When a cheap model is enough covers how to identify these tasks in your own traffic.

Cheap models also unlock strategies that are unaffordable higher up the list. At $0.14 per million input tokens, you can run the model twice and compare, or feed it far more context than you strictly need rather than building a retrieval layer to trim the prompt. Redundancy is a legitimate quality strategy when tokens are nearly free.

The counterexample is anything unattended and long-running, where per-step reliability compounds. That is where the cheap tier stops being a bargain.

Where the expensive models earn the gap

Three workloads, consistently.

Long unattended agent runs, where a few percent of per-step reliability turns into a large difference in completed runs. K3's 88.3 and GLM-5.2's 81.0 on Terminal-Bench 2.1 are measuring exactly this, and it is the capability least visible in a casual side-by-side test.

Work a human will judge on sight. K3's first place on Arena Frontend Code at 1,679 comes from blind developer voting rather than an automated harness, which makes it unusually relevant when the output is code someone reads and reacts to.

And tasks where a wrong answer is expensive — a schema migration, a security-sensitive change, anything that reaches customers without review. The model price is trivial next to the cost of the failure, and optimising it is a category error.

The configuration that actually saves money

Not choosing the cheapest model. Routing between tiers, with an explicit rule.

Default everything to the cheap tier. Escalate on three triggers: a validation check you can compute cheaply has failed, the task is a multi-step agent run rather than a single completion, or the output goes somewhere unreviewed and high-stakes.

Then track the escalation rate as a first-class metric. Under ten percent and you are capturing nearly all the available saving. Over a third and either the triage rule is wrong or the work is genuinely hard, in which case simplify to the stronger model and stop paying the complexity tax. Model routing and fallbacks covers the implementation.

One caution on all of the above: these are list prices from a field that reprices frequently, and third-party providers frequently list below official rates. Re-check them before any decision that matters, and treat every figure here as dated August 2026.