[FEATURE] Model Specific Feature Mechanism

[dbschmigelski]

Problem Statement

Currently, different models on Bedrock and other providers have specific requirements and limitations that can cause runtime failures. For example, DeepSeek R1 has issues with reasoningContent in messages that other models like Claude don't have (as seen in PR #652 ). We need a systematic way to handle these model-specific configurations and requirements.

Proposed Solution

No response

Use Case

The system should implement a configuration registry pattern where model-specific behaviors are defined in external configuration files rather than scattered throughout the codebase with if-statements. This approach would be similar to how the SDK currently handles other features (as seen in various issues like #652 and #713).

For example, instead of:

if model == "deepseek":
    strip_reasoning_content()
elif model == "claude":
    handle_token_limits()

The system would use a declarative configuration approach where model capabilities and limitations are defined in configuration files, and a single handler processes these configurations. This keeps the core code clean and maintainable while moving model-specific logic to configuration rather than implementation.

This design would align with the SDK's existing architecture while preventing the proliferation of model-specific conditional statements throughout the codebase, as evidenced by the challenges seen in the DeepSeek reasoning content issue (#652) and other model-specific issues in the repository.

Alternatives Solutions

No response

Additional Context

No response

[dbschmigelski]

Additional example of model/provider specific logic #630

model = BedrockModel(
    model_id="openai.gpt-oss-120b-1:0",
    streaming=False,
)

Strands should know gpt oss must use Converse and automatically use it.

[dbschmigelski]

Additional example #686 relating to non-claude models and the inclusion of the status field.

[matheus-1618]

Hey, any news on it? Thanks!