Expose request compression in the new SDK and coordinate Bedrock support #110

Describe the feature

I'd like the new async Python SDK to expose request-body compression through its generated client configuration, and to establish how Bedrock and Mantle can support it.

We use AWS-hosted models for conversation-heavy agents. As conversations and tool results grow, uploading the next request becomes part of the wait before the first token. Exposing the standard SDK compression controls would be a useful product capability for AWS-hosted inference.

Use Case

Anthropic announced gzip in Claude Code, and its changelog documents compression for large requests to api.anthropic.com. OpenAI documents zstd request bodies for the Responses API.

AWS offers models from these providers through Bedrock and its Mantle endpoint. I'd like AWS applications to be able to use supported compression capabilities too, without maintaining custom HTTP transports. Compression can reduce upload time; the benefit depends on payload size and the network. It doesn't reduce model tokens.

In checks on October 18, 2026 in us-east-1, matched requests using Anthropic Haiku succeeded uncompressed through Bedrock Converse/ConverseStream and Mantle Messages, including streaming responses. Gzip and zstd requests returned HTTP 400; Bedrock reported Unable to parse request body. This needs service coordination alongside the SDK implementation.

Proposed Solution

The companion PR adopts Smithy Python's shared compression implementation through the usual generated client configuration. Generated clients expose disable_request_compression and request_min_compression_size_bytes, with the standard inclusive threshold range of 0 through 10485760. The companion implementation supports gzip under the current Smithy contract; zstd needs a coordinated follow-up covering the contract and service support.

A zero threshold compresses eligible buffered requests regardless of size. Operations without compression metadata remain uncompressed, including current Bedrock Runtime operations.

The shared runtime and generator changes belong in Smithy Python. This repository should adopt that behavior through its normal generation and dependency workflow, with client-level tests and guidance explaining the service capability requirement. Adoption depends on a Smithy release containing the implementation. We should not manually advertise compression on Bedrock operations that don't accept it.

This generated client covers modeled Bedrock Runtime operations. Mantle's provider-compatible APIs need a separate API/client integration.

The diff includes client tests and guidance for this integration. I'd appreciate feedback on the generation and release process, and help connecting with the Bedrock/Mantle service owners. The checks above cover only the named Haiku routes; they include no OpenAI-route test or latency measurement.

Other Information

Companion implementation: PR.

• Smithy Python: shared runtime and code generation — issue, PR.
• Botocore: correct the standard compression threshold range — issue, PR.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

Affected area

service client (generated client under clients/), code generation, documentation

Relevant package(s)

aws-sdk-bedrock-runtime; shared compression implementation in smithy-python.

Source reviewed at 8f209d245501792c7b18ce197c194170ca4d6564.

Python version used

Python 3.12.14 for the companion implementation's local tests. See the companion PR for validation details.