You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The TPS output from Deepseek V4.1 is very slow. Last week, it was averaging around 250, but today it's only around 100. This is almost a 50% decrease, which significantly impacts the user experience.
2026-09-29 00:49 +08:00:
provider-metadata → providerMetadata = {"novita": {...}}
no deepseek block, no gateway.routing at all.
Response headers changed too: x-fusion-transport: embedded,
x-ratelimit-*, and one response carried a Domain=novita.ai cookie.
Control in the same run: deepseek/deepseek-v4-pro still returns the full
DeepSeek-official metadata (finalProvider:"deepseek", systemFingerprint,
zero-markup cost reconciliation). So this is a flash-tier change, not
"Command Code left DeepSeek".
That lines up with the reports in this thread: ~250 → ~100 tok/s, much higher
latency, and output that is "significantly different from the official
version". Novita does list DeepSeek V4.1 Flash in its own model library.
Caveat: this is a single observation window right after the 2026-09-28
DeepSeek API outage, so it could be failover rather than a permanent switch.
Worth re-checking over the next days — the test is cheap and deterministic.
Why nobody noticed earlier: the official-vs-third-party routing only shows up
in the raw stream's provider-metadata event. Normal CLI/desktop UI surfaces
(tok/s, usage, cost) look identical either way.
Activity
XXXE88 commentedon Sep 28, 2026
And today's (September 28th) DeepSeek V4.1 Flash is significantly different from the official version.
XXXE88 commentedon Sep 28, 2026
GOAT Package; Intelligence is very low, with a severe decline; No feedback channels
XXXE88 commentedon Sep 28, 2026
centre009 commentedon Sep 28, 2026
Reproducing the TPS/latency reports above with the transport metadata —
deepseek/deepseek-v4.1-flashis no longer being served by DeepSeek's own API.Same key, same CLI channel (POST /alpha/generate), same model, tiny prompt.
Baseline (mid-September, archived):
provider-metadata → providerMetadata.deepseek {promptCacheHitTokens,
systemFingerprint} + providerMetadata.gateway.routing
{resolvedProvider:"deepseek", finalProvider:"deepseek",
credentialType:"system", only:["deepseek"]}
2026-09-29 00:49 +08:00:
provider-metadata → providerMetadata = {"novita": {...}}
no
deepseekblock, nogateway.routingat all.Response headers changed too: x-fusion-transport: embedded,
x-ratelimit-*, and one response carried a
Domain=novita.aicookie.Control in the same run:
deepseek/deepseek-v4-prostill returns the fullDeepSeek-official metadata (finalProvider:"deepseek", systemFingerprint,
zero-markup cost reconciliation). So this is a flash-tier change, not
"Command Code left DeepSeek".
That lines up with the reports in this thread: ~250 → ~100 tok/s, much higher
latency, and output that is "significantly different from the official
version". Novita does list DeepSeek V4.1 Flash in its own model library.
Caveat: this is a single observation window right after the 2026-09-28
DeepSeek API outage, so it could be failover rather than a permanent switch.
Worth re-checking over the next days — the test is cheap and deterministic.
Why nobody noticed earlier: the official-vs-third-party routing only shows up
in the raw stream's
provider-metadataevent. Normal CLI/desktop UI surfaces(tok/s, usage, cost) look identical either way.
XXXE88 commentedon Sep 29, 2026