llm-pi-ai: 希望能支持每个model设置独立的effort

[ColorFuzzy]

使用场景, 接入了litellm之后, 希望不同的模型使用不同的effort:

• haiku使用high
• gpt-6-astra使用medium
• opus-5.5-xhigh使用xhigh

现在是使用多个providers绕过去的, 选择模型菜单不是很干净, 如下:

- id: llm-pi-ai
  name: "@deepseek-ai/dsh-llm-pi-ai"
  config:
    providers:
      litellm-anthropic-opus-5-5:
        displayName: LiteLLM · Opus 5.5
        apiKeyEnv: LITELLM_ANTHROPIC_API_KEY
        api: anthropic-messages
        baseURL: https://test-ai-gateway.xxx.biz:4000
        reasoning: xhigh
        compat:
          forceAdaptiveThinking: true
          supportsTemperature: false
        models:
          - id: claude-opus-5-5
            name: claude-opus-5-5
            contextWindow: 1000000
            reasoningEfforts:
              "off":
              low: low
              medium: medium
              high: high
              xhigh: xhigh
              max: max
      litellm-openai-gpt-6-astra:
        displayName: LiteLLM · GPT-6 Astra
        apiKeyEnv: LITELLM_OPENAI_API_KEY
        api: openai-responses
        baseURL: https://test-ai-gateway.xxx.biz:4000/v1
        reasoning: medium
        models:
          - id: gpt-6-astra
            name: gpt-6-astra
            contextWindow: 920000
            reasoningEfforts:
              "off": none
              low: low
              medium: medium
              high: high
              xhigh: xhigh
              max: max
      litellm-openai-grok-4-7:
        displayName: LiteLLM · Grok 4.7
        apiKeyEnv: LITELLM_OPENAI_API_KEY
        api: openai-responses
        baseURL: https://test-ai-gateway.xxx.biz:4000/v1
        reasoning: high
        models:
          - id: grok-4.7
            name: grok-4.7
            contextWindow: 500000
            reasoningEfforts:
              low: low
              medium: medium
              high: high
              xhigh: xhigh

[argszero]

You do not have to split the providers to get this — the per-request effort is a field the plugin layer can set, and the missing piece is narrower than it looks.

Where the effort actually comes from today

For an installed pi-ai profile the default is resolved per dispatch as options.reasoningEffort ?? profile.reasoning (packages/llm/llm-pi-ai/src/adapter.ts:366) — that is, from the profile, which is why your workaround is one provider block per default. models[].reasoningEfforts is a different thing: it is the menu of nameable levels and their wire spellings, not a default.

The session-selection layer already handles the explicit case: installModelSelection (packages/core/agent/src/model-selection.ts:88-110) writes the selected model's effort into the request config on the agent/request waterfall, and — this is the part worth knowing — when the selection carries no effort it clears the inherited one, so the call falls back to the provider default. So today there are exactly two states: explicitly selected, or profile default. There is no per-model default, which is the gap you are describing.

The seam that closes it

agent/request is a waterfall whose handler returns the LlmCallConfig for the dispatched request (packages/core/agent/src/runtime-types.ts:337), and agents[].reasoningEffort is documented as a value that waterfall may override (packages/core/agent-loop/README.md:51). A listener can therefore read the resolved provider/model and set reasoningEffort per model, in one profile per gateway, with your model menu unchanged.

Two published packages already live on that seam and can be read as working references for the mechanics (provenance, ordering, and how to reach the resolved config):

• @argszero/dsh-effort-route-guard — https://github.com/argszero/dsh-effort-route-guard — hooks the outermost agent/request to clear an effort that a model switch left behind.
• @argszero/cordis-plugin-subagent-effort — https://github.com/argszero/cordis-plugin-subagent-effort — the delegated-agent face of the same field.

One honest caveat before anyone builds it: the resolved config does not say why an effort is present, so "the user explicitly picked xhigh, leave it alone" and "nobody picked, the profile default applied" look identical at that seam. Distinguishing them needs a provenance check (Agent.options or the last durable request/header) rather than a value comparison — that is the same problem dsh-effort-route-guard ran into, and the reason its guard only acts when it can prove where the value came from. I have not built the per-model map; I am naming it because the seam exists and the work is small, and because a mapping like yours (haiku→high, gpt-6-astra→medium, opus-5.5-xhigh→xhigh) is exactly what the waterfall is for.

Whether models[].reasoning should also become a first-class configuration field — so the answer lives in the profile instead of a plugin — is the maintainers' call, and the profile-level fallback above is where it would plug in.

[ColorFuzzy]

Thanks for the detailed answer. You're right that there are several ways to work around this, but being able to set it directly would make things much more convenient.