Error: 400 reasoning_effort for DeepSeek v4 pro xhigh on OpenRouter

[zaskara]

What happened?

I choose (openrouter) deepseek/deepseek-v4-pro • xhigh, then try to send a message and it shows error:

Error: 400 reasoning_effort: Invalid option: expected one of
"xhigh"|"high"|"medium"|"low"|"minimal"|"none"

But it is xhigh.

With 'high' it works.

Also, I tried to set it in models.json like this, but pi didn't show xhigh at all in that case:

"reasoning": true, "compat": { "requiresReasoningContentOnAssistantMessages": true, "thinkingFormat": "deepseek", "reasoningEffortMap": { "minimal": "high", "low": "high", "medium": "high", "high": "high", "xhigh": "max" } }

Steps to reproduce

(openrouter) deepseek/deepseek-v4-pro • xhigh

Expected behavior

xhigh maps to max reasoning

Version

0.75.3

[github-actions]

This issue was auto-closed. All issues from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md will not be reopened or receive a reply.

If a maintainer replies lgtmi on one of your issues, your future issues will stay open. If a maintainer replies lgtm, your future issues and PRs will stay open.

See CONTRIBUTING.md.

[behrangsa]

A similar problem, but via the official DeepSeek APIs:

DeepSeek V4 has two thinking levels: high and max (see https://api-docs.deepseek.com/guides/thinking_mode).

However, Pi can only set thinking mode to high and xhigh.

Also the average token counts for high/xhigh (~16K/~32K) is not applicable to DeepSeek V4.

• Is there a way to map xhigh to max when the active model is DeepSeek V4 Flash/Pro?
• Is there a way to not display (~16k tokens)/(~32k tokens) in the Thinking Level selector when the active model is DeepSeek V4?

Or is this a bug?

$ pi --version
0.75.4

Update

This configuration seems to be working fine:

{
  "providers": {
    "deepseek": {
      "baseUrl": "https://api.deepseek.com",
      "api": "openai-completions",
      "apiKey": "sk-...",
      "compat": {
        "supportsDeveloperRole": false,
        "supportsReasoningEffort": true,
        "thinkingFormat": "deepseek",
        "supportsStrictMode": false,
        "supportsLongCacheRetention": false
      },
      "models": [
        {
          "id": "deepseek-v4-flash",
          "reasoning": true,
          "input": ["text"],
          "contextWindow": 1048576,
          "maxTokens": 384000,
          "cost": {
            "cacheRead": 0.0028,
            "cacheWrite": 0.28,
            "input": 0.14,
            "output": 0.28
          },
          "thinkingLevelMap": {
            "minimal": null,
            "low": null,
            "medium": null,
            "high": "high",
            "xhigh": "max"
          }
        },
        {
          "id": "deepseek-v4-pro",
          "reasoning": true,
          "input": ["text"],
          "contextWindow": 1048576,
          "maxTokens": 384000,
          "cost": {
            "cacheRead": 0.003625,
            "cacheWrite": 0.87,
            "input": 0.435,
            "output": 0.87
          },
          "thinkingLevelMap": {
            "minimal": null,
            "low": null,
            "medium": null,
            "high": "high",
            "xhigh": "max"
          }
        }
      ]
    }
  }
}

[zaskara]

@behrangsa thank you! What about "requiresReasoningContentOnAssistantMessages": true? Official docs have it.

https://api-docs.deepseek.com/quick_start/agent_integrations/pi_mono

[behrangsa]

@behrangsa thank you! What about "requiresReasoningContentOnAssistantMessages": true? Official docs have it.

https://api-docs.deepseek.com/quick_start/agent_integrations/pi_mono

Ah, I didn't know about that. It worked even without that. I'll add it to my config to see what happens.

Edit: according to DeepSeek:

The requiresReasoningContentOnAssistantMessages flag is actually a compatibility setting for providers like DeepSeek that require reasoning_content to be echoed back, especially in multi-turn tool-call scenarios. While the flag defaults to false, it is generally recommended to set it to true for the best experience. However, your models still work without it because Pi has built-in measures to prevent failures in common use cases:

· Empty Field Fallback: For DeepSeek models, Pi may automatically inject an empty reasoning_content: "" into assistant messages. While this is less robust than echoing the original reasoning, it often satisfies the API when the conversation doesn't strictly require the original field, preventing a 400 error.
· Limited Impact: The strict requirement for reasoning_content only applies to specific, complex scenarios like multi-turn conversations that involve tool calls.

If you'd like to ensure full compatibility and avoid potential issues in the future, I still recommend setting the flag to true in your Pi configuration.

[kdejaeger]

Hopefully this get's fixed soon. Same issue for v4-flash off course. Fix seems easy for an experience pi dev.

[ACAne0320]

I reproduced this against OpenRouter DeepSeek V4 Flash:

./pi-test.sh --provider openrouter --model "deepseek/deepseek-v4-flash" --thinking xhigh -p "Say exactly: ok"

On current main, it fails with:

400 reasoning_effort: Invalid option: expected one of "xhigh"|"high"|"medium"|"low"|"minimal"|"none"

I think the issue is that pi is applying the direct DeepSeek reasoning metadata to the OpenRouter model. For OpenRouter, xhigh should stay as xhigh and go through its unified reasoning interface; OpenRouter then handles the provider-specific conversion internally. So applying thinkingFormat: "deepseek" and mapping xhigh -> max on the pi side makes the request invalid for OpenRouter.
OpenRouter reasoning docs: https://openrouter.ai/docs/guides/best-practices/reasoning-tokens

I have a minimal fix here: ACAne0320@edbf875
With the fix, the same real OpenRouter test returns ok, and npm run check passes locally.

Per CONTRIBUTING.md, could a maintainer confirm whether it is OK for me to open a PR for this? @badlogic

[badlogic]

Fixed in generated model metadata.

OpenRouter DeepSeek V4 no longer gets the direct DeepSeek thinkingFormat, so xhigh is sent through OpenRouter as xhigh. Direct DeepSeek still maps xhigh to max.

npm run check passes.

This comment is AI-generated by /wr