OpenDesign DeepSeek Flash Eco: Where It Differs

OpenDesign Go added deepseek-v4.1-flash-eco. The official pitch is "for non-urgent work, no quality trade-off." I sent 960 requests to see how far that claim holds.

Key Takeaways

• The no-trade-off claim holds: code execution tests passed 18/18 for both
• Multimodal holds too: images worked despite the catalog listing text only
• The delay is uneven: no gap on short turns, 2x on generation, 6x on long inputs
• Different upstreams: Volcengine for Flash, BytePlus for Eco

The quality claim holds

Eco is positioned for non-urgent work. That leaves one practical question: how long is the wait, and on which tasks?

In my measurements, the answer depended almost entirely on input length.

• Quality: identical on every checkable task I could build
• Short single turn: no measurable difference in time to first token
• Streaming output: about half the speed
• Long documents: up to six times slower

Checking the marketing claims against measurements

I lined up each claim with what I measured. Every quality claim held up.

The interesting part is that "non-urgent" is doing a lot of work in that sentence. It covers a range from no difference at all to a one-minute wait per request.

They are not even running on the same upstream

The first thing I checked was whether both models hit the same backend.

Model IDs confirmed:

id: deepseek-v4.1-flash       input_modalities: ["text","image"]
id: deepseek-v4.1-flash-eco   input_modalities: ["text"]

The stream also reports routing_info. Across ten attempts each, the routing never changed.

Different providers entirely, not a quantization variant of the same model. That explains the speed gap.

Decoding speed is where the 2x lives

I disabled thinking with reasoning_effort=none to isolate raw generation speed.

{"model": "deepseek-v4.1-flash-eco", "max_tokens": 4000,
 "reasoning_effort": "none",
 "messages": [{"role": "user", "content": "Count from 1 to 300"}]}

Counting to 300, five runs each, interleaved between models. Medians:

The first token arrives at the same time. Everything after that is half speed.

Long inputs make the gap much worse

Input prefill is the real bottleneck. Each run used a unique prefix so caching could not help.

The ratio grows with input length. For reading long documents there is no reason to pick eco.

Both models accepted 920k tokens, close to the advertised 1,048,000 limit.

Quality was essentially a tie

I used only tasks with checkable answers. Two entries my first scoring script marked wrong were corrected after reading the raw output.

Code output was actually executed against 15 test suites. Both passed everything.

Only one instruction-following case differed. Asked for an exact 40-character summary, flash returned an empty body while eco succeeded.

Images work even though the catalog says otherwise

/v1/models reports eco as text-only. It still read images correctly.

Seven of eight, identical scores. Do not trust the catalog metadata blindly, but avoid depending on undocumented capability.

Three quirks specific to eco

Quality matches, but behavior differs in ways that matter operationally.

It rejects `reasoning_effort=ultra`

flash accepts it, eco returns HTTP 400.

{"error":{"code":"upstream_error","message":"The request could not be completed."}}

It is nondeterministic at `temperature=0`

Five identical requests produced one unique output on flash and three on eco. Do not rely on eco for reproducible tests or caching.

Thinking runs away on long summarization

With reasoning_effort=high and max_tokens=8000, the body came back empty. Both models spent the entire budget on reasoning. eco made me wait 82 seconds versus 45 for flash.

The workaround is a larger cap. At 32000, eco finished within 10,113 reasoning tokens.

One point I could not verify

The claim that both models use the same weights could not be confirmed directly.

• system_fingerprint came back empty for both, five runs each
• logprobs returned null, and top_logprobs was rejected with HTTP 400

The model field and the routing provider do differ, so the two are distinguishable. Whether the weights match is not.

Summary

• The no-trade-off claim holds, with 18/18 on executable code tests for both
• The delay is uneven: no gap on short turns, 2x on generation, 6x on long inputs
• The upstreams differ: Volcengine versus BytePlus. This is not a quantization variant
• eco has its own quirks: no ultra effort, nondeterministic at temp 0, runaway thinking
• The split is clear: short conversations on eco, long documents and code editing on flash