Can Kimi K3 and DeepSeek V4 Flash Really Use 1 Million Tokens? The 1M Context Reality

Verdict: Kimi and DeepSeek both document a 1,048,576-token context window, but this investigation has not yet shown that either hosted endpoint accepted—or reliably used—a prompt near that ceiling. The completed measurement is offline tokenization: across three rotated corpora, the largest corpus measured 966,205–966,287 Kimi tokens and 984,965–984,994 DeepSeek tokens. Official-API inference stopped before the first paid call because the available DeepSeek account had no usable balance and the Kimi runner had neither a funded account nor a usable API key. Retrieval accuracy, endpoint-accepted tokens, truncation, latency, caching and billed cost therefore remain unmeasured, not zero.

That distinction is the point of this test. Context accepted is a capacity result: the service receives a request of a verified size and returns a response without truncation. Context successfully used is a retrieval and reasoning result: the model finds the right evidence wherever it sits, connects distant facts, resolves superseded instructions, cites the supplied record and declines to invent an absent fact. A million-token label establishes neither result by itself.

This is deliberately not another broad model comparison. Kingy’s existing Kimi K3 versus DeepSeek V4 Flash comparison covers specifications, benchmark claims, pricing, licensing and positioning. The separate Kimi K3 Mac Studio investigation and DeepSeek V4 Flash local hardware guide cover deployment. Here, the only question is whether either official API can retrieve, combine and ground answers across a controlled enormous prompt.

Why advertised context is not usable context

A context window is a token budget shared by the input and generated output. Tokens are pieces of text, not words, and different tokenizers split the same bytes differently. “One million tokens” therefore does not mean one million words, and it does not mean the same document occupies the same fraction of each model’s window.

There are also three separate gates between a context claim and a useful answer:

1. Serialization: the corpus, system instruction, question and chat wrappers must fit after the provider’s tokenizer processes them.
2. Endpoint acceptance: the API must accept that exact request without silently dropping content. A local tokenizer count is a planning measurement, not proof of acceptance.
3. Evidence use: the model must recover and reconcile the information needed for the answer. This can fail even when the request fits.

The third gate is the hard one. Long-context research has repeatedly found that retrieval quality can depend on where information appears, with evidence in the middle sometimes used less reliably than evidence near the beginning or end. The original “Lost in the Middle” study documented that positional effect across long-context tasks. A modern million-token model may reduce it; the label alone cannot tell us whether it has. Kingy’s context-engineering guide explains why packing more material into a prompt is not a substitute for designing how evidence is selected and presented.

Exact versions, endpoints and documented limits

Research and corpus generation were completed on August 1, 2026. The API aliases and documentation below can change, so a later execution must record the model string returned by each response, the DeepSeek system_fingerprint where available and the retrieval date.

Primary sources support the capacity claims, not Kingy’s unfinished performance result. The Kimi K3 technical report and released Kimi K3 model card state a 1,048,576-token context. Kimi’s Chat Completions reference says input plus max_completion_tokens must remain within the model window and that an overflow returns invalid_request_error. The DeepSeek V4 Flash 0731 model card identifies the released checkpoint, while the current DeepSeek model table maps deepseek-v4-flash to DeepSeek-V4-Flash-0731 and lists a 1M context.

For repeatable offline counting, the package pins Kimi’s tokenizer repository to revision 9f62e4e9fffbd0a83ddd60e1c209d828994b3569 and DeepSeek’s to 7872f01b1d1fe23eabc4c98b48bffcef5a386062. Those pins make the local counts reproducible. They do not prove that a mutable hosted alias uses byte-identical tokenization on the test date, which is why provider-side counts remain mandatory.

The corpus and test method

The frozen package contains five nominal context tiers—32K, 128K, 256K, 512K and near 1M—with three independently generated trials at each tier. Every trial uses the same task grammar but rotates evidence positions and synthetic identifiers. There are 15 corpora in total.

Each corpus combines neutral filler records with facts that should be impossible to answer from training data. A trial includes:

• one unique fact near the beginning, one near the midpoint and one near the end;
• five additional needles distributed across the corpus;
• a three-hop chain whose final answer requires three distant records;
• an obsolete policy and a newer, higher-authority replacement;
• a four-file code dependency whose effective value emerges only after tracing imports and overrides;
• three independent constraints that must be cited in a grounded recommendation; and
• an absent identifier designed to catch unsupported invention.

Every evidence record has a unique ID. The answer format requires both the value and the IDs that support it. Exact values can show retrieval, while exact citations show whether the model grounded the answer in the supplied corpus instead of producing a plausible sentence.

The planned run uses streaming responses for client-measured time to first reasoning or content token and total latency. Each tier has a cold request and an identical-prefix cache probe. Provider usage objects, raw streamed events, HTTP status, retry history and wall-clock timestamps must be preserved. No server-side prefill field is assumed: if a provider does not expose prefill time, the result stays blank rather than being reverse-engineered from total latency.

Sampling cannot be made perfectly identical. The frozen Kimi request uses streaming, max_completion_tokens=3000, reasoning_effort=high, temperature=1.0, top_p=0.95, n=1 and zero presence/frequency penalties; Kimi documents those sampling values as fixed and exposes no seed. The DeepSeek request uses streaming, max_tokens=3000, thinking enabled and reasoning_effort=high. It requests one completion and omits temperature, top-p and penalties because DeepSeek documents them as ineffective in thinking mode; no seed is documented. The config and every raw-results row record those controls and restrictions instead of pretending that matching JSON fields create matching inference conditions.

Scoring before seeing the outputs

The rubric was frozen with the corpus. Retrieval accuracy is the proportion of eight requested single facts returned with their exact evidence IDs. Multi-hop, contradiction, code-dependency and synthesis tasks are scored separately and require all necessary citations. The absent-fact control counts as a hallucination if the response supplies either a value or invented supporting evidence. API rejection is an acceptance failure, not a model-accuracy score.

Download the complete experiment package (ZIP, SHA-256 47978044b4f09988f3d3780d377ef2939be2859e87781305056de4a7c039f31a). It includes the generator, pinned configuration, all 15 corpora, expected answers, per-file hashes, scoring rubric, verification script and raw-results CSV schema.

What was actually measured

The corpus generator and tokenizers ran successfully. The 32K corpus was regenerated independently and matched the recorded hashes. The table below is therefore a reproducible offline tokenization result. It is not an API benchmark.

The “serialized request” column adds the transparent system instruction, task prompt and message framing used by the local tokenizer. The hosted service may add different private framing. A successful provider response is still needed to establish the accepted count.

Context accepted versus successfully used

“Not run” is not a euphemism for failure. On August 1, the authenticated DeepSeek balance check returned no available balance. The Kimi console showed zero balance, and the runner did not have a usable MOONSHOT_API_KEY. Kimi’s official recharge and rate-limit table requires at least a $1 recharge to start API use and lists a 500,000-token-per-minute Tier 0 limit. The 512K trials sit only narrowly below it by local count: 495,584–495,897 serialized input tokens plus a 3,000-token output reservation equals 498,584–498,897. They need Kimi’s provider estimator to confirm that hosted framing does not cross the limit. The near-1M tier clearly requires at least the 2,000,000-TPM tier documented after $10 cumulative recharge. Sending a few smaller calls would not answer the requested five-tier comparison and could tempt readers to mistake a partial run for a completed one.

Results by context tier

There are no official-API outputs to score at any tier. Accordingly:

• 32K: corpus generation and offline counts complete; endpoint acceptance, retrieval, latency and cost not measured.
• 128K: corpus generation and offline counts complete; endpoint acceptance, retrieval, latency and cost not measured.
• 256K: corpus generation and offline counts complete; endpoint acceptance, retrieval, latency and cost not measured.
• 512K: corpus generation and offline counts complete. The planned Kimi total is 498,584–498,897 tokens by local serialization plus reserved output—below Tier 0 by only 1,103–1,416 tokens—so provider-estimator confirmation is required. All inference measurements remain unmeasured.
• Near 1M: the largest local serialized requests remain below the released 1,048,576-token configurations with a 3,000-token output reservation, but neither request was submitted. Calling this a successful million-token test would be false.

This fail-closed presentation matters. A blank cell preserves uncertainty. Filling it with a provider benchmark, a local configuration value or a projected latency would collapse three different kinds of evidence into one misleading “result.”

Lost-in-the-middle behavior

The test is positioned to detect a middle penalty, but no model output exists yet. Each trial moves the early, middle and late facts while preserving comparable record structure. After execution, the analysis should report each position separately at every tier, followed by the three-trial mean. An overall retrieval score could hide a model that recovers edge evidence while missing the midpoint.

The relevant result will not be “the model found a needle.” It will be whether exact-value-plus-citation accuracy remains stable as both context size and position change. Until those runs exist, the only responsible conclusion is that lost-in-the-middle behavior is untested here.

Multi-hop and contradiction performance

Single-needle retrieval is necessary but weak. Real investigations often require joining an identifier in one document to a location in a second and a final code in a third. The package’s three-hop task places those records far apart. The answer receives credit only if the final value and all three evidence IDs are correct.

The contradiction case tests something different: authority and recency. One passage contains an obsolete policy; another explicitly supersedes it. A model that quotes the first matching number fails even if that number appears verbatim in the corpus. The frozen scorer requires the current value, the winning evidence ID and recognition that the older record was superseded.

Neither model has a score on these tasks yet. Provider claims and unrelated benchmark tables cannot substitute for this corpus-specific measurement.

Codebase-scale dependency tracing

The code task is a compact proxy for repository work. Four pseudo-files define, import, override and consume a time-to-live value. The effective value cannot be read from a single snippet. The model must follow the active dependency path and cite every file that determines the result.

This is narrower than claiming either model can understand an entire production codebase. It tests one traceable dependency chain embedded in increasingly large context. No output was generated, so code-dependency accuracy remains unmeasured. Readers interested in deployment constraints should use Kingy’s separate hardware guides; repeating those details here would not answer the retrieval question.

Latency and time-to-first-token reality

Long prompts impose an input-processing, or prefill, stage before useful output arrives. Client-measured time to first token includes network and queueing as well as provider computation. Total latency adds the full generation. Those values should be reported separately, with medians and individual trials, because one congested request can distort a tiny sample.

Neither provider exposes a server-side prefill duration in the planned Chat Completions response. The experiment therefore records it as unavailable unless the API later adds a documented field. It will not estimate prefill by subtracting an assumed generation speed.

Cost and caching

Cost is also unmeasured. The frozen schema calculates it from provider-reported prompt, cached-input, uncached-input and completion tokens using the price in force at execution time. Kingy’s token-budgeting guide explains why the window ceiling and the economic working set are different questions.

The currently documented list prices are sharply different, but quoting them is not the same as observing a bill. Kimi’s current K3 pricing page lists per-million-token rates of $0.30 for cached input, $3.00 for uncached input and $15.00 for output. DeepSeek’s current model table lists $0.0028, $0.14 and $0.28 respectively. Both pages warn, directly or by their changeable nature, that current pricing governs. Any future results update must store the retrieved pricing snapshot and calculate each row from actual usage.

Caching needs its own measurement. Kimi documents automatic context caching and returns cached_tokens. DeepSeek says context caching is enabled by default, reports prompt_cache_hit_tokens and prompt_cache_miss_tokens, and describes cache hits as best effort rather than guaranteed. For that reason, cold and repeated-prefix requests cannot be mixed into one latency or cost average. A cheap warm run does not describe first-pass research over a new corpus.

Which workloads could benefit—if the evidence holds

A large, usable context window could help when the evidence set is known but too interdependent for aggressive chunking: a regulatory record with amendments, a litigation bundle, a repository-wide dependency trace, a long incident timeline or a research archive whose claims must be reconciled across sources.

It is less compelling when retrieval can confidently narrow the working set, when most documents are irrelevant, when low latency matters, or when the answer depends on a few passages that can be supplied directly. Even a model that performs well here would not make search, ranking, access controls or source hygiene optional.

The frozen workload is designed to reveal whether these models can use distant evidence, not whether every application should send a million tokens. A positive result would establish capability on this test. It would not establish that maximum-context prompting is the best architecture or the best use of budget.

Limitations

• The main limitation is decisive: zero inference calls were completed. There are no model outputs, accepted provider counts or observed performance metrics.
• The synthetic facts prevent training-data leakage, but they cannot represent every property of messy real archives.
• Three trials per tier can reveal obvious instability, not provide a tight confidence interval for all long-context behavior.
• Offline tokenizer revisions are pinned, but hosted aliases can move and may serialize messages differently.
• Provider caching, queueing and service load can change between requests. Cold and warm results must remain separate.
• Kimi and DeepSeek expose different reasoning and sampling controls. The protocol controls what it can and documents what it cannot.
• A successful near-1M request would test approximately one million tokens, not prove acceptance of exactly 1,000,000 or 1,048,576 submitted tokens. Only provider usage can establish the exact accepted count.

The narrow 1M-context verdict

Documented capacity: yes. Kimi’s paper, model card and API reference support a 1,048,576-token total window. DeepSeek’s released model and API table support a 1M window for DeepSeek V4 Flash 0731.

Locally prepared near-1M corpus: yes. The largest byte-identical trials count just under the released limits under both pinned tokenizers.

Official endpoint acceptance: unknown. Neither largest request—or any smaller tier—was submitted successfully in this investigation.

Reliable retrieval, multi-hop reasoning, contradiction handling, code tracing and grounded citation across the window: unknown. There is no basis for naming a long-context winner.

The eventual test can produce a verdict only after both APIs run the same 15 frozen corpora and the returned counts and outputs survive review. Until then, “supports one million tokens” remains a documented capacity claim, not a Kingy-verified statement about one million tokens successfully used.

FAQ

Did Kingy test exactly one million tokens on Kimi K3 and DeepSeek V4 Flash?

No. Kingy generated and locally tokenized a near-1M tier, but no request was submitted to either official API. The largest serialized local counts were 966,472–966,556 Kimi tokens and 985,256–985,285 DeepSeek tokens. They are not accepted-token counts.

Do Kimi K3 and DeepSeek V4 Flash support a 1M context window?

The providers document that capacity. Kimi’s released configuration specifies 1,048,576 tokens, and DeepSeek documents a 1M context for deepseek-v4-flash, mapped to DeepSeek V4 Flash 0731 on the research date. Capacity does not establish retrieval quality.

What is the difference between context accepted and context successfully used?

Accepted means the endpoint processed a verified-size request without rejection or truncation. Successfully used means the model retrieved and combined the required evidence, cited it correctly and avoided unsupported claims. The second standard is much stronger.

Why not publish provider long-context benchmarks instead?

They use different data, prompts, harnesses and scoring. They are relevant provider evidence but cannot be presented as results from Kingy’s fixed corpus. This investigation needs its own usage records and raw outputs.

Why are the accuracy and latency charts blank?

Because no official-API inference call completed. Plotting zero would imply measured failure; drawing an estimate would imply evidence that does not exist. The blank chart records the current state accurately.

What remains before Kingy can report completed hands-on results?

Both official API accounts must be funded and authorized; Kingy must then confirm a Kimi tier capable of the upper requests, run all 15 frozen cases plus cache probes, preserve raw events and usage, score the outputs, calculate observed cost, update the charts and tables, and complete another factual and rendered-preview review.