DeepSeek Turns the App into APIs and Open-Sources the Frontend Along the Way

On November 13, 2026, DeepSeek announced that it was opening up the capabilities behind the DeepSeek App via API. The scope includes web search, file input, URL reading, model content safety, voice input, and text-to-speech. For developers, the change is not that the model has gained another parameter, but that the search, parsing, and voice pipelines they previously had to stitch together themselves can now go through the same service.

The official documentation gives two ways to use this. The first is to enable built-in tools in the request: deepseek_web_search handles search, deepseek_read_url handles reading links; safety_check enables content safety; title automatically generates a conversation title. The second is to call OCR, ASR, and TTS separately. Chat capabilities work across all three protocols—Messages, Responses, and Chat Completions—and the model is specified as deepseek-flash.

Search and link reading are executed on the server side. The client only needs to display the returned blocks and send them back as-is in the next turn. The response includes thinking, search steps, webpage reads, and text with citations. The official documentation provides a diagram showing the rendering positions.

The open-source demo is one of the more practical parts of this release. It is a static frontend with no application backend; the browser connects directly to the API. The API key and settings are stored in localStorage, and conversations and raw attachments are stored in IndexedDB. It supports importing history exported from DeepSeek Chat; importing will replace existing local conversations and attachments. The demo URL, source code, and documentation are below:

• Live demo
• Source code
• Build documentation

Pricing needs to be viewed separately. The official reply made it clear that extended capabilities will incur tool usage fees in addition to standard token costs. The pricing chart is as follows:

Some online users have summarized that search costs $0.75 per 1,000 calls, and speech-to-text is cheaper and currently 50% off for a limited time. This claim comes from a user summary; official billing is subject to the official pricing page. Some people in the comments also asked whether search and voice are billed in the same call or separately, and whether TTS pricing is on the expensive side. This time, the official account did not explain each item in the tweet.

One easily overlooked detail: once a request declares deepseek_web_search, deepseek_read_url, or sets safety_check to high and enables title, the service will take over some parameters, and temperature, top_p, etc. in the request will be ignored. max_tokens still takes effect, but it limits the output of each reasoning step, not the total output for the entire turn. Before integrating, it is best to write these behaviors into product expectations.

Some users' judgment is that turning application-layer capabilities directly into APIs saves setup time; compute is not the main point. The competitive focus will shift from model scores to who can ship a usable product faster. This judgment makes sense, but the bill will become more complicated: token fees, search tool fees, and voice fees are calculated separately, and actual cost depends on usage structure. For teams that want to quickly build chat products, this lowers the barrier to entry; for teams that have already built their own search and voice pipelines, whether it is worth switching depends on whether the tool fees or the maintenance time saved is the better deal.