Summary

Proposal to allow per-model configuration for reasoning_content fix for Deepseek v4 or any other (future) models that might require it, which is also required right now for any API providers that offer DeepSeek Model access.

Problem to solve

Recent fixes (#74374, #71473, #71146 etc) fix for the fact that Deepseek v4 models despite generally using OpenAI style API syntax, need a bit of special treatment.

However, the fixes only currently apply when the model provider is literally deepseek, and the model names are literally deepseek-v4-flash or deepseek-v4-pro. This means the fixes don't kick in when using a custom alternative provider who offers Deepseek access (e.g. Requesty) and if such a provider names their model ID differently (e.g. deepseek/deepseek-v4-pro rather than just deepseek-v4-pro.

Proposed solution

Proposal

Introduce an additional optional configuration key compat.reasoningFormat key at the model level.

{
  "id": "deepseek/deepseek-v4-flash",
  "compat": {
    "reasoningFormat": "deepseek"
  }
}

... and let that trigger the Deepseek v4 specific fixes to reasoning_context.

Details

This would feed into three existing code paths:

Stream wrapping — the universal wrapper switch (e.g. in provider-stream-CNYlhjpk.js) would check model.compat?.reasoningFormat and apply the corresponding thinking wrapper, bypassing the plugin-level wrapStreamFn gate.

Wrapper guard — the DeepSeek V4 wrapper (inside createDeepSeekV4ThinkingWrapper) already checks isDeepSeekV4ModelId(model.id). This is fine — it stays as-is, since the model ID already identifies the model family. What's needed is a path for non-plugin providers to reach the wrapper.

Response rendering — resolveOpenAICompletionsCompatDefaults would set thinkingFormat based on compat.reasoningFormat in addition to the current endpointClass/isDefaultRouteProvider checks. This avoids having to add every proxy provider ID to the isDeepSeek list in provider-model-compat-C_Djlg3U.js.

Alternatives considered

It seems obvious that this needs to be a per-model setting, rather than hard-coded per provider or for specific model names. Allowing it as an individual setting for each model that needs it lays the foundation to also apply other required per-model fixes in a consistently expressed manner, if necessary.

Impact

Positively affects anyone who accesses Deepseek models through any 3rd party provider (Requesty, Wisgate, Openrouter etc.) since without this fix, Deepseek v4 models are practically not useable.

Positively affects anyone needing to implement future per-model fixes.

Has no negative effects or drawbacks.

Evidence/examples

Prototype

My Lobster and I have implemented a more shoddy work-around in my local install, not introducing a separate key, but just hard-coding a requesty-deepseek provider into it, but it shows that it works and isn't a massive effort.

Additional information

No response