The Cached-Input Column Spans Wider Than the Price Column: Reading the DeepSeek Catalogue

On OrcaRouter the Deepseek API page lists nine models, and the two price columns near the top of its table do not span the same distance. The spread between the cheapest and the dearest input rate is four point four times. The spread between the cheapest and the dearest cached-input rate is seven point three times [VENDOR, read 2026-10-14]. Eight of the nine rows carry both numbers, and the column that ranges wider is the one most readers skip, because the discount it describes feels like a rounding detail next to the headline price.

It is not a rounding detail when the discount is this steep. The cheapest cached rate on the page is two per cent of its own row’s input rate, which means that for one row on this catalogue, input the provider has already seen costs a fiftieth of input it has not. Whether that matters to a given workload depends entirely on a number the page does not ask you for, and the rest of this piece is about supplying it yourself.

Two spreads, side by side

Take the eight priced rows and read the first two columns as ranges rather than as a list. Input runs from $0.150 to $0.660 per million tokens. The cached rate runs from $0.0030 to $0.022 over the same eight rows. Both are monotone — no row is an exception in either direction — but the second range is the wider one, and that is the first thing worth noticing about this catalogue.

The reason is that the cached rate is not a flat fee. It is a fraction of each row’s own input rate, and that fraction is not identical from row to row. The cheapest row caches at two per cent of its input rate; the dearest caches at three and a third per cent. So the row that is already the cheapest to call is also the row that is cheapest to repeat, and the gap between the top and the bottom of the catalogue widens rather than narrows once repeated input is priced in.

What the column actually bills

The cached rate is the price of the part of a request that the provider recognises as a repeat of something it has already processed — a system prompt, a document, a long instruction block that does not change between calls. A workload with no repeated prefix pays the full input rate on every token and never touches this column at all. A workload whose request is mostly a long frozen prefix pays the cached rate on most of its tokens.

The table above lists the eight rows with both rates side by side, together with the fraction each cached rate represents of its own row:

All rates are vendor-published and read 2026-10-14 [VENDOR]; the right-hand column is arithmetic performed on the other two, not a figure the page prints.

Why a wider range still changes no ordering

Here is the practical consequence, and it is smaller than the seven-fold spread suggests. Price the same ten million input tokens on each row at a ninety per cent cached share — one tenth of the volume at the full input rate, nine tenths at the cached rate.

Every row lands between eleven and thirteen per cent of its own uncached input cost. The spread in the discount column did not translate into a spread in outcomes, because both the input rate and the cached rate move together across the catalogue: the cached column is monotone in the price column, so it rescales every bill by roughly the same factor and leaves the ranking exactly where it was.

That is a useful thing to know in both directions. It means caching is not a way to make an expensive row cheap — it is a multiplier, and a multiplier cannot reorder a list. It also means you can skip the column when the only question is which row is cheaper, and read it only when the question is what the month will cost.

Where the column stops helping

Two limits are worth stating, because both are easy to misread off a table this shape.

The first is that only input is cached. The output rate is billed in full on every token the model writes, and the output spread on this catalogue is three point three times — narrower than the input spread, but it multiplies the whole generation side of the bill with no discount available at all. A workload that reads a long frozen document and writes a long answer splits its cost between a column that can shrink and a column that cannot. Reason about the two separately, because averaging them hides the one that is fixed.

The second is that the discount arrives in proportion to a share you have to measure. At a ninety per cent cached share the blended rate is an eighth of the headline; at twenty per cent it is about four fifths, and the seven-fold spread in the discount column is worth almost nothing. The page cannot tell you your share, and this page in particular does not try to: among the seven provider pages on the site, this is the one with no cheapest-input statistic in its header, no cost question in its FAQ, and no cost calculator below the table [VENDOR, read 2026-10-14]. The header carries a model count, a median latency and a maximum context, and nothing about price.

One row that is not billed per token at all

The ninth row is priced per request rather than per token, and it sits in the same table as the eight per-million rows [VENDOR, read 2026-10-14]. It has no input rate, no output rate and no cached rate, because none of those quantities apply to it: a model billed by the call costs what it costs regardless of how long the prompt was, which means it benefits from nothing in this article and is unaffected by your cache share in either direction.

Reading that cell as zero is the mistake to avoid, and reading it as free tokens is the larger one. A per-request row is the right answer for a workload whose calls are short and whose volume is predictable, and the wrong answer for a workload whose whole design is a long frozen prefix — a per-token row with a ninety per cent cached share can beat a per-request row on the same job, and only arithmetic on your own volume settles which.

The takeaway

The cached-input column on this catalogue spans seven point three times while the input column spans four point four, and that is the more interesting number only because it is the more misleading one. At a ninety per cent cached share every row lands at eleven to thirteen per cent of its own uncached input cost, the ranking does not move, and the wider spread turns out to be a rescaling rather than a rearrangement. Read the column for what it does — multiply your input bill by a factor you can compute from two published rates — and read the output column as the part of the bill that no prefix and no cache share can touch. Then measure your own cached share, because it is the only input in that arithmetic the page cannot supply.

Sourcing note: every per-million-token rate, cached-input rate, context window, maximum output and quality score cited is vendor-published and read 2026-10-14 [VENDOR]; all blended rates, cached shares, spread ratios and the ninety per cent scenario are arithmetic performed on those published rates, not separate measurements. Quality scores are OrcaRouter’s own composite, assembled from production traffic and published sources, not a third-party benchmark. The absence of a cheapest-input statistic, a cost FAQ and a cost calculator on this page is read from the page itself [VENDOR]. The per-request row’s billing basis is the vendor’s own published description.