DSH redacted_thinking compatibility

DSH redacted_thinking: Anthropic Tool-Call Compatibility

Author
DeepSeekAgent.io Editorial Team
Published
Updated

Multi-step tool use can stop on the second model call when DeepSeek models are reached through an Anthropic-compatible protocol. In a community reproduction, the first Tool Call completes, then the next response contains a redacted_thinking block. The DSH adapter throws UNSUPPORTED_CONTENT, reporting that DeepSeek Messages does not support that response block.

The tool itself is not the failure, and visible reasoning settings are not the core issue. Anthropic uses redacted_thinking for protected reasoning content. A compatible client must preserve it as opaque protocol data and return it when required by the next request.

Why the first step succeeds

The initial request has no complete prior Assistant response to round-trip, so the model can emit tool_use normally. After the tool result is added, the second request enters a multi-step path. When a gateway or model emits redacted_thinking, an adapter dispatcher that only handles text, thinking, and tool_use reaches its default error branch.

The visible symptom is “the second tool step failed,” but the actual boundary is response-block mapping. Both none and high reasoning effort can reproduce it because UI exposure of reasoning is separate from protocol support for an opaque block.

Correct treatment of redacted_thinking

The compatibility layer should:

  1. Accept the block without aborting the whole response.
  2. Preserve the fields required for round-trip integrity, including ordering.
  3. Hide protected contents from UI and logs, recording only safe type and position metadata.

If the internal DeepSeek Messages representation cannot express the block, the adapter can retain it in dedicated opaque metadata and restore it for the next Anthropic-protocol request. Dropping it may or may not work depending on gateway signature and continuity requirements; round-trip preservation is the safer default.

Reproduction and diagnosis

Use a minimal task that requires at least two tool calls and retain:

  • DSH, provider-plugin, and gateway versions;
  • model ID, protocol, and reasoning setting;
  • the ordered block types in the first response;
  • the raw block types after the tool result;
  • the adapter function and block index from the error stack.

When the first step succeeds and the second consistently fails on the same block type, changing tools or increasing timeouts adds little evidence. Inspect the adapter union and default branch. With translation gateways such as Bifrost, determine whether the upstream response originally contained the block or the gateway mapped another reasoning form into it.

Regression coverage after a fix

Test at least:

  • text → tool_use → tool_result → text;
  • thinking → tool_use;
  • redacted_thinking → tool_use;
  • interleaved blocks and multiple Tool Calls;
  • persistence, Session replay, and next-turn round trips;
  • safe logs, exports, and UI rendering.

The absence of an exception is not sufficient. The second tool must execute, and reopening the Session must preserve the same context and block order.

For a fixed wait without UNSUPPORTED_CONTENT, see the 30-second turn event-timeline analysis. The two problems require different evidence.

References

FAQ

Does disabling reasoning effort avoid the issue?

Not reliably. The reported case reproduces across reasoning settings when the protocol response includes an unsupported block type.

Can redacted_thinking be converted into ordinary text?

It should not be. It is protected opaque protocol data, and conversion can violate confidentiality and signature requirements.

Why does the failure often appear on the second Tool Call?

Multi-step execution must round-trip the previous Assistant content. That is when an uncovered block type enters the complete adapter path.