DeepSeek Packs Search, Files, and Safety Into deepseek-flash at 88% Below GPT-4o

DeepSeek has added the capabilities behind its consumer chatbot to the API guide for deepseek-flash. Developers can now invoke web search, multi-step search, file parsing, URL reading, and safety checks through the model API.

Applications can delegate tool execution and context assembly to DeepSeek instead of maintaining those workflows locally. Related capabilities are also available through standalone Search, Fetch, optical character recognition (OCR), speech-to-text (ASR), and text-to-speech (TTS) endpoints for custom pipelines.

One model, three API shapes

DeepSeek exposes the chat features through the Messages API, Responses API, and Chat Completions API. Each protocol uses the deepseek-flash model identifier, allowing teams to keep a compatible SDK and request format.

Teams that need direct control over retrieval or media processing can call the standalone endpoints independently:

• Search returns search results for application-managed retrieval and ranking.
• Fetch retrieves and parses content from a specified URL.
• OCR extracts text from images and document pages.
• ASR converts recorded speech into text.
• TTS generates spoken audio from text.

The server owns the tool loop

DeepSeek’s server executes searches and page fetches, then returns typed content blocks describing each step. A client renders those blocks and includes them unchanged in the next request when the conversation continues. Preserving their order and contents keeps tool results, citations, and conversation state intact.

A Messages API request with search, URL reading, safety screening, title generation, and streaming enabled looks like this:

curl https://api.deepseek.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-flash",
    "thinking": {"type": "enabled"},
    "tools": [
      {"type": "deepseek_web_search", "name": "deepseek_web_search"},
      {"type": "deepseek_read_url", "name": "deepseek_read_url"}
    ],
    "safety_check": {"level": "high"},
    "title": {"enabled": true},
    "messages": [{
      "role": "user",
      "content": "Read https://api-docs.deepseek.com/ and summarize the latest DeepSeek V4.1 changes using current web sources."
    }],
    "stream": true
  }'

Streaming responses contain blocks such as thinking, server_tool_use, web_search_tool_result, and final text output. Inline citations_delta events connect claims in the answer to retrieved sources, giving clients enough structure to render source links and tool activity.

Any request that declares deepseek_web_search or deepseek_read_url, sets safety_check to high, or enables title generation gives the service control over sampling. DeepSeek ignores client-supplied values for settings such as temperature, top_p, and stop sequences in those cases.

Tokens stay cheap; tools meter separately

Base token prices for V4.1 Flash remain unchanged. Input prices below apply to cache misses, while Search and Fetch calls are billed in addition to model tokens.

Pricing for OCR, ASR, and TTS needs to be included separately when estimating a pipeline that uses those endpoints. Retries and repeated searches also count as additional tool calls.

A peak-rate workload using one million input tokens, one million output tokens, 1,000 Search calls, and 1,000 Fetch calls would cost $3.00: $0.30 for input, $1.20 for output, and $1.50 for the two tool allocations. That estimate excludes other endpoint charges.

At these reference rates, deepseek-flash peak input and output prices are about 88% lower than GPT-4o’s. Retrieval-heavy applications need to add per-call Search and Fetch charges before comparing total costs.

One contract replaces several integrations

Retrieval-augmented chat applications commonly combine a language model, search provider, document parser, moderation service, and voice layer. DeepSeek now supplies those functions under one account, with server-side orchestration for the model’s built-in tools. The approach resembles OpenAI’s Responses API and Anthropic’s server tool use, with DeepSeek competing on token prices and access to adjacent document and voice services.

Standalone endpoints preserve flexibility for teams that want custom ranking, application-managed tool selection, or separate model calls. They also allow Search, Fetch, OCR, ASR, and TTS to be inserted into existing workflows without adopting the complete chat runtime.

DeepSeek’s open-source reference frontend mirrors the main DeepSeek Chat interface and demonstrates:

• Web search, multi-step search, and URL reading
• Image and document uploads
• Text and image safety review
• Conversation title generation
• Message editing and answer regeneration
• Voice input and spoken answers
• Chat-history import and export

Production deployments still need application-specific authentication, authorization, persistence, abuse controls, observability, and compliance workflows. The reference project supplies interface and integration scaffolding rather than a complete production architecture.

Migration comes with tradeoffs

Migration planning needs to cover compliance, model controls, variable tool costs, infrastructure routing, and retrieval security:

• Safety obligations remain with the developer. Public-facing applications must enable DeepSeek’s checks, while operators retain responsibility for content review, model registration, and AI-labeling requirements in relevant jurisdictions.
• Built-in tools reduce sampling control. Applications that depend on exact temperature, top_p, or stop-sequence behavior need to test how server-selected values affect output consistency.
• Agent loops can multiply tool charges. A single user turn may trigger several searches and page fetches, so cost models should use observed calls per turn instead of assuming one call per request.
• Search and fetching run through DeepSeek. Teams with data-residency, network-latency, or provider-governance requirements need to assess the service’s infrastructure against their policies.
• Retrieved content remains untrusted input. Applications should defend against prompt injection in fetched pages, validate outbound links, and avoid granting retrieved instructions access to sensitive tools or data.
• Tool failures need explicit handling. Clients should account for empty results, blocked pages, timeouts, missing citations, and safety refusals in both the interface and application logic.

Teams evaluating the release can benchmark it with representative production traces, measuring searches per turn, end-to-end latency, refusal rates, citation quality, and total cost. Those results will show whether DeepSeek’s server-side orchestration fits the application’s control, compliance, and reliability requirements.