DeepSeek updated V4.1 Flash: fingerprint and effort levels changed

system_fingerprint is the cheapest way to tell whether the model behind an API has changed. I re-measured DeepSeek V4.1 Flash on both the official API and OpenDesign on 2026-10-28, and compared the result with a record from 2026-10-15.

Key Takeaways

• The fingerprint moved from aeb56401ca74e127821c4f9126dcb669 to bc19ba97cbe016479903222bb1578db6
• Both the official API and OpenDesign returned the new value, 5 out of 5 times each
• The model listing declares three effort levels while the API accepts eight
• An invalid effort returns HTTP 422 on the official API and HTTP 400 through OpenDesign

The fingerprint changed on both endpoints

The fingerprint is different from the October record. Both endpoints moved to the same new value.

The measurement ran from a home connection in Japan (colo=NRT, no VPN) at 08:10 JST.

The fingerprint does not depend on the prompt. Six different prompts all returned the same value on both endpoints. Changing reasoning_effort to none, low or high also left it unchanged.

Both endpoints still serve the same weights

A fingerprint alone proves that something changed, not what. Token-level probabilities show whether two endpoints compute with the same weights.

I sent 12 short prompts to both endpoints with temperature=0 and top_logprobs=5.

• 11 of 12 prompts matched exactly, with a maximum difference of 0.000000
• The remaining prompt differed only in how -9999 is written (-9999.0 versus -7798.767)

So OpenDesign and the official API still serve the same weights as of this measurement. That is the same conclusion as the October comparison.

One detail moved: with no reasoning_effort set, the logprobs now arrive under logprobs.reasoning_content. Setting reasoning_effort=none returns them under logprobs.content as before.

Effort handling is looser than the model listing says

The model listing reports a narrower set of levels than the API accepts. That mismatch is what every caller has to work around.

curl -s "https://api.deepseek.com/models" -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
 | python3 -c "import json,sys;print(json.load(sys.stdin)['data'][0]['effort'])"

Output:

{'supported_levels': ['low', 'high', 'max'], 'default_level': 'high'}

Only three levels appear here, while the API accepts eight. The error message is the reliable source.

HTTP 422
{"error":{"message":"Failed to deserialize the JSON body into the target type:
 reasoning_effort: unknown variant `bogus-value`, expected one of `none`, `minimal`,
 `low`, `medium`, `high`, `xhigh`, `ultra`, `max` ...","type":"invalid..."}}

The same request through OpenDesign returns HTTP 400 instead of 422, and its message lists the same eight levels.

One limit on the October comparison: I only sent invalid values through OpenDesign back then, and it answered HTTP 400 both times. The official API’s status code was not measured in October, so the 422 above is an observation, not a verified change.

What this does not tell you

A changed fingerprint means the serving configuration changed. It does not identify the change.

• The fingerprint cannot distinguish fp4 from fp8; the API never exposes the quantization format
• Logprobs are final-layer output probabilities, so they carry no precision metadata
• The raw logprob data from October is gone, so no old probability value can be compared directly
• Only two dates are known, so the switch happened somewhere between October 15 and October 28

Summary

• system_fingerprint moved from aeb56401ca74e127821c4f9126dcb669 to bc19ba97cbe016479903222bb1578db6
• Official API and OpenDesign match on the new value, and their logprobs still agree, so both serve the same weights
• The API accepts eight effort levels while the model listing declares three, and an invalid value returns HTTP 422
• The fingerprint proves a change happened but cannot show what changed