DeepSeek V4.1-Flash is now our default DeepSeek Flash model
DeepSeek V4.1-Flash is now our default DeepSeek Flash model
If you point anything on CloudCode.ONE at DeepSeek Flash — subagents, background summarisation, the cheap half of a two-model setup — you're already running the new one. deepseek-v4-flash now serves DeepSeek-V4.1-Flash, and you didn't have to change a line of config to get it.
DeepSeek announced it on September 10. It's the smallest model in their new architecture family, and it's the first Flash-tier model we've shipped where "cheap tier" stops being an apology.
The architecture is lopsided on purpose
V4.1-Flash is a 552B-parameter MoE built on what DeepSeek calls a Causal Encoder–Decoder architecture. The interesting part is the asymmetry: 8B active parameters on the input side, 16B on the output side.
That split maps almost suspiciously well onto how coding agents actually behave. An agent turn reads an enormous amount — system prompt, file contents, tool results, the whole conversation so far — and writes comparatively little: a plan, a patch, a tool call. Spending your cheap compute on ingestion and your expensive compute on generation is the right trade for that shape of workload, and it's why a "small" model can post numbers DeepSeek says land ahead of their own V4-Pro flagship.
Their words, their benchmarks — take the framing with the usual grain of salt. But the third-party reports have been pointing the same direction, and the thing feels fast in a way the scores don't fully capture.
It sees now
This is the part that changes day-to-day work.
Previous DeepSeek Flash models were text-only. Vision was a separate experimental model (deepseek-v4-flash-vision-exp), and on our side the gateway handled the gap by routing image-bearing requests to whatever could actually look at them. That routing is still there and still matters for text-only models — but deepseek-v4-flash no longer needs it.
V4.1-Flash has native visual understanding. Paste a screenshot of a broken layout, a Figma export, an architecture diagram, or a stack trace you screenshotted instead of copying, and the image lands in the same model's context as the rest of the conversation. No handoff, no intermediate description step, no losing the detail that mattered because a captioning pass decided it wasn't important.
For agent loops that render a frontend, screenshot it, and iterate, that's the difference between two models playing telephone and one model looking at its own work.
The KV cache got much smaller, and that's a bill thing
Compared with the previous generation, V4.1-Flash's KV cache needs roughly a quarter of the HBM and an eighth of the SSD storage.
That sounds like an infrastructure detail until you remember how agent pricing actually works. Every turn in a long session re-sends the entire conversation. Those tokens are cache hits, and in a twenty-turn debugging session they're the majority of what you pay for. Shrink the cache and you shrink the dominant line item.
Upstream, cache-hit input on V4.1-Flash costs a fraction of what V4-Pro charges for the same tokens — roughly a seventh — and cache-miss input and output both dropped hard too. We're passing that through.
Specs worth knowing
|
DeepSeek-V4.1-Flash |
| Context |
1M tokens |
| Max output |
384K tokens |
| Thinking |
On by default, non-thinking mode available |
| Vision |
Native, multiple images per request |
| Tool calls |
Yes |
| JSON / structured output |
Yes |
| FIM completion |
Non-thinking mode only |
| Upstream concurrency |
2,500 (vs 500 for V4-Pro) |
That concurrency ceiling is the quiet one. If you're fanning out eight subagents against the same key, Flash has five times the headroom of the Pro tier before anyone starts queueing.
What happened to V4 Pro
Short version: it's staying.
DeepSeek's launch post said V4-Pro was being phased out and that deepseek-v4-pro requests would start routing to V4.1-Flash from September 14. They then reversed it — the current API docs say V4-Pro service continues past that date with billing unchanged, in response to user demand.
So on CloudCode.ONE, V4 Pro remains available for anyone who wants it. Nothing you've built on it breaks.
And the id you call doesn't move either. deepseek-v4-flash is the public id on CloudCode.ONE, it stays the public id, and it now resolves to V4.1-Flash. There's no migration, no deprecation window, and nothing in your config to change.
DeepSeek renamed things on their side — their canonical id for this model is deepseek-flash — but that's ours to absorb, not yours to track. That's most of what a gateway is for.
Using it
Everything points at https://api.cloudcode.one, same as always.
Claude Code
export ANTHROPIC_BASE_URL=https://api.cloudcode.one
export ANTHROPIC_AUTH_TOKEN=your-cloudcode-key
export ANTHROPIC_MODEL=glm-5.3
export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-v4-flash
claude
Main agent on GLM-5.3, fast lane on DeepSeek Flash. If you're on an older Claude Code, the fast-lane variable is ANTHROPIC_SMALL_FAST_MODEL — deprecated, still honoured.
Anthropic-compatible request
curl https://api.cloudcode.one/v1/messages \
-H "x-api-key: $CLOUDCODE_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"max_tokens": 4096,
"messages": [
{"role": "user", "content": "Explain what this migration script does, then flag anything that is not idempotent."}
]
}'
With an image
curl https://api.cloudcode.one/v1/messages \
-H "x-api-key: $CLOUDCODE_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"max_tokens": 4096,
"messages": [{
"role": "user",
"content": [
{"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": "'"$(base64 -w0 screenshot.png)"'"}},
{"type": "text", "text": "The card grid breaks at tablet width. Here is the CSS — fix it."}
]
}]
}'
Harness
Nothing to do. Pick DeepSeek Flash in the model selector and you're on V4.1-Flash. Screenshots pasted into the chat go straight to the model.