DeepSeek V4-Flash-Vision-Exp: pricing, vision and routing

The launch recorded on August 21, 2026, placed DeepSeek-V4-Flash-Vision-Exp in DeepSeek's official documentation as an experimental model that accepts image input in addition to text. The published pricing table lists US$ 0.22 per million cache-miss input tokens outside peak hours. For a buyer, the consequence is direct: a multimodal route must be measured per request, not selected from one isolated price. The official pricing page was consulted on August 25, 2026.

What was launched, and what does the documentation confirm?

The official documentation confirms that DeepSeek-V4-Flash-Vision-Exp is experimental, uses deepseek-v4-flash-vision-exp in an API call, and accepts image input in addition to text. The same page publishes six values per million tokens, divided between cache-hit input, cache-miss input, and output, across two billing windows. That is the central fact, without extrapolation.

Confirmed fact: the Your First API Call page lists deepseek-v4-flash-vision-exp as the API identifier and states that the experimental version accepts images. The pricing page names the version DeepSeek-V4-Flash-Vision-Exp. The documentation also states that image-to-token conversion depends on image dimensions. This text does not reproduce benchmarks or claim leadership, superiority, or equivalence.

The six published prices are:

Cache hit and cache miss are the two published input billing categories. The buyer must use the provider's recorded usage and the cache status of each request to classify a call. If a team explains prefix or context-cache mechanisms, it needs the specific documentation, because the pricing table does not define that semantics.

The documentation defines peak hours as 01:00 to 04:00 UTC and 06:00 to 10:00 UTC, Monday through Friday. Every other period is classified in the table note as outside peak hours. A team operating in Brazil needs to record the time in UTC instead of inferring the window from the service's local clock. Time changes the bill.

The official page also warns that prices can change and that the provider may adjust them. The six values above are therefore the dated record of the official table consulted on August 25, 2026. They are not a promise of effective cost for a specific application and do not replace periodic review of the official documentation.

Operational inference: the buyer should store the table-reading date with the usage report. Without that date, a comparison made weeks later mixes a reference price with the price in force.

Why is price per token not enough for a multimodal request?

Price per token is not enough because an image sent to DeepSeek-V4-Flash-Vision-Exp is converted into tokens according to its dimensions and billed with the text input tokens. The request cost therefore depends on the image, text, cache, time window, and consumed output. The measurement changes the decision.

The formula published in the documentation is simple: spending equals the number of tokens multiplied by the applicable price. The difficult part is identifying the number and category of every token correctly. In a multimodal request, image tokens enter the input. The consulted table does not show a separate image charge.

The official Vision documentation, consulted on August 25, 2026, states that images are resized before inference. Larger images are reduced to an approximate budget of 800 x 800 total pixels, smaller images are enlarged, and each image has a documented upper limit of 384 tokens under that processing rule. In a request with several images, each image is counted independently. The 384-token limit is conditional on that documented mechanism, not a general property of multimodal models.

Image dimensions allow a tokenization estimate, and the token-usage page offers a calculator for specific sizes. That estimate does not replace the image tokens actually recorded in the API usage response, which must be kept separate when billing is compared. Without naming and citing the corresponding usage field in the API documentation, this article does not treat that record as definitive. There is no universal cost for a photo, screenshot, scanned page, or technical drawing. An estimate is not an invoice.

That point changes the unit of analysis. “US$ 0.22 per million” describes cache-miss input outside peak hours. It does not describe the cost of a request combining an image, a text instruction, and a response. Likewise, “US$ 0.007 per million” applies to cache-hit input outside peak hours, not to every input sent to the model.

Output deserves its own line. The table lists US$ 0.66 per million tokens outside peak hours and US$ 1.32 per million tokens during peak hours. A task with little input and a long response should not be compared only on the input line. Output must remain separate in the report.

The common mistake is adding input and output tokens as if they were one category. That erases the distinction between cache-hit input, cache-miss input, and output. The second mistake is treating the image as an attachment without economic weight. The official documentation says otherwise: the converted image enters input billing.

Still unverified: the consulted documentation does not support a universal cost by image class. Dimensions support an estimate, but the tokens and usage actually recorded for each call define the API reference. The published prices also cannot be converted into a buyer savings percentage without comparable usage data. Measurement settles the question.

What changes for an AI buyer in production?

For an AI buyer in production, image input expands the set of tasks that can enter evaluation while increasing the variables that must be observed. The right decision is not to adopt the model because it appears inexpensive. It is to test cost per completed task, answer quality, latency, cache behavior, and availability in the flow that will be routed. Price does not decide alone.

Confirmed fact: DeepSeek describes the model as experimental. The consulted documentation does not support a universal recommendation, general availability, SLA, or performance leadership. The table text is not a visual or textual quality benchmark.

Operational inference: the CTO should treat the model as a candidate route, not a default destination. The platform leader should separate image tasks from text tasks and record whether each response meets the business criterion. FinOps should examine cost per completed task, because inexpensive tokens do not guarantee a useful first response.

The official pricing documentation, consulted on August 25, 2026, lists 1 million context tokens, a maximum of 384 thousand output tokens, and a concurrency limit of 2,500 for deepseek-v4-flash-vision-exp. The official Vision guide, consulted on the same date, documents supported image formats, a 48 MiB request-body limit, 32 MiB for base64 or external-URL images, 64 MiB for Files API IDs, and up to 600 images per request. The maximum is 8,192 pixels per side, reduced to 4,096 pixels when a request contains 15 or more images. These are documentation values accessed on August 25, 2026, not an SLA or availability guarantee.

A quality classification must be defined before testing. For document reading, the team can check correctly extracted fields, omissions, and the need for human review. For image analysis, it can check whether the response identifies the elements required by the task. The article does not assign the model a capability that the official source did not describe. The test answers the suitability question.

Latency and time window belong in the same decision. An outside-peak window may have a lower published price, but the buyer should not move sensitive traffic without measuring the effect on response time and operations. Peak hours have two UTC ranges. The policy must turn that information into an observable field, not a hidden rule in code.

The failure mode also needs a name. A flow may send a large image, receive an incomplete response, retry the request, and pay input and output tokens again. It may also send the same task to another route without recording why. When that happens, cost per task disappears and the team concludes that the model is expensive, when the real problem was an untraceable retry policy.

This is the type of measurement covered in how to measure LLM provider performance before setting a routing policy. The difference here is that image input adds a token variable that must be present in the baseline from the first test.

How should cost be compared before changing the route?

The comparison must move beyond unit price and reach a request policy. Before, a team could look at the input line and choose a route by intuition. Afterward, it must record image, text, output, cache, UTC time, quality, and cost per task, while keeping a fallback when the answer or availability misses the defined criterion. The spreadsheet needs context.

The right-hand column does not claim that the model will have a specific effective cost. It describes what the buyer must measure to reach that cost. The official table is the starting point. Production results appear only after the team observes its own traffic.

There is no basis for calculating a percentage saving from the six numbers. The outside-peak price is published in one band, the peak price in another, and a request can combine cache miss, image, and output. Without volume, dimensions, cache distribution, time windows, and quality, any percentage would be invented.

A route change must also consider result stability. If an answer fails the task criterion, a second processing attempt can consume more tokens than the first call. If the team does not record rework, the spreadsheet shows a low price and an expensive operation.

A buyer already following model economics in routing can reuse break-even discipline, but it should not import a conclusion from one version into another. The current event includes image input and a specific billing composition. The correct unit remains the observed task.

What should be measured in a DeepSeek V4-Flash-Vision-Exp test?

The test should answer five decisions before any default route changes: which tasks enter, which images will be measured, how cache and time will be compared, what quality approves an answer, and when fallback starts. Each decision needs a per-request record and a baseline from before adoption. Start small.

1. Define the text and multimodal baseline. The team should separate tasks that already use text from tasks that will send images, recording volume, text tokens, output tokens, and operational result. Without that split, a cost variation may come from mixed tasks rather than the model.

2. Build a representative, anonymized corpus. The fixed sample should contain the image classes the operation actually receives, such as screenshots, scanned documents, product images, and technical drawings, with dimensions recorded and personal data removed. The same corpus should run through DeepSeek and the incumbent route in a paired comparison.

3. Fix the rubric and measure quality. Before looking at price, the team should define task approval criteria, such as correct fields, no omissions, identification of required elements, and the need for human review. The rubric must not change during the cycle. The report should include first-pass success, human-review rate, retries, latency, and cost per accepted task, along with tokens and cache.

4. Separate cache and time. Every call needs cache_status and utc_time. The team should compare cache-hit input with cache-miss input and distinguish the ranges of 01:00 to 04:00 UTC and 06:00 to 10:00 UTC, Monday through Friday, from all other periods. The published table guides the test; it does not promise the result.

5. Decide fallback and exposure limits. The team should set when an answer is sent to another route, what spending limit is accepted per key or project, and how each switch is audited. The policy needs exponential backoff bounded by a ceiling, a circuit breaker, and a combined maximum budget for retries and fallbacks per task. Transient transport or provider errors may enter the policy; invalid requests, such as unsupported format, size, dimensions, or image count, and model selection without Vision must be filtered rather than repeated. The trace must record whether a second provider call occurred, making duplicate billing visible when the first attempt was already accepted or partially processed.

The test must survive an audit. A report containing only total spending does not show what happened to the image. A report containing tokens but not cache does not explain the price choice. A dashboard showing cost but omitting quality does not reveal whether savings came with more rework.

The model router as middleware for the AI stack helps place the decision correctly: the application should not carry an isolated pricing rule while route data is scattered across different integrations.

Where does Nexforce Router fit in this decision?

Nexforce Router enters as a gateway and decision layer for comparing model routes, without promising a specific integration with the deepseek-v4-flash-vision-exp identifier. The honest connection is operational: one API, selection by cost, performance, latency, and context, configurable fallback, limits, traceability, observability, and analytics for the policy the buyer actually tests. Governance comes first.

The product reference describes Router as an LLM gateway with an API for models and routing intelligence. Documented capabilities include selection by cost, performance, latency, and context, model fallback, price and performance ranking, limits by key, agent, or project, logs, metrics, tracing, dashboards, cache, and savings and performance analytics. The Nexforce Router institutional page supports this mapping.

This does not mean Nexforce confirmed a ready integration with the DeepSeek identifier for this article. The official provider documentation confirms the identifier at its endpoint. Router is presented here as a governance layer capable of receiving a decision policy, not as proof of validated compatibility with this experimental model.

In practice, the application can send the request to a single layer while the policy decides whether traffic follows a multimodal route, another available route, or a fallback. That is an architectural inference, not a verified property of this integration. A real Router test must validate preservation of the multimodal payload, normalization of provider-specific errors, image handling, and billing telemetry before concluding that route switching works as expected.

Limits by key or project help prevent an experimental test from consuming the entire budget. Traceability preserves the relationship between request, tokens, time, and response. Observability shows latency and errors. Analytics organizes cost and performance. None of these functions turns the published price into guaranteed savings.

Confirmed fact: the Nexforce Router product documents these gateway, routing, fallback, limit, and observability capabilities. Operational inference: they are suitable for structuring a multimodal cost test. Still unverified: specific compatibility with deepseek-v4-flash-vision-exp and model behavior inside a Router route were not confirmed by the official sources used here; multimodal payload preservation, error normalization, image handling, and billing telemetry require an integration test.

Frequently asked questions about DeepSeek V4-Flash-Vision-Exp

DeepSeek-V4-Flash-Vision-Exp is an experimental model with image input, and the official documentation publishes distinct prices for cache-hit input, cache-miss input, and output during peak and outside-peak hours. The answers below preserve the boundary between what the table confirms, what the buyer must measure, and what remains unverified. The table is not a benchmark.

How much does DeepSeek V4-Flash-Vision-Exp cost per million tokens?

Outside peak hours, the table lists US$ 0.007 per million tokens for cache-hit input, US$ 0.22 for cache-miss input, and US$ 0.66 for output. During peak hours, it lists US$ 0.014, US$ 0.44, and US$ 1.32, respectively. These are table prices consulted on August 25, 2026.

How is an image billed?

The official documentation states that images sent to DeepSeek-V4-Flash-Vision-Exp are converted into tokens according to their dimensions and billed as input tokens together with text. Dimensions support a documented tokenization estimate, but usage recorded in the API response is the operational reference, without this article naming a specific field as definitive. There is no universal cost for every image. Records beat estimates.

What are the peak hours?

The published peak hours are 01:00 to 04:00 UTC and 06:00 to 10:00 UTC, Monday through Friday. All other periods are classified as outside peak hours in the table note. The measurement system should record UTC because a local time zone can move a call into a different policy window.

Does the lower price justify making the model the default route?

No. The model is experimental, and the consulted documentation does not confirm a universal recommendation, SLA, general availability, or superiority benchmark. The buyer must measure quality, latency, image tokens, cache, time, output, failures, and fallback. A default route makes sense only after the completed task, rather than the token alone, has a known cost.

Does Nexforce Router already integrate this identifier?

The sources used in this analysis do not confirm a specific Nexforce Router integration with deepseek-v4-flash-vision-exp. Router can support the decision as a gateway and routing layer, with selection, fallback, limits, traceability, and observability documented in the product. Concrete compatibility with the identifier must be verified before any technical promise.

References and Further Reading

• DeepSeek API Docs, Models & Pricing, official pricing documentation consulted on August 25, 2026.
• DeepSeek API Docs, Your First API Call, official documentation listing the deepseek-v4-flash-vision-exp identifier and pointing to the Vision guide, consulted on August 25, 2026.
• DeepSeek API Docs, Vision, official guide on resizing, image tokens, formats, request limits, and multiple images, consulted on August 25, 2026.
• Nexforce Router, official product page and reference for gateway and routing capabilities.

The routing decision starts after the table

The published price opens a testing opportunity, but it does not close a production decision. For a B2B buyer, the right question is how much it costs to complete a multimodal task at the required quality, during the actual time window, with observed cache behavior and a fallback that can absorb failure. Nexforce Router is the governance layer for measuring that choice. The route should change only after the data. The next step is measurement.