Summary

When thinking={"type":"disabled"} is set in claude-agent-sdk, the SDK does not preserve that explicit setting across the SDK -> CLI -> API path.

Instead, it appears to downgrade the setting into --max-thinking-tokens 0. For Anthropic-compatible providers, this is not equivalent to explicitly sending thinking={"type":"disabled"}.

As a result, on compatible third-party backends, thinking may still remain enabled and responses may still contain ThinkingBlock, even though the user explicitly requested disabled thinking.

Why this is a bug

From the SDK user's perspective, thinking={"type":"disabled"} should be preserved semantically end-to-end.

The current behavior changes a structured API instruction into a token-based CLI flag, which may work for Anthropic-native handling but does not appear to work correctly for Anthropic-compatible providers that distinguish between:

• omitted thinking
• explicit thinking={"type":"disabled"}

This means the SDK does not reliably transmit the user's intent.

Expected behavior

When the user sets:

thinking={"type":"disabled"}

the final request should preserve that intent and explicitly disable thinking, rather than relying on --max-thinking-tokens 0 or omitting the thinking field.

In other words, Anthropic-compatible providers should receive the equivalent of:

thinking={"type":"disabled"}

so that disabled thinking works consistently across providers.

Impact

This likely affects Anthropic-compatible providers in general, not just one specific model or vendor.

As a result, users cannot reliably disable thinking through claude-agent-sdk when targeting compatible third-party backends.

Suggested fix

Please preserve the structured thinking configuration across the SDK -> CLI boundary, or ensure that the disabled case is serialized as an explicit thinking={"type":"disabled"} request instead of being reduced to --max-thinking-tokens 0.

Environment

• claude-agent-sdk: 0.1.49
• Claude Code CLI: 2.1.77