Expose reasoning effort metadata in GET /models

[miaomiaoyaoqimiaomaoxian]

Hi DeepSeek team,

First, thanks for the V4 family — the low / high / max effort ladder is genuinely useful for agent workloads.

Background

We maintain an agent harness (HanaAgent) that supports multiple providers. To render a correct "reasoning effort" selector per model, we need to know which effort values each model accepts.

Today, GET /models returns only:

{
  "id": "deepseek-v4-pro",
  "object": "model",
  "owned_by": "deepseek"
}

There is no reasoning metadata, so clients must hard-code a mapping table keyed by model id. That breaks in two ways:

1. New models require a client release. When you ship something like deepseek-v4.1-flash-expires-on-0910, existing clients show a wrong or empty effort list until they hard-code the new id.
2. Probing is impossible. Unsupported reasoning_effort values are silently ignored rather than rejected, so a client cannot discover the supported set by trial and error.

Request

Please expose the supported effort ladder in the model list (or a model-detail endpoint). A shape consistent with what other providers already do would be ideal:

{
  "id": "deepseek-v4-pro",
  "object": "model",
  "owned_by": "deepseek",
  "reasoning_efforts": {
    "support": true,
    "valid_efforts": ["low", "high", "max"],
    "default_effort": "high"
  }
}

Field semantics we would consume:

Field	Meaning
support	whether the model supports effort control at all
valid_efforts	the exact accepted enum, in ascending strength order
default_effort	what the server uses when the parameter is omitted

Prior art

• Moonshot already returns this on GET /v1/models:

  "think_efforts": { "support": true, "valid_efforts": ["low","high","max"], "default_effort": "max" }

• OpenRouter returns it on GET /api/v1/models:

  "reasoning": { "mandatory": false, "default_enabled": true, "supported_efforts": ["high","medium","low","none"], "default_effort": "medium" }

Secondary ask

Consider returning HTTP 400 for unsupported effort values instead of silently ignoring them. Silent coercion makes client bugs invisible; an explicit error surfaces them at integration time.

Thanks for considering.