-
Notifications
You must be signed in to change notification settings - Fork 750
Description
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