DeepSeek open-sources the plumbing between your API and its models

What it does

It converts requests in Messages, Chat Completions, and Responses formats into a unified Conversation format, renders that into DeepSeek V4/V4.1 prompts, encodes it into token IDs with a bundled tokenizer, and parses model output back into the format the caller asked for. Crucially, it does none of the actual work: model inference, tool execution, and HTTP transport are all the caller’s job. It’s the translation layer, not the engine.

The interesting bit

The boring parts are where the value hides — it handles the fiddly semantics people usually get wrong: default max_tokens resolution against context limits (8192 normally, 65536 in thinking mode, 131072 at max effort), reasoning-token counting via tokenizer re-encoding, and structured output where JSON Schemas are validated and written into the prompt while regexes pass through for the backend to enforce via constrained decoding.

Key highlights

• Rust core with Python bindings (deepseek_recipe on PyPI), plus an Axum and a FastAPI example server with mock inference.
• Streaming support, thinking mode, tool calls, logprobs plumbing, and image preprocessing for V4.1 (V4 requests get images replaced with [Unsupported Image]).
• Deferred tool loading and client-executed tool search for V4.1.
• A web demo that renders prompts, highlights special tokens, and parses output into any of the three response formats.
• MIT-licensed, split into focused crates (-core, -encoding, -image, -macros).

Caveats

• RequestImageFetcher fetches any URL by default — the README explicitly warns services handling untrusted input to install a DestinationFilter.
• It doesn’t compute logprobs or enforce output constraints; it just converts and passes the buck to your backend.

Verdict

If you’re building an inference backend or API gateway for DeepSeek V4/V4.1 models, this saves you weeks of protocol archaeology. If you just want to call an API, you already have that and don’t need this.