# DeepSeek Vision API Caps Every Image at 384 Tokens

> DeepSeek's vision model resizes every image toward 800x800 before inference, so image cost is a flat 384 tokens regardless of original resolution.

Published: 2026-08-22
URL: https://daniliants.com/insights/deepseek-vision-api-caps-every-image-at-384-tokens/
Tags: deepseek, multimodal, openai-compatible, api

---

## Summary

DeepSeek's `deepseek-v4-flash-vision-exp` model accepts images via three methods, inline base64, external URL, or a pre-uploaded Files API reference, across OpenAI-compatible, Anthropic-compatible, and Responses API endpoints. Image cost is capped regardless of resolution: every image is resized toward roughly 800x800 pixels before inference, so a 2000x2000 and a 5000x5000 image consume the same fixed 384 tokens.

## Key Insight

- **Flat token cost per image is the standout detail.** Because resizing targets roughly 800x800 px pre-inference, image cost is capped at 384 tokens no matter the original resolution. Multi-image requests don't get a discount or penalty; each image is counted independently under the same rule. This makes cost prediction trivial versus providers that scale tokens with resolution or tiling.
- **Three ingestion paths, each with different limits, not just convenience variants:**

  - Inline base64: simplest, but counts toward the 48 MiB total request body limit; capped at 32 MiB per image.
  - External URL: the model fetches it; URL max 8192 chars, file max 32 MiB, download must finish in 60 seconds.
  - Files API `file_id`: the only path that supports images up to 64 MiB and isn't checked against the 32 MiB per-image cap; best when reusing the same image across many requests (avoids re-upload).

- **Hard ceilings worth knowing before hitting them in production:** max 600 images per request; max total image payload 64 MiB without `file_id` (up to 200 MiB if using `file_id` references); max image dimension 8192 px per side, but that drops to 4096 px per side once a request contains 15+ images.
- **Format detection is content-based, not filename or MIME-based.** A mislabeled file still gets parsed correctly (or rejected) based on actual bytes.
- **Images are restricted to `user` messages only.** Putting an image in a `system` or `assistant` message returns a `400` error, and only the vision-tagged model accepts images at all (other models 400 with "This model does not support image").
- **The `detail` field (`low`/`high`/`original`/`auto`) only matters for `image_url` inputs.** `low` downsamples to 512x512 before inference (cheaper and faster when detail doesn't matter); it's silently ignored when the image comes via `file_id`.
- The Anthropic-compatible endpoint (`/anthropic` base path) mirrors the same three methods but reshapes them as `image` blocks with a `source.type` of `base64`, `url`, or `file`. The `file` variant requires the `anthropic-beta: files-api-2025-04-14` header.