[Bug] dsh-llm-deepseek throws UNSUPPORTED_CONTENT on Anthropic redacted_thinking blocks

[yqxu]

Summary

@deepseek-ai/dsh-llm-deepseek 0.2.1-rc.3 fails a session on the second LLM step when the Anthropic-compatible endpoint returns a redacted_thinking content block. Tool calls in step 1 succeed; step 2 fails before further tool execution, so multi-step agent loops cannot continue.

Environment

• DSH: 0.2.1-rc.3
• @deepseek-ai/dsh-llm-deepseek: 0.2.1-rc.3
• Endpoint: Anthropic-compatible gateway (.../anthropic/v1) via Bifrost
• Models tested: deepseek-v4-pro, deepseek-flash
• reasoningEffort: none and high (both reproduce)
• Session has MCP tools enabled

Steps to reproduce

1. Create a DSH session and bind it to a task/work item.
2. Prompt the agent with a normal instruction; in step 1 the agent calls an MCP tool successfully.
3. Let the session continue to step 2.

Actual behavior

Step 1 tool calls succeed. Step 2 fails with:

DeepSeek Messages does not support response block redacted_thinking
code=UNSUPPORTED_CONTENT

Session events show assistant/attempt finishing with an error and turn/end with the same error.

Expected behavior

Anthropic Messages defines redacted_thinking as a content block that clients should pass through / round-trip without interpreting. The adapter should at minimum not fail the turn; ideally preserve and replay it according to the protocol.

Root cause

In packages/llm/llm-deepseek, startBlock() handles text, thinking, and tool_use; the default branch throws:

default: throw new LlmError(
  `DeepSeek Messages does not support response block ${String(native.type)}`,
  "UNSUPPORTED_CONTENT"
);

The installed build throws at lib/index.js:1878.

Impact

Any Anthropic-compatible provider/model that emits redacted_thinking cannot complete a multi-step tool loop. This blocks agent workflows that need more than one step of tool calls.

Notes

• Switching models (deepseek-v4-pro vs deepseek-flash) does not help; the block type is the trigger.
• Setting reasoningEffort: none did not prevent it in my test.
• Package metadata points to this repository; issues are disabled, so reporting via Discussions as CONTRIBUTING.md requests.

Possible fix

Handle redacted_thinking in startBlock() (and request replay) as an opaque/empty reasoning block instead of throwing, or skip it while preserving block indices.

[argszero]

Read this at 22ddee3792 and the answer decides the fix: redacted_thinking has to come back to the provider, so dropping it is not the repair.

The tree already encodes that requirement. packages/llm/llm-pi-ai/tests/protocol-roundtrip.spec.ts:42 feeds a { type: 'redacted_thinking', data: 'encrypted-redacted-reasoning' } block; :147 shows how it is recorded — { type: 'reasoning', thinkingSignature: 'encrypted-redacted-reasoning', redacted: true }; and :173 asserts the next request to the same provider still contains that payload. The block is not decoration: its data is a signed blob that later steps depend on being returned unchanged.

dsh-llm-deepseek has no way to do that, in three places that would have to move together:

• src/translate.ts:60 — throws on any block outside text / thinking / tool_use.
• src/replay.ts:7-10 — ReplayBlock is { type: 'text' | 'reasoning' | 'tool-call'; signature?: string }: no redacted marker, and no field that could carry data.
• src/serialize.ts:31-34 — writes a reasoning block back as { type: 'thinking', thinking, signature? }. There is no branch that can emit { type: 'redacted_thinking', data }, which is a different block type rather than a thinking block with a signature.

So the fix is not local to startBlock(). Accepting the block without recording it would send the next request a history whose reasoning continuity silently differs from what the provider issued — the failure moves from a loud UNSUPPORTED_CONTENT to a quiet one, which is worse than the report. What it actually takes: accept and record the block (a shape change to the durable deepseek-messages replay envelope, so a version bump), and re-emit it at the same index. tests/stream.spec.ts:89 pins the current throw, so it moves with the fix.

I want to be explicit about the boundary, because it is why this is analysis and not a patch. The seam is not reachable from outside the adapter. The throw happens inside translate()'s generator, before any chunk reaches an llm/stream listener — a response-side filter never sees the block, it sees an error. Catching that error downstream would suppress content the request has to carry later, which is the opposite of a repair. And the request side needs the payload to have been persisted first; nothing in the session record holds it, so an external wrapper would have nothing to replay. The fix belongs in dsh-llm-deepseek's serialization and replay state, not in a wrapper around it.

Interim, if you need multi-step loops before that lands: the pi-ai adapter speaks the same wire protocol as a named route —

anthropic:
  baseURL: https://your-gateway/anthropic
  api: anthropic-messages

(shape from packages/llm/llm-pi-ai/README.md:54-58). That is the code path with redacted-block handling, per the test above. Honest caveat: my evidence is that in-tree roundtrip test against a mock Anthropic server, not a run against a Bifrost gateway, so treat it as "the adapter that handles the block" rather than a verified fix for your endpoint.

Two limits on this reading, so you can discount it correctly. It is source at 22ddee3792, not your installed rc.3 build — your lib/index.js:1878 is consistent with this translate.ts:60, but I did not execute your build. And I cannot open a pull request here: issues are disabled, as you found, and this repository is not taking contributions through my account — so this message is the contribution, and the patch has to come from someone who owns the adapter.