DeepSeek performance evidence hub, updated August 7, 2026. This page brings together Chat-Deep.ai’s original DeepSeek tests without turning different protocols into one score. Each entry states what was tested, when it was tested, what the result can support, and where to inspect the full method or data.
Use this hub to choose the right evidence. Availability probes answer a different question from long-context retrieval, API contract checks, citation accuracy, code generation, or consumer-chat file analysis. Results are dated observations, not promises about every account, provider, region, model version, or future release.
Choose the evidence you need
| Question | Original test | Surface | Test date or window |
|---|---|---|---|
| Was the service reachable and how did measured API latency vary? | Reliability program | API and public-route probes | Launched August 5, 2026; rolling |
| How accurately did Flash and Pro retrieve structured facts from long prompts? | 1M context benchmark | DeepSeek API | August 6-7, 2026 |
| Did a bounded integration suite and live smoke test satisfy the tested API contract? | API tests | Chat Completions API | July 28, 2026 |
| Did consumer DeepSeek Search citations resolve and support adjacent claims? | Citation audit | DeepSeek consumer web search | July and August 2026 |
| Did generated programs compile and pass a frozen fixture? | Coding benchmark | DeepSeek API | July 25-26, 2026 |
| How did the consumer chat handle synthetic PDFs and mixed files? | PDF and file benchmark | DeepSeek Chat web interface | July 24, 2026 |
How this hub labels evidence
- Original test: Chat-Deep.ai ran the described protocol and retained evidence.
- Primary result: the preregistered or frozen denominator, not a later diagnostic.
- Separate protocol: a result that must not be merged with another test into a new headline score.
- Rolling data: a current artifact that can change as new observations arrive.
- Limitation: a boundary on what the result can establish.
Reliability and API performance monitoring
The reliability program probes DeepSeek Flash and Pro separately every 15 minutes from six AWS network vantage points. It validates response markers, terminal events, token usage, finish reason, and time to first token. Public-app routes blocked by the probe environment are labeled monitor_blocked and excluded from success denominators; they are not counted as service failures.
Read the evidence: full reliability report and methodology; latest JSON summary; latest observations CSV; latest latency chart; and public code and data dictionary.
Limit: these are independent network observations, not a provider SLA, login test, browser-functionality guarantee, or proof of user experience in a particular country.
1M context retrieval benchmark
The frozen primary protocol ran 288 U.S.-vantage cases across 32K, 128K, 512K, and approximately 950K provider-counted prompts, using three retrieval task families, three target positions, two models, and repeated runs. It produced 152 strict exact matches out of 288 (52.7778%), 100% valid JSON and exact key sets, and 72.1014% field accuracy. Twenty pilot calls and 36 matched India-vantage latency calls have separate analysis roles and are not part of that primary accuracy denominator.
Read the evidence: full benchmark and methodology; 288-case primary CSV; canonical summary JSON; frozen GitHub release; and version DOI.
Limit: this is a structured synthetic retrieval benchmark on a dated API run. It is not a general reading-comprehension score, a provider comparison, or a claim that every prompt used exactly one million tokens.
API regression and live smoke tests
On July 28, 2026, the historical Node.js regression suite passed 29 tests with zero failures. A separate bounded live smoke test made two allowlisted requests with zero retries: GET /models and one non-thinking POST /chat/completions request to deepseek-v4-flash; both returned HTTP 200 and the completion returned the expected harmless marker.
Read the evidence: complete API testing guide and test boundaries and downloadable Node.js regression project.
Limit: the live run was a contract smoke test, not a latency, uptime, load, rate-limit, or response-quality benchmark. The later Responses API section is source-derived fixture guidance and does not claim that the July live run exercised /responses.
Consumer Search citation-accuracy audit
The July global protocol scored 61.3899, with 4 of 24 questions and 0 of 6 batches meeting its frozen gates. The separate August U.S.-and-India protocol produced a 58.5084 combined macro score with 4 of 24 questions meeting the inherited question gates; the India subset scored 42.1966 with 0 of 12 passing questions. These two dated protocols cover 48 questions but must not be merged into a new single score.
Read the evidence: full 48-question audit and methodology; July question-level CSV; July dataset JSON; country-extension CSV; and public repository.
Limit: the audit covers the dated English-language consumer web-search surface. It does not establish API, open-weight, third-party-host, other-account, other-language, or future behavior. A reachable citation is not automatically a supporting citation.
Coding benchmark across five languages
The frozen shortest-subarray benchmark made 10 sequential API calls with no retries: one generation for each Flash-or-Pro and Python, JavaScript, Java, Go, or C# cell. All 10 calls returned HTTP 200; seven sources passed strict extraction and safety checks, compiled, and passed all 14 deterministic cases. Pro passed 5 of 5 cells and Flash passed 2 of 5. One generation per cell on one fixture is not a general coding-model ranking.
Read the evidence: full coding benchmark, method, language matrix, token use, and limitations.
Limit: the stored fetch timer ended at response headers, so this benchmark does not publish a provider-latency ranking. Results apply only to the frozen task, fixture, toolchains, safety gate, and dated model responses.
PDF and mixed-file analysis benchmark
The July 24 consumer-chat benchmark used 10 controlled synthetic tasks and scored the primary Instant-mode product workflow at 89/100: 84/95 from nine submitted model responses plus 5/5 for the protected-file interface safeguard that blocked submission. Replacing the failed raster-chart Instant result with a later Vision diagnostic yields a post-hoc 98/100 sensitivity calculation, not a new primary score.
Read the evidence: full PDF benchmark, screenshots, scorecard, prompts, and mode limitations.
Limit: this is a web-interface product test, not the DeepSeek API file workflow. Expert mode did not expose file upload during the session, and Vision was used only for the documented raster-chart diagnostic.
How to use these results
- Match your decision to the tested surface before comparing numbers.
- Open the methodology and denominator before quoting a result.
- Use versioned or dated files for citation; use rolling files only for a clearly dated current snapshot.
- Do not combine protocols into a site-wide DeepSeek score.
- Rerun the relevant test when the model, API contract, consumer interface, provider, or scoring rule changes.
For broader context, visit the original DeepSeek research hub or return to our independent DeepSeek guide.