Request challenge
POST /create_pow_challenge
Target path identifies chat completion or file upload.
This Chrome capture exposes DeepSeek’s browser-facing protocol in unusually clean detail: prompts, search cards, streamed answer patches, proof-of-work, uploaded-file derivatives, polling, and telemetry. It does not expose the server-side retriever, ranking stack, prompt assembly, or token-level grounding path.
Loading…
Every claim is tagged by epistemic status. “Observed” is directly recoverable from the HAR; “inferred” follows from request ordering; “limit” marks the edge of the evidence.
The distinction matters. A request flag expresses capability; a SEARCH fragment in the SSE state is direct evidence that the backend actually ran search.
The surrounding bundle fetched and translated Baidu Cloud community articles surfaced by turn 2. Their precise metrics and confident internal diagrams are useful as examples of what DeepSeek retrieved, not as proof of how DeepSeek itself works.
Turn 2 turns retrieved third-party material into a mechanistic story about DeepSeek’s private infrastructure. The matrix below separates what the capture actually supports from what the answer merely asserts.
The capture begins mid-thread at parent message 6. Each visible user request and assistant stream after that point is reconstructed from the stateful SSE delta protocol. Fourteen of the sixteen turns have their text withheld here; their timing, frame counts, token usage, and search flags are intact.
The visible protocol is a sequence of anti-abuse setup, one completion request, and a long-lived SSE response carrying a compact patch language.
POST /create_pow_challenge
Target path identifies chat completion or file upload.
difficulty = 144000
SHA3 WebAssembly is requested nearby; its body is omitted from this HAR.
x-ds-pow-response
Prompt JSON plus PoW, HIF, client, locale, version, and settings fields.
APPEND · SET · BATCH
Ready → optional search → token deltas → finished → close.
presponse/fragments/-1/contentoAPPEND, SET, or BATCHvThis carry-forward design explains thousands of minimal {"v":" token"} frames.
These categories are easy to blur together. The capture contains all three.
Volcengine collection calls dominate the request count. Chat and settings carry most of the meaningful application state; static assets dominate declared bytes.
These labels are client-facing configurations rather than proof of underlying model weights. They are still stronger evidence about this session than names synthesized from search results.
| Endpoint | Requests | Bytes | Median | P95 |
|---|
Embedded response bodies are decoded exactly once, SHA-256 hashed, and stored by digest. Missing static bodies are recorded as missing—not silently treated as empty.
File modification times show a clear sequence: browser capture, follow-up source collection, translation, a reading interface, then Finder metadata. The raw HAR predates all of the explanatory material around it.
| Source | Role | Size | SHA-256 |
|---|
| Blob | Type | Size | References |
|---|
The full 194-item ledger lives in blob-manifest.json. Eighteen blobs carrying private session material are withheld from this build; their hashes and sizes remain in the ledger so the integrity chain stays auditable, but their bytes are not published.
No server-to-search-provider traffic, index calls, crawlers, or rerankers are visible at the browser boundary.
The result cards reaching the browser are observable; the exact material injected into the model context is not.
Citation order is evidence of presentation, not a trace of which source tokens causally shaped each generated token.
65 entries omit their bodies, including the versioned JavaScript and SHA3 WebAssembly required for a full client-code audit.