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.

The configuration should follow the shared AWS SDK controls: disable_request_compression and request_min_compression_size_bytes, accepting thresholds from 0 through 10485760. A zero threshold compresses eligible buffered requests regardless of size; operations without compression metadata remain uncompressed.

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 the standard threshold and disable controls, preserving automatic selection from the operation’s advertised encodings. 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: correct the standard compression threshold range — 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.14 for the companion implementation's local tests. See the companion PR for validation details.