Implement request compression in the Python runtime and generated clients #854

Describe the feature

I'd like Smithy Python to implement the requestCompression trait, so generated Python clients can compress request bodies when an operation supports it.

At the source revision below, the generator preserves compression metadata but lists compression as unsupported and leaves the associated protocol tests as expected failures. This seems like the right shared layer to implement the behavior for the new async AWS SDK.

An explicit gzip choice should require compression to be available and fail before sending when the operation doesn't support it. A zero automatic threshold alone would still allow unsupported operations to send uncompressed requests.

Use Case

We use AWS-hosted models for agents with long conversations and large tool results. Sending that context on every turn adds upload time before the model can respond. Request compression can reduce that transfer without changing the conversation itself; it doesn't reduce tokens or guarantee a particular latency improvement.

Anthropic announced gzip in Claude Code, with large-request behavior documented in its changelog. OpenAI supports zstd request bodies on the Responses API. Those capabilities are specific to their endpoints. The wider speed improvements in Anthropic's announcement aren't a measurement of gzip alone.

AWS offers models from these providers through Bedrock and its Mantle endpoint. Supporting the corresponding transport capabilities would make AWS a stronger option for these applications. 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. SDK support and service acceptance need to be coordinated.

Proposed Solution

The companion PR uses the operation's advertised encodings, compresses the serialized body before signing, updates the wire headers, and preserves compressed bytes across buffered-request retries. Generated clients expose automatic controls and an explicit request_compression_encoding="gzip" choice. Explicit gzip bypasses the size threshold; unsupported choices and conflicting disable settings fail before sending. The implementation supports gzip under the current Smithy contract. Zstd needs follow-up agreement on that contract and service support.

I'd appreciate feedback on the runtime boundary and configuration names in the diff. The goal is one shared implementation for generated clients. Streaming input follows modeled restrictions; this does not add streaming-input retry support.

Bedrock Runtime still needs service acceptance and upstream metadata. Mantle's provider-compatible APIs need separate API/client coordination. Can you help coordinate those parts with the AWS SDK and service teams? The checks above cover only the named Haiku routes; they include no OpenAI-route test or latency measurement.

Other Information

Companion implementation: PR.

• Botocore: explicit compression choice on top of existing gzip support — issue, PR.
• AWS SDK for Python v4: consume the shared implementation and document the Bedrock boundary — issue, PR.

Acknowledgements

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

Affected component

codegen (Java code generator), smithy-core, smithy-http, smithy-aws-core, generated client code

Version used

Source reviewed at 1692e03f047504ee43859f18ddd3e5397c004d5a. The companion PR records the tested implementation revision.

Python version used

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