Your deepseek-v4-flash ID Is Being Replaced — Here's the Fix

DeepSeek V4.1 Flash replaces V4 Flash. New model ID deepseek-flash, lower per-token price, native image understanding, and a migration checklist.

O
OurToken Team//7 min
Your deepseek-v4-flash ID Is Being Replaced — Here's the Fix

DeepSeek Flash has changed under you. The route you may be calling as deepseek-v4-flash is being replaced by DeepSeek V4.1 Flash, served through a new model ID, deepseek-flash. The old ID still resolves for now — OurToken lists it as serving requests with V4.1 Flash underneath — but the migration is worth doing now rather than waiting for a forced cutover. On OurToken the change is good news on both axes that matter: the new route bills at a lower per-token price than the old V4 Flash route, and it adds native image understanding that the old Flash did not have.

This guide explains what changed, what the new model ID and prices are on OurToken, and how to migrate an existing integration without breaking anything. It uses the live OurToken DeepSeek Flash page as the billing source and the official DeepSeek V4.1 Flash announcement for the model changes.

Verification status: Prices and model IDs are dated 2026-10-25 and were verified against the live OurToken DeepSeek Flash model page and the official DeepSeek announcement. Prices change; confirm the current model page before budgeting.

What Changed: V4 Flash → V4.1 Flash

DeepSeek's announcement lays out the migration in plain terms. V4.1 Flash is the smallest model in the new architecture family, with native visual understanding, and it retires the previous generation.

The changes that matter for an API consumer are:

  1. New model ID. V4.1 Flash is called through deepseek-flash. The old IDs deepseek-v4-flash and deepseek-v4-flash-vision-exp are retired on the DeepSeek platform and, per the official announcement, temporarily route to V4.1 Flash for compatibility. OurToken's deepseek-v4-flash page says the ID still resolves — DeepSeek serves those requests with V4.1 Flash underneath — and recommends deepseek-flash at the lower rate.
  2. New architecture. V4.1 Flash is a 552B-parameter MoE with an asymmetric Causal Encoder–Decoder design: roughly 8B parameters active for input and 16B for output. The practical result is a smaller KV cache — the announcement claims 1/4 the HBM and 1/8 the SSD storage versus the previous generation, which cuts the cache-hit cost that dominates agent workloads.
  3. Native multimodal support. V4.1 Flash understands images natively. The old V4 Flash did not; you had to reach for a separate vision route.
  4. V4-Pro is being phased out. The announcement states that deepseek-v4-pro requests route to V4.1 Flash at V4.1 Flash rates, continuing until a V4.1 Pro launches.

The official announcement also notes peak/off-peak pricing on the DeepSeek platform (off-peak at 50% of peak), but OurToken lists a flat rate, so for OurToken billing the flat rate below is what you use.

DeepSeek Flash Pricing on OurToken

On OurToken, the new V4.1 Flash route (deepseek-flash) lists at 40% of the official reference. The old V4 Flash route (deepseek-v4-flash) is still listed at 60% of its own reference, and the two do not share a rate card.

RouteInputOutputCached inputCache writes
DeepSeek V4.1 Flash (deepseek-flash)$0.1800 / 1M$0.7200 / 1M$0.0036 / 1M$0
Old DeepSeek V4 Flash (deepseek-v4-flash)$0.2640 / 1M$0.7920 / 1M$0.0084 / 1M$0

The migration is a net price cut on every category: input drops from $0.2640 to $0.1800, output from $0.7920 to $0.7200, and cached input from $0.0084 to $0.0036. Combined with the smaller KV cache, the cached-input bill — usually the largest line on long agent sessions — falls twice over: a lower per-token rate and fewer cache tokens to begin with.

The official reference prices behind these are $0.30 input, $1.20 output, and $0.006 cached for V4.1 Flash, versus $0.44, $1.32, and $0.014 for the old V4 Flash.

The model ID and endpoint

Use the new model ID through the same OurToken endpoint:

Base URL:      https://api.ourtoken.ai/v1
Full endpoint: https://api.ourtoken.ai/v1/chat/completions
Model ID:      deepseek-flash
Context:       1M tokens
Max output:    up to 384K tokens

The endpoint does not change — this is a model ID migration, not a base URL migration. The base URL and auth header stay exactly as they are.

How to Migrate from deepseek-v4-flash

The migration is small, but there are three things to check so it does not silently change your bill or your behavior.

1. Change the model ID. Replace deepseek-v4-flash with deepseek-flash in configuration and application code. The DeepSeek V4 API key setup guide documents the endpoint shape; the only change is the model string.

2. Re-check your cached-token accounting. The cached-input rate changed ($0.0084 → $0.0036) and the KV cache shrank. Your existing cost-estimation code that hard-codes the old cache rate is now wrong. The OpenAI-compatible prompt caching guide covers the accounting rule — cached tokens are a subset of input, billed at the cache rate — but the rate itself has to come from the live model page, not from a constant.

3. Decide whether to adopt image input. The old V4 Flash had no vision, so any image-in-capable pipeline you have probably pointed elsewhere. V4.1 Flash's native image understanding lets you consolidate text and image requests onto one deepseek-flash route. Test it on the live route before enabling it in production, because image tokens bill differently from text tokens.

Python example

The OpenAI-compatible client code does not change except for the model string:

import os

from openai import OpenAI


client = OpenAI(
    api_key=os.environ["OURTOKEN_API_KEY"],
    base_url="https://api.ourtoken.ai/v1",
)

response = client.chat.completions.create(
    model="deepseek-flash",  # was deepseek-v4-flash
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "Summarize the following in one sentence."},
    ],
    max_tokens=128,
)

print(response.choices[0].message.content)

For a cURL smoke test, the same request looks like:

curl -sS https://api.ourtoken.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${OURTOKEN_API_KEY}" \
  -d '{
    "model": "deepseek-flash",
    "messages": [
      {"role": "user", "content": "Give me a one-sentence summary of model routing."}
    ],
    "max_tokens": 64
  }'

DeepSeek V4.1 Flash vs V4 Pro

The announcement goes further than just replacing Flash: it positions V4.1 Flash as ahead of V4-Pro on performance, cost, speed, and total runtime, and states that deepseek-v4-pro requests will route to V4.1 Flash at V4.1 Flash rates until V4.1 Pro launches.

In practical terms, that means if your application currently routes the "hard" requests to deepseek-v4-pro and the "cheap" requests to deepseek-v4-flash, the two routes are converging. Until V4.1 Pro ships, the official platform maps both to V4.1 Flash. On OurToken, the two pages are still separate, so check the DeepSeek V4 Pro page for its current state before relying on the convergence claim in your billing.

The consolidation is a good moment to simplify: if one model now serves both tiers, you can drop the routing logic and run everything on deepseek-flash, or keep the routing but point both branches at V4.1 Flash for the time being. The LLM model routing guide covers the general pattern if you later want to re-split by task.

What This Does Not Change

Do not over-correct. The migration is a model swap, not an integration rewrite.

  • The endpoint is unchanged. https://api.ourtoken.ai/v1/chat/completions stays.
  • The auth is unchanged. The same OurToken key works; no new credential.
  • The OpenAI-compatible shape is unchanged. The SDK and cURL examples above differ only by the model string.
  • The DeepSeek official vs gateway comparison still holds. That article's core point — a gateway flat rate versus official peak/off-peak pricing — is about the provider's time-of-day discount, and it still applies to V4.1 Flash's official off-peak tier. The migration does not change that calculus; it changes which flat rate you pay on OurToken.

Conclusion

DeepSeek Flash has become DeepSeek V4.1 Flash, and the migration is worth doing now rather than waiting for a forced cutover. Change the model ID from deepseek-v4-flash to deepseek-flash, and you get a lower price on every token category on OurToken plus native image understanding, with no endpoint or auth change. The only real work is re-checking any hard-coded cost constants, since both the cache rate and the KV cache size changed.

Get a key from the OurToken API Keys page, switch the model string, and verify the new usage and cache numbers on the live DeepSeek Flash model page. The DeepSeek V4 API pricing guide still has the calculator pattern if you want to keep a cost model in Python — just swap in the new rates.

FAQ

Is deepseek-v4-flash still working?

For now, yes. OurToken's deepseek-v4-flash page says the ID still resolves and serves requests with V4.1 Flash underneath, but the recommended route is deepseek-flash at the lower rate. Migrate now rather than waiting for a forced cutover.

Is DeepSeek V4.1 Flash cheaper than the old V4 Flash?

On OurToken, yes. Input drops from $0.2640 to $0.1800, output from $0.7920 to $0.7200, and cached input from $0.0084 to $0.0036 per million tokens.

Does DeepSeek Flash support images?

Yes. V4.1 Flash has native image understanding, which the old V4 Flash route did not. Test image input on the live route before using it in production.

What is the new DeepSeek Flash model ID?

Use deepseek-flash on OurToken. The old deepseek-v4-flash and deepseek-v4-flash-vision-exp IDs are retired on the DeepSeek platform but still resolve for now, routing to V4.1 Flash underneath.

What happens to my deepseek-v4-pro requests?

The official announcement says deepseek-v4-pro routes to V4.1 Flash at V4.1 Flash rates until V4.1 Pro launches. Check the current OurToken DeepSeek V4 Pro page for its live state.

Do I need to change my base URL or API key to migrate?

No. Only the model ID changes. The endpoint, auth header, and OpenAI-compatible request shape all stay the same.

ourtoken-blog-76.webp
ourtoken-blog-76.webp