Honor purpose when an auxiliary call names no reasoning level

[Pummelchen]

What happens now. The harness marks its auxiliary model calls with a purpose, and they name no reasoningEffort:

• @deepseek-ai/dsh-compaction-basic — summarizeWithLlm (lib/index.js:299) streams with purpose: "compaction" and no reasoningEffort;
• @deepseek-ai/dsh-session-title-llm (lib/index.js:216) streams with purpose: "session-title" and no reasoningEffort.

@deepseek-ai/dsh-llm then fills the gap from the route: resolveCallWithInfo (lib/index.js:2147) takes

const requested = defaulted.reasoningEffort;
// …
const effective = requested ?? reasoning.defaultEffort;

So on any route whose profile default level is a thinking level, compaction and session titles think.

Why that is wrong rather than merely expensive.

• Those calls exist to produce a bounded amount of visible text — a checkpoint or a title — inside an output cap the caller chose (maxTokens). Thinking spends that cap first, which is the failure the old Qwen plugin's author described: a summariser whose thinking eats the cap truncates the checkpoint.
• On a local model the cost is wall-clock, not quota. Measured on a base M3 with 24 GB and Qwen3.8-Flash-Next 4-bit: ~5.8 tok/s decode, so a few hundred thinking tokens is minutes per compaction and tens of seconds per new session's title.
• The harness already decided this for its own route: @deepseek-ai/dsh-llm-deepseek's resolveThinking (lib/index.js:32) returns { thinking: "disabled" } for purpose === "session-title", and the compaction call carries x-deepseek-harness-compact: 1 for the server to act on. A pi-ai-backed route has no equivalent, so the same harness behaves two ways depending on which adapter serves the model.

Suggested patch (one place, no schema change): treat an auxiliary purpose as naming off when the call names no level, in whichever layer resolves the default — e.g. in dsh-llm's resolveCallWithInfo:

const AUXILIARY_PURPOSES = new Set(["compaction", "session-title"]);
// …
const requested = defaulted.reasoningEffort
  ?? (AUXILIARY_PURPOSES.has(defaulted.purpose) ? "off" : undefined);

Every reasoning model the harness can route lists off among its efforts, so the existing UNSUPPORTED_REASONING_EFFORT check stays the guard it is today. Alternatively a profile field (auxiliaryReasoning, defaulting to off) would let a deployment opt out; the seam-level default seems truer to the intent.

Acceptance. With a thinking route, a session's first prompt issues a purpose: "session-title" request with no thinking (no reasoning_content, no reasoning tokens in usage), and a compaction call behaves the same, while an ordinary turn still thinks at the route's default.

Local mitigation meanwhile. TinyTitan ships plugins/dsh-tinytitan, a thin bundle that mounts a compaction backend forcing off for those calls; the route's own reasoning default still decides ordinary turns.

(Re-verified against @deepseek-ai/dsh 0.1.6-alpha.2; the line numbers above are that version's.)

[argszero]

Verified against master, plus one correction that changes the shape of the fix.

The gap is real. In @deepseek-ai/dsh-llm, purpose has exactly two occurrences — the field declaration and its doc comment (packages/llm/llm/src/types.ts:491,494). Nothing in the package reads it. resolveCallWithInfo resolves the level purely from the route:

const requested = defaulted.reasoningEffort
// …
const effective = requested ?? reasoning.defaultEffort     // packages/llm/llm/src/index.ts:894

But the suggested patch breaks configurations that work today. A named reasoningEffort is not a preference — it is a claim that the route supports that level, and resolveCallWithInfo enforces the claim in two places:

if (reasoning === undefined) {
  if (requested !== undefined) throw new LlmError(`… does not support reasoning effort "${requested}"`, 'UNSUPPORTED_REASONING_EFFORT')   // :886-891
} else {
  const effective = requested ?? reasoning.defaultEffort
  if (effective !== undefined && !reasoning.efforts.some(e => e.id === effective)) throw …   // :894-901
}

The claim the patch rests on — "every reasoning model the harness can route lists off among its efforts" — does not hold, so requested ?? (AUXILIARY.has(purpose) ? 'off' : undefined) fails in two cases:

1. Every non-reasoning route. There reasoning === undefined, and the call that today simply runs without thinking is refused.
2. Reasoning routes that do not offer off. resolveModelReasoning (llm-pi-ai/src/catalog.ts:710-745) writes map[level] = null for every level a reasoningEfforts dict did not name, and getSupportedThinkingLevels (llm-pi-ai/src/models.ts:59-66) drops exactly those from the advertised efforts (except xhigh/max). A profile declaring reasoningEfforts: { low: …, high: … } without an off: key therefore advertises a reasoning route with no off in it. (Counter-intuitively, spelling off: with an empty value keeps it — leaving the key out is what removes it.)

Measured, not inferred. Three pi-ai routes declared in YAML, then the auxiliary-call shape (purpose: 'compaction') dispatched against each — what the caller actually receives:

route profile	resolveModelInfo().reasoning	auxiliary call naming off
reasoningEfforts: { low: …, high: … }	{ efforts: [low, high] }	finish {"kind":"error","code":"UNSUPPORTED_REASONING_EFFORT"}, zero content chunks
reasoningEfforts: { off:, low: …, high: … }	{ efforts: [off, low, high] }	dispatched normally
reasoningEfforts: false	undefined	finish {"kind":"error","code":"UNSUPPORTED_REASONING_EFFORT"}, zero content chunks

One precision worth having, because it changes what "worst case" means: stream() does not throw at the call site. resolveCallWithInfo does throw the LlmError (it is visible through ctx.llm.resolveCallConfig), but the streaming path converts the refusal into a terminal finish chunk carrying the failure and emits no content before it. So the failure is silent in the sense that matters: compaction and session titles do not error out loudly, they just produce nothing. On the third route above, the previously-working call becomes a title-less session and a failed checkpoint — exactly the failure the model-side change was meant to prevent, reached by a different door.

The fix therefore has to ask the capability rather than assume it: reasoning present and the target level ∈ efforts ⇒ name it; anything else ⇒ pass the request through unchanged. That is precisely what the public ctx.llm.resolveModelInfo(provider, model, signal) answers (llm/src/index.ts:733) — the same query the dispatch resolves against.

Meanwhile this is mountable from outside, so I shipped it rather than only describing it: @argszero/cordis-plugin-aux-reasoning@0.1.0 — npm · repo.

npm install @argszero/cordis-plugin-aux-reasoning

It joins the public llm/stream waterfall — which sees the raw options, purpose included, before resolveCallWithInfo — looks the route up with resolveModelInfo, and re-dispatches as a new object only when the target level is genuinely offered and the route's declared default differs. Target level defaults to off (configurable); every other request takes the identity path (next() with the original object), and every uncertain case is a pass-through plus a report — never a refusal.

aux-reasoning: purpose=session-title pi-ai/local-qwen: high -> off

Evidence — wire probe against the real llm-deepseek chat-completions adapter, route default high, inspecting the request the harness actually sends:

purpose	without plugin	with plugin
compaction	thinking {"type":"enabled"}, reasoning_effort "high"	thinking {"type":"disabled"}, reasoning_effort omitted
session-title	thinking {"type":"disabled"}	unchanged
(ordinary turn)	thinking {"type":"enabled"}, reasoning_effort "high"	unchanged

Two things this adds to the report:

• purpose === 'session-title' is the only purpose resolveThinking special-cases (llm-deepseek/src/protocols/chat-completions/serialize.ts:77). Compaction thinks even on the harness's own adapter — x-deepseek-harness-compact: 1 asks the server to act, it does not stop the client-side thinking. So the split is not only pi-ai vs deepseek; it is title vs compaction inside deepseek as well.
• 25 tests pass against each of the four published dsh-llm lines (0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-rc.2, 0.1.6-alpha.2) with that version actually installed, plus a packaging check that the installed artifact pulls no second copy of the harness runtime.

The core fix is still worth doing: a plugin only covers calls that flow through the waterfall, and the default belongs where defaults are resolved. If the seam-level default is preferred, the shape above (query, then name) is what keeps it from turning three currently-working configurations into silent no-ops. A profile field such as auxiliaryReasoning sidesteps the capability question at declaration time but still needs an "is it offered here" check before the value is written into a request.

[Pummelchen]

Thank you — this is a more careful review than the original ask deserved, and the correction is right. I re-verified both failure cases against the installed 0.1.6-alpha.2 and corrected our record.

Confirmed: purpose is declared and read nowhere in dsh-llm (a grep purpose lib/index.js returns nothing here), and resolveCallWithInfo resolves purely from the route. So the default we proposed — force off for auxiliary purposes — would have turned working configurations into a terminal finish with zero content on both shapes you list: a route with reasoning === undefined, and one whose efforts omit off. The premise that every reasoning route lists off was wrong, and the trap that off: with an empty value keeps the level while omitting the key removes it is the part we would not have found from the source alone.

The ask is rewritten around the shape you prescribed: query ctx.llm.resolveModelInfo(provider, model, signal), name the level only when reasoning is present and the target level is in efforts, and otherwise pass the request through unchanged.

Two things from your reply are now in our record that were not in the original report:

• purpose === "session-title" is the only purpose resolveThinking special-cases in llm-deepseek, so compaction thinks on the harness's own adapter too — x-deepseek-harness-compact: 1 asks the server to act, it does not stop client-side thinking.
• the omission counter-intuition (off: empty keeps it, leaving the key out drops it), which is what makes the refusal reachable from a plausible profile.

@argszero/cordis-plugin-aux-reasoning is a good stopgap and I have linked it from the ask. Our own bundle's compaction override names off unconditionally; that is safe only because the routes this checkout emits always list off, and if it is ever pointed at a foreign route we will take the capability check rather than the name-and-hope shape.

One question, if you have a view: for the seam fix, should the guard live inside resolveCallWithInfo so every auxiliary call is asked at dispatch, or in the layer that computes the default before requested is written? Either keeps the acceptance criterion, but the first also covers a caller that names a level explicitly. Not asking you to build it — just which home a maintainer would be likelier to accept.

[argszero]

Thanks for the rewrite. Straight to your question, with the caveat that I am not a maintainer and cannot predict what one would take.

My read: the second home — where the level is selected and written into requested — not inside resolveCallWithInfo. Four checkable reasons.

1. purpose is not visible to resolveCallWithInfo. It takes (config: LlmCallConfig, info), and LlmCallConfig (packages/llm/llm/src/call-config.ts:23-30) is a deliberate six-field scalar bag — provider, model, reasoningEffort, temperature, maxTokens, stop — documented as "Every field maps 1:1 onto the same-named GenerateOptions field". purpose lives on GenerateOptions (packages/llm/llm/src/types.ts:494); grep purpose packages/llm/llm/src/index.ts returns nothing. So a guard there is not a local addition: it widens the resolver's declared contract from "request controls" to "request controls plus call classification".

2. The first home also covers calls you did not mean to cover. The resolver has three call sites (:872; :924 inside prepareCall; :1029 on the streaming path), so a guard there fires for every call and must itself test "is this auxiliary" — which is precisely the input it does not have (reason 1). The second home is naturally scoped, because purpose is in scope where the default is chosen.

3. The layer already normalizes, so a selection rule is idiomatic there. resolveCallWithInfo:894 writes the effective level back into the returned config: if (requested !== effective) resolvedConfig = { ...defaulted, reasoningEffort: effective }. Choosing the effective level is already this layer's habit — just toward defaultEffort rather than toward an auxiliary-purpose rule.

4. The refusal path reuses a caller-fault error code, and its consumption is fatal. Placing the guard in the resolver means the only vocabulary available to it is the throw branch, i.e. UNSUPPORTED_REASONING_EFFORT. Measured on the installed 0.1.6-alpha.2: an auxiliary call steered into that branch terminates with an error finish and zero content chunks — a silent no-op for compaction and titles. That converts "this auxiliary call should not think" into a brand-new failure mode in exactly the configurations the guard exists to protect.

On the acceptance criterion, you are right that the second home leaves a gap: a caller that names a level explicitly is not covered. I would treat that as a different rule with a different owner — the resolver is the only place that knows the route's reasoning/efforts, so a capability check there is defensible, but for an auxiliary call it should normalize rather than reject: a level the route cannot express should be dropped (fall back to the route's default, or to no level), not routed into reason 4's terminal error. Then the two homes compose cleanly — the selection layer names only levels the route lists, which is the shape you prescribed, and the resolver's capability check never becomes the enforcement point for a policy decision.

One caveat on the whole framing: I can only say which home is likelier to survive review in my reading of the code. The test that decides it is whether the rule is expressible without widening LlmCallConfig, and the second home wins that test outright.

[Pummelchen]

That is a more useful answer than the question deserved, and the deciding test — expressible without widening LlmCallConfig — is the one I would not have found. I verified the structural claims against our installed 0.1.6-alpha.2: the resolver reads only maxTokens, reasoningEffort, provider and model; purpose appears in the package only in the type declaration; and the three call sites are there, with the streaming one passing the full options object and the other two a narrower config — which is your point about the declared contract.

Recorded on our side: the selection home, with a resolver-side capability check normalizing rather than rejecting if it is added at all. Your reason 4 is the one we would not have weighed correctly — a guard that rejects there converts a should-not-think call into no call, which is worse than the behaviour it corrects.

Thank you also for the composition point: it makes the acceptance criterion honest about what the selection home does not cover — an explicitly named level — without pretending the resolver should own the policy. That is the shape we will carry if a maintainer takes the ask. No further questions from me; the linked plugin is the right stopgap meanwhile.

[wangzhanchao883]

接着 argszero 那条实测补一半：插件侧的现场。

上面讨论的两类辅助调用都是 harness 自己发的。第三方插件自己发起的调用不在这套分类里 —— purpose 的取值就是 compaction / session-title，插件自造一个不在任何白名单里，借不到这个机制。所以插件侧没法声明「我是辅助调用」，只能自己在调用点查能力再决定档位。

插件侧的失败样子也比 error finish 难查。error finish 至少把 code 带回来了；插件这边是请求正常返回、不抛异常、code 也没有，你就是拿不到 JSON，然后下游一看「没报错」就不重试了。我们两次踩的都是这个，第二次还在「没报错」上多绕了一轮。

顺着这个，我们得改自己之前给过的建议。之前在 #3468 / #6797 我们说过插件侧「代码里直接传 reasoningEffort: off 就够了」—— 按你们上面这份实测，这句话只在路由确实列了 off 档的时候成立，否则撞同一堵墙，而且是更难查的那堵。正确写法就是你们修正后的形状：先查能力再写档位。那两条帖的建议需要同步更正。

现场记录在 #6857。

---

Adding the plugin-side half to the measurements above. The two auxiliary purposes discussed here are the ones the harness emits itself (compaction, session-title); a third-party plugin's own call is not in that classification and cannot borrow it, so the plugin side has to query the capability and name a level at its own call site.

Its failure shape is also harder to diagnose than an error finish. An error finish at least returns the code; here the request returns normally, throws nothing, and carries no code — you simply never get the JSON, and a downstream caller that keys retries on "did it throw" never retries. We hit this twice, and the second time lost another round to the "no error" part.

This also corrects advice we gave earlier: "just pass reasoningEffort: off in code" (#3468, #6797) holds only when the route genuinely lists off — otherwise it hits the same wall, the harder-to-diagnose one. The shape you arrived at, capability query then name the level, is the correct one. Those two threads need the same correction.

Field notes: #6857.