Which open-weight model is cheapest per token right now?

DeepSeek V4 Flash, at roughly $0.14 in and $0.28 out per million tokens. That does not make it cheapest per completed task — a model that needs two attempts at your work costs more than one that needs a single attempt at a higher rate.

How much does cached input actually save?

It depends entirely on prefix reuse. Kimi K3 prices cached input at $0.30 against $3.00 uncached. A single-shot request sees almost no benefit; a twenty-turn agent loop that resends the same system prompt and transcript sees most of its input billed at the cached rate.

Should I self-host to avoid per-token pricing?

Only at sustained high utilisation. A mixture-of-experts model needs all its parameters resident in memory regardless of how few activate per token, so the hardware floor is set by total size and the bill does not drop when traffic does.

Open Model Pricing Compared: What the Per-Token Rate Hides

Open-weight model pricing looks simple: an input rate and an output rate, per million tokens. Two numbers, easy to sort. The sort is almost always misleading, because neither number is what decides your monthly bill.

Here is the published field as of August 2026, per million tokens. DeepSeek V4 Flash at roughly $0.14 in and $0.28 out. DeepSeek V4 Pro at roughly $0.44 in and $0.87 out. Kimi K2.6 at roughly $0.95 in and $4.00 out. GLM-5.2 at roughly $1.40 in and $4.40 out. Kimi K3 at $3.00 in and $15.00 out, with cached input at $0.30. MiniMax M3 is quoted differently by different sources — around $0.30 and $1.20 in some listings, around $0.60 and $2.40 in others — so check the vendor page before you build a forecast on it.

That is a spread of more than twenty to one on input and more than fifty to one on output within a single generation. The spread is real. What it means for your spend is not obvious.

The output rate is the one that moves your bill

Look at the ratios rather than the absolutes. DeepSeek V4 Flash charges twice as much for output as input. GLM-5.2 charges roughly three times. Kimi K3 charges five times. Those multipliers matter because your workload has a fixed shape, and the shape decides which rate dominates.

Classification, extraction, routing and log triage are input-heavy: thousands of tokens in, tens out. For those the input rate is effectively the whole price and the output multiplier is noise.

Code generation inverts it. A refactor might take 4,000 tokens of context and emit 3,000 tokens of diff. Now the output rate carries most of the cost, and a model with a five-times multiplier is much more expensive than its input rate suggests. Input versus output token pricing works through the arithmetic properly.

Cached input changes the shape of an agent bill

Kimi K3 lists cached input at $0.30 against $3.00 uncached, a tenfold reduction. For a single-shot request that is a rounding error. For an agent it is the difference between viable and not.

An agent loop resends the same system prompt, the same tool schemas and a growing transcript on every turn. By turn twenty, most of the input tokens on each call are bytes the provider has already seen. Caching prices those at a tenth.

The consequence is that comparing headline input rates between a model with caching and one without tells you very little about agent cost. Model the actual prefix reuse of your loop instead. Prompt caching savings math shows how to do that without guessing.

Price per token is not price per task

The cheapest model per token is frequently not the cheapest per completed task, and this is the mistake that costs teams the most.

A model that fails and needs a retry has doubled its cost. A model that half-solves a problem and needs a human to finish has spent engineering time, which is the most expensive line in any of these comparisons. A model that loops for forty turns where a stronger one finishes in twelve can cost more despite a tenth of the per-token rate.

So the useful metric is dollars per merged change, or dollars per resolved ticket, measured on your own work. It is not hard to collect: log tokens and outcome per task for a fortnight, then divide. Cost per pull request covers the accounting.

Reasoning effort is a pricing dial

GLM-5.2 exposes two reasoning effort levels, high and xhigh. That is a spending control wearing the costume of a quality control, because reasoning tokens are billed as output.

Raising effort raises the number of tokens generated before the answer appears, and at roughly $4.40 per million output that accumulates fast across a busy day. The sensible default is the lower level, with the higher one reserved for tasks that demonstrably need it.

The lesson generalises beyond one model. Any knob that lengthens generation is a spending knob, so treat verbosity settings and chain-of-thought instructions as line items rather than free quality. Reducing token usage lists the levers worth pulling.

Where the spread actually bites

At small volume none of this matters. A solo developer sending a few million tokens a month pays single-digit dollars on the cheap tier and low double digits on the expensive one. Optimising that is not worth an afternoon of your time.

The spread bites at agent scale. An unattended agent working through a backlog can burn tens of millions of tokens a day, and there the twenty-to-one input spread separates a hobby from a budget line that finance will ask about.

It also bites when the workload is uniform. If every request has the same shape, pick the cheapest model that clears your bar and stay there. Mixed workloads are harder, which is why routing exists. Model routing and fallbacks covers sending cheap work to cheap models without hand-classifying every request.

Self-hosting moves the price, it does not remove it

Open weights invite the thought that you could avoid the per-token rate entirely. You can, and you replace it with a GPU bill that does not shrink when traffic does.

The economics turn on utilisation. Serving a large mixture-of-experts model means keeping every expert resident in memory even though only a fraction activates per token, so the hardware floor is set by total parameters rather than active ones. Kimi K3 ships around 1.6TB of weights, which is a different class of problem from a single-GPU dense model.

The crossover point is real but higher than most teams estimate, and it is a function of sustained load rather than peak. Self-hosting versus managed API cost and picking an open model to fit your GPU cover the two halves of that decision.

A decision rule

Start from workload shape, not from the price table. If your traffic is input-heavy and shallow, sort by input rate and take the cheapest model that passes your evaluation. If it is output-heavy, sort by output rate and expect the ordering to change.

If you run agents, weight cached input heavily and measure dollars per completed task rather than per token. If you are unsure, run the two candidates at either end of your shortlist across a hundred real requests and compare total spend alongside outcome.

Prices move, and they have moved repeatedly through 2026. Re-run the comparison quarterly rather than treating a spreadsheet from six months ago as current.