[Bug] DeepSeek Messages 400s when a session's tool list becomes all-deferred (defer_loading)

[Thesouth-EricWang]

Summary

When an existing session's tool set changes so that every tool is "new" relative to the session's first request, @deepseek-ai/dsh-llm-deepseek sends a tools array where every entry has defer_loading: true. The Messages endpoint rejects it with 400 INVALID_REQUEST:

tools: at least one tool must have defer_loading=false. All tools cannot be deferred. (request_id: a9ab203e-9acc-4541-86a9-166f92861d11)

The session is then permanently unusable: every following request has the same shape, so retrying never helps. We hit this in 4 sessions on dsh desktop 0.2.1-rc.2 (provider deepseek-account, model deepseek-flash).

How the malformed request is produced

1. The session's first request is logged as request/header with only run_code (PTC presentation).
2. ToolHistoryProjection keeps that header as the declaration baseline.
3. Later the tool presentation changes to native. We observed three sessions resumed at the same second going from 1 to 68 tools - the PTC tool-presentation layer did not apply on that resume, so the scope fell back to native.
4. buildRequest (agent-loop) appends a developer/message with 67 tool-addition blocks and 1 tool-removal (run_code), and projectToolUpdates marks every addition deferLoading: true.
5. After filtering by active names, the original run_code is gone and the provider receives 68 tools, all defer_loading: true -> 400.

Why it is not handled today

@deepseek-ai/dsh-llm-pi-ai already handles this exact shape for anthropic-messages routes: when every tool is deferred, it prepends ANTHROPIC_TOOL_UPDATE_PLACEHOLDER (see llm-pi-ai/lib/index.js, the tools.every((tool) => tool.deferLoading === true) branch). The DeepSeek adapter's serialize() in llm-deepseek/lib/index.js has no equivalent guard, so the raw all-deferred list goes out unchanged.

Proposed fix

In llm-deepseek's request serializer: if options.tools is non-empty and every tool has deferLoading === true, prepend one non-deferred placeholder tool (name, description, empty object schema), mirroring the pi-ai adapter. A local patch doing exactly that (same byte length, injected placeholder) is what we are testing now.

Notes

• The trigger is not "switching the agent preset": presets are locked after the first turn (agent-preset/locked). The tool set changed because the presentation layer resolved differently on resume.
• Affected sessions cannot be recovered by re-sending messages or switching back; the only workarounds we found are switching the conversation to a model whose catalog entry has no toolUpdate (e.g. deepseek-v4-pro, which skips the deferred projection path) or starting a new session.

Happy to provide session-log excerpts (request/header + developer/message sequences) if useful.

[argszero]

Reproduced your diagnosis, and shipped a plugin that repairs the request in front of the dispatch — so a session that is already in this state becomes usable again without a fork of the adapter.

The shape, confirmed against the shipped code

Your step list matches projectToolUpdates in packages/llm/llm/src/content.ts exactly. Two details worth adding, because they explain why the fix has to be a placeholder rather than a filter:

• toolDeclarations() seeds the declaration set from toolHistory.tools and marks every tool-addition deferLoading: true; nothing removes a deferred entry afterwards.
• llm-deepseek declares toolUpdate: 'addition-only' (packages/llm/llm-deepseek/src/models.ts:13). That mode is the filter you observed: case 'addition-only' deletes every declaration whose name is not in options.tools. Remove the one tool that was available from the start and nothing loadable is left.

So the invariant for a route in that mode is simply: a wire entry is loadable iff its name was already declared, non-deferred, in toolHistory.tools — which is a set operation over the request, no model knowledge required.

The plugin

@argszero/dsh-all-deferred-tools-guard — https://github.com/argszero/dsh-all-deferred-tools-guard

npm install github:argszero/dsh-all-deferred-tools-guard

(Not on npm yet — the registry token on this machine is unavailable, so the git form is the honest one today. Same package name is reserved for when it lands.)

It listens on the llm/stream waterfall and re-dispatches with the identical placeholder the pi-ai adapter already uses — DeferredToolPlaceholder, same description, {type:'object',properties:{}}, not deferred. Same name on purpose: on an anthropic-messages route, pi-ai's own every(tool => tool.deferLoading === true) predicate is then false, so it adds nothing and that route receives exactly the request it would have produced anyway. Nothing is written to the session log or to disk.

Two triggers:

1. Predicted — the set operation above. Costs nothing and never touches the network, so a poisoned session is repaired on its next request.
2. Rejected — when the prediction is silent but the request is in the tool-update regime, the first chunk of the stream is inspected, and your provider message (at least one tool must have defer_loading=false / All tools cannot be deferred) triggers a re-dispatch. A refused request emits no content chunk, and INVALID_REQUEST is not retried, so the refusal arrives exactly once and starting over loses nothing.

The second trigger exists because the update mode is resolved per model inside the adapter and is not readable from the waterfall — so the prediction is an over-approximation and the provider is the backstop.

Evidence

• scripts/probe-lines.mjs calls the real projectToolUpdates from the shipped @deepseek-ai/dsh-llm, on 0.2.0-rc.2 and 0.2.1-rc.2. On both lines a request built from your report (baseline run_code, 67 additions, one removal, run_code no longer active) projects to 67 tools, every one deferred — the run you are describing — and the request this plugin builds from it projects to 68 tools with exactly one loadable.
• 38 unit tests over the predicate, the substitution and the listener (including observe mode, fail-open on a malformed request, and early consumer abort), plus 8 mutation arms that each break the built library and must turn the suite red — 8/8 caught.
• Peer ranges are asserted under both semver readings (the harness's gate uses includePrerelease: true; npm does not), because that divergence has already bitten community plugins here.

Two things it does not claim: it repairs the request, not the history — the session still holds a table where every active tool arrived as an addition, and the placeholder is what keeps the wire list legal; and a model that calls the placeholder reaches the ordinary unknown-tool path, the same trade pi-ai makes.

Your proposed upstream fix (llm-deepseek's serializer prepending a placeholder when the projected list is all-deferred) remains the right place for this — the plugin is the community-side path until then, and it also covers already-poisoned sessions, which a serializer fix does for free on the next request.

If you still have one of the four affected sessions, mounting it in observe mode first will tell you what the guard would have replaced without changing anything. Reports either way are welcome.

[argszero]

One correction to the evidence in my earlier comment, and it changes a support claim rather than the diagnosis.

I said the cross-line probe ran on 0.2.0-rc.2 and 0.2.1-rc.2, and the peer range said the same. Two lines out of the ten published versions that range admits is not evidence for the range — it is evidence for the two lines. It now installs every one of them and calls each release's own projectToolUpdates:

line	reported request projects to	repaired request projects to
0.1.7-rc.2	67 tools, all deferred	68, one loadable
0.2.0-rc.1, 0.2.0-rc.2	67, all deferred	68, one loadable
0.2.1-alpha.1 … alpha.5, rc.1, rc.2	67, all deferred	68, one loadable

10/10 — the failure you reported and the repair this plugin performs are identical on every line the plugin claims, so a reader can pick any of them and reproduce your case.

That exercise also found the range wrong in one place. The 0.2.0 segment started at rc.2 by inheritance rather than by measurement: 0.2.0-rc.1 exports projectToolUpdates, projects the same 67-tool all-deferred list, ships cordis 4.0.5, and has dsh-session's toolHistory() projection — nothing in the mechanism is missing on it. It is now admitted. The other boundary survived the same test and stayed: 0.1.7-rc.1 does not export projectToolUpdates at all, and the predicate is a reading of that function, so admitting it would be a claim with nothing underneath.

Two smaller things in the same pass, because a probe that cannot be trusted not to abort is not a probe: the script was enumerating every entry under probe/, including its own README, and died with ENOTDIR before measuring a line; and it now applies the declared peer range to each probed version under both semver readings, so a line that is measured but not declared — the exact drift above — fails instead of being documented in prose.

Same install path as before, now at the tip of main:

npm install github:argszero/dsh-all-deferred-tools-guard

Still not on npm (registry token unavailable on this machine), and the upstream sentence from my earlier comment stands unchanged: the durable fix belongs in llm-deepseek's serializer, and this plugin is the community-side path plus the recovery for sessions that are already poisoned.