Compressed Request Bodies
The text generation APIs accept compressed JSON request bodies. Compress your payload, add aContent-Encoding header, and everything else works exactly as before — same request schema, same response.
Why compress?
Chat requests resend the full conversation history every turn, so request bodies grow with the conversation — multi-hundred-kilobyte payloads are common for agents and long chats, and tool schemas add more. JSON like this compresses roughly 5:1 with gzip. The win is mostly your own latency: the request body has to finish uploading before we can start model dispatch, and a large body costs multiple network round-trips just for TCP to ramp up. Compressing it:- Cuts time-to-first-token, most noticeably on long conversations, on high-latency routes, and on constrained uplinks. The further you are from the origin and the bigger your payloads, the more you save on every single request.
- Reduces your egress bandwidth — relevant for server-to-server integrations that send us high volumes.
- Makes retries cheaper and uploads more robust on flaky networks: fewer bytes in flight, fewer mid-upload stalls.
Supported endpoints and encodings
A comma-separated
Content-Encoding list (e.g. gzip, identity) is accepted and decoded in reverse order per the HTTP spec, but a single encoding is all you need.
Examples
The OpenAI and Anthropic SDKs don’t compress request bodies on their own, but both let you plug in a custom HTTP transport. The snippets below work with your existing SDK setup — or with plainfetch/requests if you don’t use an SDK.
curl
Python
JavaScript / TypeScript
The same transport works for
/v1/responses and (with the Anthropic SDK’s equivalent custom-fetch option) /v1/messages — the compression handling is identical on all three endpoints.Errors
Everything else — validation, billing, streaming — behaves exactly as with uncompressed requests.