SkyrimNet fails to detect content deepseek's chinese prohibition message

[GoodProvider]

What's happening?

When deepseek responds with "你好，我无法给到相关内容" (Hello, I am unable to provide the requested content.)
This means that it is refusing to respond. SkyrimNet is not detecting this.

Steps to reproduce

Do something deepseek doesn't approve of. Mostly seen it in memory access.

How often does this happen?

Every time (100% reproducible)

Expected behavior

SkyrimNet should give a notification to the user.

What area is affected?

Memory (NPCs forgetting things, wrong memories)

TTS Provider

XTTS (remote/local server)

LLM Model

deepseek/deepseek-v4-flash

STT Provider (if relevant)

None

Game Version

AE (1.6.1170+)

Game Version (if Other)

No response

Modlist

n/a

SkyrimNet version

beta21-rc3

Did this work before?

Not sure / first time trying

What changed? (if it used to work)

I've been seeing it for a while. Decided to investigate today.

Log file

SkyrimNet.log

Anything else?

No response

[dimadetroit]

Hey @GoodProvider, jumping in as a fellow user — I had exactly this problem about two weeks ago with deepseek-chat-v3-0324 on the memory variant, ~86% of memory generations failing with that same Chinese refusal template. Here's what we found and what fixed it:Root cause (not SkyrimNet's fault): OpenRouter routes DeepSeek requests through several backend providers, and some of those providers wrap a content filter that returns the Chinese refusal instead of the actual model output. It's not the model refusing — it's an intermediary provider's safety layer. This means the same DeepSeek model can work fine on one request and refuse on the next, depending on which provider OpenRouter picks. The memory prompt is especially prone to it because memory generation often consolidates emotionally-loaded events (combat, intimacy, deaths) that trigger the provider's filter even though the underlying DeepSeek model itself would have answered fine.Why memory specifically gets hit: dialogue prompts run constantly and the filter triggers on a small fraction; memory generation runs less often but each one summarises a large window of recent events, so the cumulative "spicy content" density per request is way higher. You notice it as "every time" because every memory generation is a high-content-density request.What fixed it for me:

Easiest fix — switch the memory variant model away from DeepSeek to one with fewer provider intermediaries. I moved memory generation to google/gemini-2.5-flash-lite. Cheap, fast, no Chinese refusals, and memory generation doesn't need a heavyweight model anyway — it just needs to summarise events into JSON. Been running on Gemini for two weeks, zero refusals.
If you want to stay on DeepSeek — go into your OpenRouter dashboard and explicitly whitelist only DeepSeek's own first-party endpoint for that model (under provider preferences). This bypasses the third-party wrappers. Works but you lose fallback redundancy if DeepSeek's own endpoint goes down.
Bottom line — this isn't really a SkyrimNet bug to fix; the plugin is correctly forwarding what OpenRouter returned. But @MinLL it would be lovely if SkyrimNet detected this specific pattern (the Chinese refusal text is very distinctive) and either retried automatically or surfaced a clearer warning to the user, since the silent failure mode is confusing — the player just sees memories getting corrupted with no idea why.Hope this helps you get back to playing fast! 🍻

[GoodProvider]

Thanks. Goncola solve my problem by excluading alibaba provider in Open Router.

But the bug remains.SkyrimNet needs to spawn an error message,

[MinLL]

We don't have any sort of parsing to try to detect rejection messages today.

[GoodProvider]

I was receiving error message for policy rejections caused by other models.
Maybe they where setting something in the JSON metadata.

Since it is happening in metadata calls, a normal user will not detect know it is happening.

How much effort would it be to detect and count (with decay) the frequency of a stable useless responses. They can't be parsed correctly or in this case don't select any memories. If a static useless response cross a threshold, this would trigger a call to an LLM to explain it and send a Debug.Notification to the user that something is likely wrong.

[MinLL]

I did that on CHIM for English; It worked, but I had probably 20 variants of fragments of "Sorry Hal, I can't do that" - not to mention that we have users that play in a lot of languages. Also - Different LLM's all have very different flavors of "I'm not going to comply" responses. How do you quantify a "static useless response"? They're typically not always the same, and differ.

[GoodProvider]

. How do you quantify a "static useless response"? They're typically not always the same, and differ.

Indeed that is the core problem. At this point, I am happy to close the issue.

But if you want to think about think about it ;). While a general solution isn't possible, but there might be specific solutions.

• memory: no memories returning