DeepSeek-V3.2 Token Counter
Estimated token count and cost for DeepSeek-V3.2, worked out in your browser.
The pricing shape here is unusual
$0.28 per million input, $0.42 per million output. That is a ratio of about 1.5 to 1, where nearly every other model on this site charges four to six times more for output than for input.
It matters more than the headline cheapness. On most models, generating a long answer is what your bill is made of, so the standard advice is to cap output length. Here, output costs barely more than input, so a verbose answer is not the expensive mistake it would be elsewhere. You can let the model write.
The count is an estimate
DeepSeek publishes no tokeniser that runs in a browser, so this uses o200k_base as a stand-in. Close on English prose, less reliable on code and on Chinese text, which is worth flagging given where this model's strengths and its user base lie.
If you are sizing Chinese input against the context limit, leave real headroom rather than trusting the figure.
More detail
128K is the constraint to design around
The context window is 128,000 tokens, an order of magnitude below the million-token models. For most conversational and coding work that is ample. For feeding entire documents or long transcripts, it is the thing that will stop you, and no amount of cheapness compensates for an input that does not fit.
Check the count against 128,000 before you build a pipeline that assumes more.
What this is genuinely good for
High-volume work where per-call cost dominates: bulk classification, extraction, summarisation, first-pass code review. At these rates you can run volumes that would be uncomfortable on a frontier model and still spend very little.
Questions
Why is output barely more expensive than input here?
That is how DeepSeek prices it: roughly 1.5 to 1, against the 4 to 6 to 1 typical elsewhere. The practical effect is that long answers are not the dominant cost, so the usual advice to cap output length matters much less.
How accurate is the count for Chinese text?
Less accurate than for English. The estimate uses o200k_base as a proxy and languages without spaces are where that proxy drifts most. Leave headroom when sizing against the context limit.
Is 128K enough?
For conversation and most coding work, comfortably. For whole documents, long transcripts or large codebases, it is the binding constraint, and a million-token model is the alternative regardless of price.
Does my text leave the browser to be counted?
No. The encoding runs locally with a bundled vocabulary and nothing is transmitted.