Allow users to configure Thinking levels

Problem or Motivation

The Thinking picker currently always presents the full built-in set of levels:

• No Thinking
• Low
• Medium
• High
• Extra High
• Max

Each option also includes an explanatory subtitle. These descriptions are useful when first discovering the feature, but once the levels are familiar they add considerable vertical space and make the picker slower to scan.

Not every level is useful to every user. In my case, I regularly use only Low, Medium, High, and Extra High. I would like to hide the other levels and remove the subtitles while keeping the underlying reasoning behavior unchanged.

This would make the Thinking picker more compact and let users adapt it to their workflow without requiring unsupported local changes to the application.

Proposed Solution

Add a persisted JSON configuration for the Thinking level entries exposed in the UI. Each entry would reference one of the existing, fixed runtime IDs and define its presentation.

For example, my preferred configuration would be:

{
  "thinkingLevels": [
    {
      "id": "low",
      "name": "Low"
    },
    {
      "id": "medium",
      "name": "Medium"
    },
    {
      "id": "high",
      "name": "High"
    },
    {
      "id": "xhigh",
      "name": "Extra High"
    }
  ]
}

A user who wants custom descriptions could provide them per entry:

{
  "thinkingLevels": [
    {
      "id": "low",
      "name": "Low",
      "description": "Quick tasks"
    },
    {
      "id": "medium",
      "name": "Medium",
      "description": "Everyday default"
    },
    {
      "id": "high",
      "name": "High",
      "description": "Complex analysis"
    },
    {
      "id": "xhigh",
      "name": "Extra High",
      "description": "Long-running agentic work"
    }
  ]
}

Expected behavior

• id must be one of the existing runtime levels: off, low, medium, high, xhigh, or max.
• The order of entries controls their display order.
• Omitting an entry hides that level from interactive selectors.
• name controls the displayed label.
• An omitted, empty, or whitespace-only description renders no subtitle and reserves no subtitle spacing.
• Custom presentation does not change reasoning effort, token budgets, provider behavior, or model compatibility behavior.
• If no custom configuration exists, the current built-in list, localized labels, descriptions, and order remain unchanged.
• Invalid or duplicate IDs, missing names, and an empty effective list are handled safely with actionable validation feedback or a documented fallback.

Hidden current level

If the currently selected level is omitted, automatically select the closest visible level according to the existing order:

off < low < medium < high < xhigh < max

If two visible levels are equally close, prefer the lower level to avoid silently increasing reasoning effort, latency, or cost.

Examples:

• off hidden, low visible → low
• max hidden, xhigh visible → xhigh
• medium hidden while low and high are visible → low

Legacy think values should continue to normalize to medium before visibility resolution. The workspace global option should continue to inherit the application default rather than being treated as a Thinking level.

Scope

The resolved entries should be used consistently in:

• The standard chat-input picker
• The compact chat-input picker
• The application-level default Thinking selector in Settings → AI
• The workspace Thinking override selector in Settings → AI

Acceptance criteria

• With no custom configuration, the current behavior remains unchanged.
• Configuring low, medium, high, and xhigh shows exactly those four options in all interactive Thinking selectors.
• An omitted, empty, or whitespace-only description renders no subtitle or empty subtitle spacing.
• Custom names and non-empty descriptions are displayed for their entries.
• Unsupported IDs, duplicate IDs, missing names, and an empty effective list are handled safely.
• A hidden or invalid selected level resolves to the closest visible level, with ties going to the lower level.
• Legacy think values still normalize to medium before visibility resolution.
• Application defaults and workspace overrides remain valid when a previously selected level is hidden.
• Runtime reasoning semantics remain unchanged.

Alternatives Considered

I tried modifying the installed renderer locally. This can produce the desired interface, but the change is unsupported, fragile, and overwritten by application updates. A persisted configuration would provide the same customization safely.

Additional Context

The requested configuration is intended to customize presentation only. It should not create new Thinking levels or redefine the behavior of the existing levels.

The proposed entry shape follows the same general user-facing pattern as configurable model entries: a stable technical id is kept separate from its displayed name and optional description.