AI
DeepSeek documents a 600-image vision model
DeepSeek’s V4 Flash Vision Exp model accepts images through OpenAI-, Anthropic-, and Responses-compatible APIs, with a 600-image request limit.
DeepSeek’s deepseek-v4-flash-vision-exp model can process images alongside text, and its API documentation lays out three upload methods, token handling, compatibility layers, and strict size limits. DeepSeek’s API documentation describes the model and its image-input implementation, but does not state a public launch date or pricing for the vision model.
The model is designed for tasks such as describing photographs, reading text from screenshots, and analyzing charts. It accepts JPEG, PNG, GIF, and WebP files. DeepSeek says it detects the format from the file’s actual contents rather than relying on the filename or declared MIME type.
Three ways to send images
The standard OpenAI-compatible Chat Completions API carries images in a content array containing separate text and image blocks. Developers can provide an image in any of three ways:
- Base64 data URL: Encode a local image and include it directly in the request. The encoded data counts toward the 48 MiB request-body limit.
- External URL: Supply a publicly accessible http or https link for DeepSeek to download. The URL can be up to 8,192 characters, the image can be up to 32 MiB, and the download must finish within 60 seconds.
- Files API reference: Upload the image once and pass its file_id in subsequent requests. This is intended for larger files or workflows that reuse the same image across multiple calls.
The Files API route changes the size limits. An image referenced through a file_id can be up to 64 MiB and is not subject to the standard 32 MiB per-image check. DeepSeek also supports an inline file_data block containing a base64 data URL, but file_data and file_id are mutually exclusive.
A typical Chat Completions request combines a question with an image_url block. The same model can also be called through DeepSeek’s Responses API, where the equivalent content types are input_text and input_image.
Image detail controls processing cost
For image_url inputs, developers can set a detail value that controls how the image is processed. The available values are:
- low: Downscales the image to 512×512 before inference, which DeepSeek describes as faster and cheaper when fine visual detail is unnecessary.
- high: Keeps the original image and is currently equivalent to original.
- original: Keeps the original image.
- auto: Automatically selects a mode, although DeepSeek says it is currently equivalent to original.
The Responses API exposes the same low, high, original, and auto options. When an image is supplied with a Files API file_id, the detail setting is ignored.
DeepSeek bills image tokens together with text tokens. Before inference, the service resizes images while preserving their aspect ratio. Images with fewer than roughly 384×384 total pixels are scaled up, while larger images are scaled down to a total pixel count roughly equivalent to an 800×800 image.
That resizing creates an upper bound of 384 tokens per image, according to the documentation. A 2,000×2,000 image and a 5,000×5,000 image therefore consume the same number of image tokens after resizing. In a multi-image request, each image is counted independently under the same rule; there is no separate calculation for the request as a whole. DeepSeek points developers to its Token & Token Usage page for more precise estimates.
Request limits and API restrictions
The documented limits are unusually specific for applications that process batches of images:
- 600 images per request
- 64 MiB total image data per request without file_id images
- Up to 200 MiB total image data when file_id images are included
- Maximum image dimension of 8,192 pixels per side
- Maximum dimension reduced to 4,096 pixels per side when a request contains 15 or more images
- 48 MiB maximum request body
- 32 MiB maximum for a single base64 or externally hosted image
- 64 MiB maximum for a single Files API image referenced by file_id
Images are accepted only in user messages. DeepSeek says images placed in system or assistant messages produce a 400 error. The model is also the only supported vision model listed in the documentation: sending images to other models returns a 400 error stating that the model does not support images. User text containing DeepSeek’s reserved image-placeholder token is rejected as well.
The documentation also says that image input works through DeepSeek’s Anthropic-compatible endpoint at https://api.deepseek.com/anthropic. The request shape differs from the OpenAI-compatible API: developers use an image block with a source object whose type is base64, url, or file.
The Anthropic-compatible version maps directly to the same three input methods. Base64 input requires a media type such as image/jpeg, image/png, image/gif, or image/webp; URL input retains the 8,192-character limit; and Files API references require the anthropic-beta: files-api-2025-04-14 header.
What developers still need to verify
DeepSeek’s documentation establishes the request formats and operational limits, but it leaves several product details unstated. It does not provide pricing for image tokens in the supplied material, a general-availability date, or benchmark results for tasks such as OCR, chart analysis, or visual reasoning.
For now, the clearest technical signal is compatibility rather than performance: the experimental model can accept images through Chat Completions, the Responses API, and an Anthropic-compatible messages endpoint, while the Files API supports larger images and repeated reuse. That gives developers multiple migration paths, but the missing price and evaluation data will determine how practical large-scale visual workloads are.