openai / openai/codex

Allow configuring request body compression per model provider

Open
#41,662 0 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

CLI config custom-model enhancement
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What variant of Codex are you using?

CLI

What feature would you like to see?

Allow request body compression to be configured per model provider:

[model_providers.my-gateway]
name = "my-gateway"
base_url = "https://gateway.example.com/v1"
wire_api = "responses"
request_compression = "gzip"   # "off" (default) | "gzip" | "zstd"

Today compression only engages when all three conditions in responses_request_compression (codex-rs/core/src/client.rs) hold:

self.client.state.enable_request_compression
    && auth.is_some_and(CodexAuth::uses_codex_backend)
    && self.client.state.provider.info().is_openai()   // provider.name == "OpenAI"

Any custom model_providers entry therefore always uploads uncompressed, with no way to opt in — including OpenAI-compatible gateways that forward to the official Codex backend and would happily accept the same compressed bodies.

Why this matters

Responses API request bodies are JSON conversation history: highly compressible, growing with every turn, and re-sent in full on every request. Over a long session, upload is where the bytes are.

The response direction can already be compressed through ordinary Accept-Encoding negotiation, so on a custom provider the request direction ends up being the only leg paying full price — and it is also the leg that grows with context length. On metered or bandwidth-constrained egress that is the largest avoidable cost in the path.

Why it has to be explicit configuration

HTTP has no negotiation mechanism for request bodies — Accept-Encoding only covers the response direction. A client cannot discover whether an endpoint accepts Content-Encoding: zstd, so this cannot be auto-detected and should not be on by default.

Making it a per-provider opt-in puts the decision with the operator, who is the only party that knows what their endpoint accepts:

  • default "off" — no behavior change for any existing config
  • "gzip" as the conservative option; it is far more widely supported by OpenAI-compatible servers than zstd
  • leave the current hardcoded behavior for the official provider untouched

Optionally, a one-shot fallback: if the first compressed request comes back 400/415, retry it uncompressed and remember that for the rest of the session, so a misconfiguration degrades gracefully instead of failing hard.

Additional information

Related: #18677 (closed as completed) asked for enable_request_compression to be made explicit (off / auto / force), but stayed scoped to the official provider. This request is the complementary half — letting the provider entry declare what its own endpoint accepts.

The existing test request_body_is_not_compressed_for_api_key_auth_even_when_enabled documents the current intent, so this would be a deliberate, explicitly gated widening of that contract rather than a change to any default.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in codex-rs/core/src/client.rs at responses_request_compression and inspect the existing request_body_is_not_compressed_for_api_key_auth_even_when_enabled test. Trace how model_providers entries reach the client configuration. Done means provider-level off/gzip/zstd configuration is covered by tests while the default and official-provider behavior remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, cli
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.