Feature Request: Custom Thinking Levels per Model

[ghost91-]

What do you want to change?

Allow models to define their own thinking levels in models.json, so Shift+Tab only cycles through levels the model actually supports. The extension API should support this via pi.registerProvider() as well. I'd like to implement this myself once the approach is decided.

Related: #3016. That issue describes the broader problem well. This issue focuses on a specific, actionable proposal.

Why?

I'm working with a custom OpenAI-compatible provider whose models support only specific reasoning_effort values (e.g., ["none", "medium"]). The provider defaults to thinking ON when the parameter isn't sent, which clashes with pi's "thinking off" display that omits the parameter entirely. Users see "off" but get thinking enabled on the backend.

The provider exposes a custom /info endpoint with model metadata, including supported_reasoning_effort per model. I'd like to build an extension that auto-discovers these models and configures thinking levels correctly, but extensions can't define custom levels today.

Current workarounds are insufficient:

• reasoningEffortMap maps pi levels to provider values, but all 6 levels still appear in the UI
• before_provider_request can inject reasoning_effort, but can't change which levels are selectable
• Mapping 6 levels down to 2 works-ish but confuses users

How? (optional)

Add a way to define custom thinking levels per model. A few options:

Option 1: New thinkingLevels field - levels appear in UI and are sent directly to API. Simple, but no mapping for non-standard level names.

{ "id": "model-a", "thinkingLevels": ["none", "medium"] }

Option 2: reasoningEffortMap keys define visible levels - single field for both UI and mapping. Only mapped keys are selectable. Optional: null as value omits reasoning_effort for that level. Risk: changes semantics for existing configs that only map a subset.

{ "id": "model-a", "reasoningEffortMap": { "off": "none", "medium": "medium" } }

Option 3: Both fields together - separate control over UI and mapping. Useful for non-standard level names, but more verbose.

{ "id": "model-a", "thinkingLevels": ["off", "high"], "reasoningEffortMap": { "off": "disabled", "high": "turbo" } }

All options need to handle the "thinking off" case: either disable the special "off" behavior when custom levels are set, or add a defaultThinkingLevel field. Key requirement: backward compatibility.

[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.

[mindplay-dk]

option 1 doesn't contain all the information needed, if you want to be able to map a default setting to a model option.

option 3 repeats the thinking levels that are defined in the reasoning effort map - this would lead to parity errors.

so option 2 seems better, I think.

Risk: changes semantics for existing configs that only map a subset.

how so?

for my understanding, in terms of types, the existing type:

https://github.com/badlogic/pi-mono/blob/f2c0489197cf48a703c0762a11e2499003c416f7/packages/ai/src/types.ts#L45

would need an added mode "none", I think? (since null or undefined doesn't work in maps)

type ThinkingLevel = "none" | "minimal" | "low" | "medium" | "high" | "xhigh"; // Pi's levels

type ThinkingLevelMap = Partial<Record<ThinkingLevel , string>>; // provider's thinking levels

is that correct?

you can then do e.g. const levels = { none:0, minimal:1, low:2, medium:3, high:4, xhigh:5 } for easy numeric comparisons, e.g. automatically picking the next higher (probably?) level available for a given model based on the default setting.

(note that this model could be lossy, as it constrains the model to a maximum of 6 levels. I don't know why a model would have more than 6 reasoning levels, so probably not a real problem in practice...)

[ghost91-]

Risk: changes semantics for existing configs that only map a subset.

how so?

In the current implementation, if you specify reasoningEffortMap but do not list all levels there, the unlisted levels are unchanged. With option 2, they would instead be removed, which is a change in behavior.

for my understanding, in terms of types, the existing type:

pi-mono/packages/ai/src/types.ts

Line 45 in f2c0489
export type ThinkingLevel = "minimal" | "low" | "medium" | "high" | "xhigh";

would need an added mode "none", I think? (since null or undefined doesn't work in maps)

type ThinkingLevel = "none" | "minimal" | "low" | "medium" | "high" | "xhigh"; // Pi's levels

type ThinkingLevelMap = Partial<Record<ThinkingLevel , string>>; // provider's thinking levels

is that correct?

To be honest, this type becomes kind of irrelevant, since it will be arbitrary strings, both for the keys and the values. That's the point here. Of course, there could still be an internal enum or so for the known common levels.

[pyfisch]

This feature is particularly relevant to the Pi user experience when using open-weights models. None of the models I am using right now support thinking levels in the way Pi expects. While I have written a custom provider that calls these models correctly, I can't fix the user interface with an extension.

• gemma4-31B-it: thinking is either on or off
• Qwen3.5-35B-A3B: thinking is either on or off
• gpt-oss-120b: reasoning effort is one of low, medium, high, you can't switch off reasoning
• NVIDIA-Nemotron-3-Super: thinking is either off, "low-effort" or on

I spent more time tinkering with reasoning levels on models that don't support them (or were misconfigured) than I'd like to admit. Colleagues are interested in Pi, however I am not looking forward to explaining them that you can toggle between five thinking levels for Qwen 3.5, yet everything between "minimal" and "high" is the same.

[mindplay-dk]

I am not looking forward to explaining them that you can toggle between five thinking levels for Qwen 3.5, yet everything between "minimal" and "high" is the same.

I'm not completely sure I understand what's being proposed, but yeah, that does not sound like the right way to do it.

What I pictured is, the built-in levels could be used to specify a default level, perhaps for different modes etc. - and that the default level would be used to select e.g. the model equivalent or next higher available mode.

I do not think built-in thinking levels should replace or hide model specific modes - when I'm picking the thinking mode for a specific model, I want to see the modes available for that model, with the names that are specific to that model.

The built-in levels shouldn't abstract away the models native levels - it should be used in situations where you can't or don't want to use model specific modes, I think.

An enhancement, not a replacement.

[pyfisch]

I am not looking forward to explaining them that you can toggle between five thinking levels for Qwen 3.5, yet everything between "minimal" and "high" is the same.

I'm not completely sure I understand what's being proposed, but yeah, that does not sound like the right way to do it.

I propose that Pi only shows the levels a model actually supports. If a model only has thinking on/off, there are two levels and the choice between them is meaningful, unlike right now when multiple levels in the user interface all map to thinking on.
Personally I don't care about the names of the different thinking levels for each model, it's fine when Pi abstracts over them.
(This is what ghost91 proposes in options 2 and 3.)

As an aside: The Qwen3 technical report section 4.3 describes the thinking budget: a </think> token is inserted after a predetermined number of tokens has passed. This allows users to limit thinking and interrupt thinking loops. Recent versions of llama.cpp have a parameter thinking_budget_tokens for this purpose. I will experiment with mapping the Pi thinking levels to different thinking budgets for Qwen 3.x models.

[badlogic]

fyi: gpt-5-mini via the OpenAI Responses API no longer accepts reasoning.effort: "none".

it now only accepts minimal|low|medium|high. this showed up in e2e because the default non-thinking path was sending none and getting a 400 back.