›_ Codex Issues
Codex Issues / #22876

`/responses/compact` sends `service_tier` when provider-scoped API-key auth is used

Resolved 💬 11 comments Opened May 15, 2026 by msokolov-meta Closed Jun 12, 2026

What version of Codex CLI is running?

0.130

What subscription do you have?

api

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.13.2-0_fbk7_0_gbc14455e13aa x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

What issue are you seeing?

Auto/manual compact can fail because Codex sends service_tier to /responses/compact:

Error running remote compact task: {"error":{"code":"invalid_request_error","message":"Pipeline execution failed: provider error (HTTP 400): Unknown parameter: 'service_tier'.","param":null,"type":"invalid_request_error"}}

This appears to happen when the active model provider uses provider-scoped command/bearer auth. The actual request auth is API-key-like, but compact decides whether to include service_tier using the session-level auth manager.

What steps can reproduce the bug?

  1. Configure Codex to use a model provider with provider-scoped command/bearer auth (ModelProviderInfo.auth), so the provider request path uses AuthManager::external_bearer_only(...).
  2. Configure a non-empty service_tier.
  3. Start interactive Codex CLI/TUI.
  4. Trigger manual or auto compact.
  5. Observe that /responses/compact receives service_tier and can fail with Unknown parameter: 'service_tier'.

What is the expected behavior?

/responses/compact should not include service_tier when the actual resolved provider/request auth does not support it.

More generally, compact request compatibility should be based on the auth/provider setup used for that compact request, not only on the session-level auth manager.

Additional information

The current compact setup decides whether to pass service_tier here:

service_tier: if sess.services.auth_manager.auth_mode() == Some(AuthMode::ApiKey) {
    None
} else {
    turn_context.config.service_tier.clone()
},

That assumes sess.services.auth_manager.auth_mode() reflects the auth mode of the request sent to /responses/compact.

However, provider-scoped auth can replace the request auth later. In the configured provider path:

Some(config) => Some(AuthManager::external_bearer_only(config)),

and BearerTokenRefresher reports:

fn auth_mode(&self) -> AuthMode {
    AuthMode::ApiKey
}

So the actual compact request can be API-key/bearer-authenticated even when the session-level auth manager is not AuthMode::ApiKey.

Potential fixes:

  1. Move the service_tier decision closer to ModelClient::compact_conversation_history, after current_client_setup(), and base it on the actual resolved provider/request auth.
  2. As a safer short-term fix, omit service_tier from /responses/compact by default, or gate it until compact endpoint support is confirmed.

View original on GitHub ↗

11 Comments

BSG2000 · 2 months ago

Confirming this on Codex Desktop App for Windows, build 26.513.4821.0 (Microsoft Store), against Azure AI Foundry (/openai/v1, api-version=preview, wire_api = "responses").

Auto-compact reliably fails with the same payload:

Error running remote compact task: {
  "error": {
    "message": "Unknown parameter: 'service_tier'.",
    "type": "invalid_request_error",
    "param": "service_tier",
    "code": "unknown_parameter"
  }
}

Relevant config.toml:

model = "gpt-5.5"
model_provider = "azure"

[model_providers.azure]
name = "Azure AI Foundry"
base_url = "https://<resource>.openai.azure.com/openai/v1"
env_key = "AZURE_OPENAI_API_KEY"
wire_api = "responses"
query_params = { api-version = "preview" }

No service_tier is set anywhere in config.toml — it is injected by the compact request path itself. Matches the analysis in the original report: the provider uses bearer/API-key auth via query_params/env_key, so service_tier should be omitted for this provider.

Practical impact for Azure-only users: long sessions cannot be auto-compacted, which forces manual /compact and eventually session restart. The "safer short-term fix" proposed in option 2 (omit service_tier from /responses/compact by default until endpoint support is confirmed) would be very welcome for the Azure path.

BSG2000 · 2 months ago

Proposed fix prepared on a fork: BSG2000/codex@fix/compact-omit-service-tier-for-provider-bearer-auth.

Diff is a single file (codex-rs/core/src/compact_remote.rs, +25/−1) and follows the option-1 fix outlined above — move the decision off the session-level auth manager and base it on the resolved provider configuration:

commit c6a2548 / diff view

fn compact_request_uses_api_key_auth(sess: &Session, turn_context: &TurnContext) -> bool {
    if sess.services.auth_manager.auth_mode() == Some(AuthMode::ApiKey) {
        return true;
    }
    let provider_info = turn_context.provider.info();
    provider_info.auth.is_some()
        || provider_info.env_key.is_some()
        || provider_info.experimental_bearer_token.is_some()
        || provider_info.aws.is_some()
}

This covers both the original ModelProviderInfo.auth case and the broader env_key / experimental_bearer_token / aws paths that show the same symptom (e.g. an Azure provider with env_key = "AZURE_OPENAI_API_KEY" running on Codex Desktop 26.513.4821.0).

Cherry-pick if useful:

git remote add bsg2000 https://github.com/BSG2000/codex.git
git fetch bsg2000 fix/compact-omit-service-tier-for-provider-bearer-auth
git cherry-pick c6a2548d71ba85bcd7f666efa819af3fe5c0e9e1

I attempted to open this as a PR via the API but CreatePullRequest is blocked for my account on this repo — likely an org-level policy. Happy to retry via the web UI if maintainers prefer, or for an OpenAI engineer to take this directly.

Notes:

  • I could not run just fmt / cargo test / cargo insta locally (no Rust toolchain in the environment I prepared this from).
  • The existing snapshot test remote_manual_compact_api_auth_omits_service_tier_and_reuses_prompt_cache_key (added in #21676) only exercises CodexAuth::from_api_key directly, not provider-side bearer paths. A follow-up that extends assert_remote_manual_compact_request_parity to configure ModelProviderInfo.auth / env_key / experimental_bearer_token would catch regressions here.
CetinSert · 2 months ago

https://github.com/openai/codex/issues/21671#issuecomment-4467060518

---

  1. git clone this repo
  2. ask codex to drop the service_tier parameter from remote compaction requests
  3. recompile (ideally without LTO or fat-LTO)
  4. win (and wait for a real fix from OpenAI or Azure)

---

A naive (it disables service_tier even for non-Azure remote compaction) patch can be seen here:
https://github.com/Elefunc/codex/commit/c0581fc0a4da98bff5c3832ddc91fb24679ac8e8

---

You can create an Azure-only script/alias and use it like this

#!/usr/bin/env bash
set -euo pipefail

embedded_azure_openai_api_key='#'
AZURE_OPENAI_API_KEY=${AZURE_OPENAI_API_KEY:-$embedded_azure_openai_api_key}

if [[ -z "${AZURE_OPENAI_API_KEY:-}" ]]; then
  printf 'ca: AZURE_OPENAI_API_KEY is empty\n' >&2
  exit 1
fi

export AZURE_OPENAI_API_KEY

exec /home/cetin/tmp/codex-rs-target/release/codex \
  --dangerously-bypass-approvals-and-sandbox \
  -c model_reasoning_effort=xhigh \
  -c service_tier=fast \
  --enable multi_agent \
  -m gpt-5-5 \
  -c 'model_catalog_json="/home/#/rt/ca.models.json"' \
  -c 'model_provider="azure"' \
  -c 'model_providers.azure.name="Azure"' \
  -c 'model_providers.azure.base_url="https://#.openai.azure.com/openai/v1"' \
  -c 'model_providers.azure.wire_api="responses"' \
  -c 'model_providers.azure.supports_websockets=false' \
  -c 'model_providers.azure.env_http_headers={ "api-key" = "AZURE_OPENAI_API_KEY" }' \
  "$@"

ask Codex to create ca.model.json for you!

---
---
---

https://github.com/openai/codex/issues/21671#issuecomment-4497122032

---

0.132.0 still has the same issue!

My patches against 0.132.0 that special-case Azure connections:
https://github.com/Elefunc/codex/commit/71057e6abccd11186674888f7c8bf2991fe834d5

BSG2000 · 2 months ago

Quick maintainer ping on this ÔÇö happy to open the PR via the web UI if that unblocks it (CreatePullRequest via API is blocked on my account for this repo, likely an org policy).

I can also extend assert_remote_manual_compact_request_parity to cover the provider-side paths (env_key, experimental_bearer_token, aws) so we get regression coverage for the cases the current snapshot test in #21676 doesn't exercise. Let me know if you'd like that bundled into the same PR or as a follow-up.

For context on impact: confirmed still reproducing on Codex Desktop for Windows 26.513.4821.0 (Microsoft Store) against Azure AI Foundry with wire_api = "responses" + env_key, identical config to the repro above.

CetinSert · 2 months ago

My patches against 0.133.0 are at https://github.com/Elefunc/codex/commit/9c37cdf619831eda4c5a11f1e4de6e0c9b207ee4!

CetinSert · 1 month ago

My patches against 0.134.0 are at https://github.com/Elefunc/codex/commit/784669bd7182d4006d57da0cbfe4dc9ebb1bfaf6!

CetinSert · 1 month ago

My patches against 0.135.0 are at https://github.com/Elefunc/codex/commit/47182c23e840a2c57205e75a583312472b98677a!

CetinSert · 1 month ago

My patches against 0.136.0 are at https://github.com/Elefunc/codex/commit/1c6142202bd2147f3bab2bf8e2d65e68340d9e6f!

CetinSert · 1 month ago

My patches against 0.137.0 are at https://github.com/Elefunc/codex/commit/0c0d09d84d4c7a58a6aeb0beb221e52d0a72b335!

CetinSert · 1 month ago

0.138.0 has resolved the issue for me!

ax-openai · 1 month ago

Closing as resolved in current releases.