[BUG] experimental-auto-review sends a hardcoded temperature: 0 and disables every tool call on models that only accept temperature=1

[nyaachen]

Summary

When @deepseek-ai/dsh-experimental-auto-review is composed and the Session's model rejects any temperature other than 1, the reviewer request fails with HTTP 400 and the pre-tool gate then denies every tool call. The gate fails closed, so the Session cannot execute any tool at all.

Environment

• dsh 0.2.1-rc.3; the same code is present on master today
• Windows x64, Node 24
• Route: an OpenAI-compatible provider whose model only accepts temperature=1.
• Example： Kimi Code Kimi K3

Steps to reproduce

1. Compose the auto-review package into a deployment (packages/experimental/auto-review/cordis.patch.yml).
2. Use a Session whose model rejects temperature != 1.
3. Invoke any reviewed tool, e.g. glob.

Actual result

The tool body never runs. The call is denied with:

auto-review: reviewer ended with error INVALID_REQUEST: 400: {"message":"invalid temperature: only 1 is allowed for this model","type":"invalid_request_error"}

Expected result

A reviewer request that the deployment's model cannot serve should not deny every tool call. The review should be sent with parameters the route supports (or the reviewer route should be configurable), and an infrastructure failure should be distinguishable from an actual review denial.

Root cause

The reviewer reuses the Session's route and hardcodes temperature: 0:

• packages/experimental/auto-review/src/index.ts:675-680 — GenerateOptions built with provider: snapshot.provider, model: snapshot.model and temperature: 0
• packages/experimental/auto-review/src/index.ts:647 — throw new Error(...reviewer ended with ${chunk.reason.kind} ${code}: ${message})
• packages/llm/llm-deepseek/src/serialize.ts:158 — the adapter forwards temperature whenever it is defined; the OpenAI-compatible/DeepSeek routes have no capability gate for it. llm-pi-ai has supportsTemperature (packages/llm/llm-pi-ai/src/catalog.ts:452), but that notion does not exist for the other providers.

So the reviewer inherits the session model and unconditionally narrows its sampling parameter.

Suggested fix

Any of these resolves it:

1. Omit temperature from the reviewer request — the route's default applies. Smallest change; reviewer determinism was never guaranteed anyway.
2. Make it a validated Config field (temperature?: number, omitted by default) so a deployment can opt into 0 when its model accepts it.
3. Gate the field on a per-route capability like pi-ai's supportsTemperature, and omit it when unsupported.

Additional context

Because the gate is fail-closed and the error is surfaced to the model as Auto review rejected tool "<name>"; its body was not executed, the model cannot tell a reviewer configuration incompatibility from a genuine denial — the session just silently stops working. Reporting the reviewer failure kind separately (e.g. as an error result rather than a denial) would make this class of misconfiguration diagnosable.

[argszero]

The diagnosis is right, and it is worth being precise about the shape of the failure, because it decides where the gap can be closed.

Why it fails closed rather than loudly. packages/experimental/auto-review/src/index.ts:675-681 builds one deep-frozen GenerateOptions with temperature: 0 and hands it to ctx.llm.stream() at :683. A route that accepts only temperature: 1 answers HTTP 400, the reviewer stream ends in error, readDecision throws at :647, and the pre-tool gate — whose whole job is to fail closed — then denies every tool call. The denial carries the same sentence a genuine review rejection produces, so a misconfigured reviewer is indistinguishable from "the reviewer said no". The session stops working and nothing on screen says why.

Where a plugin can reach it. The llm/stream waterfall sees the reviewer request and can identify it, but it cannot change it: next() takes no arguments and the options object is frozen at the call site. So the request has to be fixed one step earlier, at LlmRuntime.stream (packages/llm/llm/src/index.ts:1166), which is where a plugin can intercept it. That is what I built.

What I built. @argszero/dsh-auto-review-temperature-guard 0.1.0 shadows LlmRuntime.stream on the service instance, and when — and only when — the request is the reviewer's, it substitutes a request whose temperature is either omitted (the route's own default applies) or set to a configured value. Every other request is passed through as the same object.

The reviewer request is recognised by the marker the harness's own test fixture uses: system begins with REVIEW_POLICY (packages/experimental/auto-review/tests/fixtures/headless-reviewer.ts:20). An ordinary turn leaves system undefined, so no conversation request can match. I checked that the harness sets no purpose on this call (GenerateOptions.purpose is 'compaction' | 'session-title' only), so that field cannot be used to identify it — the policy marker is the discriminator that exists.

Install (the package is not on the registry — npm view is a 404 — so the git spec is the only honest line):

dsh plugin --profile <profile> add github:argszero/dsh-auto-review-temperature-guard#v0.1.0

Mount entry, after install: - id: auto-review-temperature-guard / name: '@argszero/dsh-auto-review-temperature-guard'. Setting temperature in that entry sends a specific value instead of omitting the field.

Measured, and against what. All of this was read against the published @deepseek-ai/dsh-llm@0.2.1-rc.3, not against the source tree, and the control arm reproduces your failure on that artifact: with the guard absent the reviewer request goes out with temperature: 0. 15 arms, green, including one that asserts a non-reviewer request is passed through untouched. The git install itself was verified end to end — dsh plugin add exits 0, the installed copy carries lib/index.js, and the entry appears in --dump-config.

Your install note. experimental-auto-review is published at 0.2.1-rc.3, but its latest dist-tag still points at 0.1.6-alpha.1 — an older build, without this code path. Pin the version when you install it, or you may reproduce a different problem than the one you reported.

What this does not do. It rewrites the request on the way to the adapter; it does not change auto-review's source, so the hardcoded value is still there and the guard is the thing standing between it and the route. And it matches on the policy marker, so if a future build changes that marker the guard stops matching and the failure silently returns — it fails open, not loud.

On the upstream fix. Issues and pull requests are disabled on this repository, so I cannot offer a core patch here — a measured statement about the channel, not a deflection. If one were possible it is small: either drop temperature from that options block at index.ts:680 and let each route's default apply, or derive the value from the model's accepted range the way the rest of the request is derived. Either one makes the plugin unnecessary.

So: this closes the failure you hit, in plugin form, today. It is a mitigation and not a fix in the core, and I would rather say that than let the install line imply otherwise.