pi-model-auto-router drops target thinkingLevelMap #9

New issue

Closed

opened 2026-09-03 18:56:44 +08:00 by lengxf · 0 comments

lengxf commented

2026-09-03 18:56:44 +08:00

(Migrated from github.com)

Summary

Routed target models lose their thinkingLevelMap, so Pi reasoning levels can be forwarded unchanged even when the target model explicitly maps them to a supported provider value.

Environment

pi-model-auto-router: 0.3.1
pi: 0.84.4
Target API: openai-responses

Reproduction

Target model in models.json:

{
  "id": "GPT-5.6-Sol-joybuilder",
  "api": "openai-responses",
  "reasoning": true,
  "thinkingLevelMap": {
    "off": "none",
    "minimal": "low",
    "low": "low",
    "medium": "medium",
    "high": "high",
    "xhigh": "xhigh",
    "max": "max"
  }
}

Route that targets this model, then request the route with reasoning: "minimal" (or run):

pi --print --no-session --model model-auto-router/gpt --thinking minimal "Reply OK"

Actual behavior

The downstream request contains:

{"reasoning":{"effort":"minimal"}}

The model rejects it:

Unsupported value: 'minimal' is not supported ... Supported values are: 'none', 'low', 'medium', 'high', 'xhigh', and 'max'.

Directly selecting the target provider/model applies the mapping correctly.

Root cause

buildModel(target) copies reasoning, input, compat, context and token limits from the target model, but omits thinkingLevelMap. The downstream provider therefore receives a model without mapping metadata and falls back to the raw Pi level.

Suggested fix

Propagate the target model mapping in buildModel:

return {
  // ...
  reasoning: model?.reasoning ?? false,
  thinkingLevelMap: model?.thinkingLevelMap,
  input: model?.input ?? ["text"],
  // ...
}

A regression test should assert that a routed model with minimal: "low" sends low to the downstream provider.

## Summary Routed target models lose their `thinkingLevelMap`, so Pi reasoning levels can be forwarded unchanged even when the target model explicitly maps them to a supported provider value. This breaks models whose provider effort names differ from Pi's level names. For example, GPT-5.6 Sol rejects `minimal` and expects `none | low | medium | high | xhigh | max`. ## Environment - pi-model-auto-router: 0.3.1 - pi: 0.84.4 - Target API: `openai-responses` ## Reproduction Target model in `models.json`: ```json { "id": "GPT-5.6-Sol-joybuilder", "api": "openai-responses", "reasoning": true, "thinkingLevelMap": { "off": "none", "minimal": "low", "low": "low", "medium": "medium", "high": "high", "xhigh": "xhigh", "max": "max" } } ``` Route that targets this model, then request the route with `reasoning: "minimal"` (or run): ```bash pi --print --no-session --model model-auto-router/gpt --thinking minimal "Reply OK" ``` ## Actual behavior The downstream request contains: ```json {"reasoning":{"effort":"minimal"}} ``` The model rejects it: ```text Unsupported value: 'minimal' is not supported ... Supported values are: 'none', 'low', 'medium', 'high', 'xhigh', and 'max'. ``` Directly selecting the target provider/model applies the mapping correctly. ## Root cause `buildModel(target)` copies `reasoning`, `input`, `compat`, context and token limits from the target model, but omits `thinkingLevelMap`. The downstream provider therefore receives a model without mapping metadata and falls back to the raw Pi level. ## Suggested fix Propagate the target model mapping in `buildModel`: ```ts return { // ... reasoning: model?.reasoning ?? false, thinkingLevelMap: model?.thinkingLevelMap, input: model?.input ?? ["text"], // ... } ``` A regression test should assert that a routed model with `minimal: "low"` sends `low` to the downstream provider.

👀 1