gpt-5.5 compact_remote: high demand reliably fails on Azure OpenAI / Foundry - A/B confirms it is not endpoint-specific

Resolved 💬 12 comments Opened May 7, 2026 by gstredny Closed Jun 29, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

compact_remote: remote compaction failed ... compact_error=We're currently experiencing high demand, which may cause temporary errors. reliably stalls Codex CLI sessions against Azure OpenAI / Azure Foundry endpoints when assembled
context approaches ~244k tokens.

I just confirmed via a controlled A/B test that the failure is not specific to any particular Azure resource
kind, hostname, or per-deployment configuration. It is gpt-5.5-specific and reproduces across two distinct
deployment variants in the same subscription.

This is likely a duplicate of #19255 with stronger evidence, and is the use case feature request #13739 was filed
against.

## Repro environment

Codex CLI: v0.128.0
Workstation: macOS Darwin 25.3.0
Two Azure deployments of gpt-5.5 v2026-04-24 in the same Azure subscription, region eastus2:

| | Deployment A (original) | Deployment B (A/B test) |
|---|---|---|
| Resource kind | AIServices | OpenAI |
| Hostname | gpt55.cognitiveservices.azure.com | championxpertazureopenai.openai.azure.com |
| SKU | GlobalStandard | GlobalStandard |
| Capacity | 7,180 | 2,000 |
| RAI policy | NewFilter (pass-through) | Microsoft.DefaultV2 |
| System-assigned identity | yes | no |

Codex profile config (host varies, everything else identical):

```toml
[model_providers.azureXX]
name = "AzureOpenAI"
base_url = "https://<host>/openai"
query_params = { "api-version" = "2025-04-01-preview" }
env_key = "AZURE_OPENAI_API_KEY"
wire_api = "responses"

[profiles.azureXX]
model = "gpt-5.5"
model_provider = "azureXX"
model_reasoning_effort = "xhigh"
model_context_window = 900000
```

Drive a normal interactive multi-turn session past ~244k tokens of assembled history. Failure occurs reliably above
that threshold; timing is non-deterministic (3-120 min) but inevitable.

## Failure event

``2026-05-07T17:34:07.889465Z ERROR session_loop{thread_id=019e037b-463e-76d1-b8c3-bd32ce54ae50}:...:turn{... model=gpt-5.5}: codex_core::compact_remote: remote compaction failed turn_id=019e037b-b1f0-7f90-a249-a679a1b37dbe last_api_response_total_tokens=244199 all_history_items_model_visible_bytes=954955 model_context_window_tokens=Some(258400) failing_compaction_request_model_visible_bytes=976302 compact_error=We're currently experiencing high demand, which may cause temporary errors.``

Across my current ~/.codex/log/codex-tui.log (613,029 lines): 99 of 99 compact_remote: remote compaction failed events are on model=gpt-5.5. Zero on any other model in the same log.

## What the A/B test rules out

By reproducing the failure on a brand-new deployment with completely different per-resource configuration:

Resource kind (AIServices vs OpenAI)
Hostname (*.cognitiveservices.azure.com vs *.openai.azure.com)
RAI policy
System-assigned managed identity
Per-deployment RPM ceiling (failure occurs at <2% utilization on the 2,000-RPM A/B deployment)
Subscription quota saturation (47.9% on OpenAI.GlobalStandard.gpt-5.5)

## Working hypothesis

Codex's compact_remote code path appears to call https://chatgpt.com/backend-api/codex/responses/compact, which
is ChatGPT-authenticated only. When Codex runs against an Azure Foundry deployment, the regular responses API calls
correctly route through the Foundry endpoint (visible in trace as transport="responses_http" api.path="responses"), but the auto-compact path still hits chatgpt.com and receives "high demand" responses
regardless of which Azure deployment hosts the model.

Microsoft Azure Support was not filed: the Azure portal blocked submission because the submitter lacks the
Support Request Contributor role on the subscription. The A/B test above is already conclusive enough for
Codex-side triage; a Microsoft server-side trace would now be corroborating only. If a subscription admin files one
later, the useful ask is whether compaction requests reached either Azure deployment at the failure timestamps.

## Possible fixes (in increasing order of effort)

Per-call compaction-model override (per #13739) - so users can route compact to a Foundry-side model that

works.

A compact.endpoint (or [model_providers.X].compact_base_url) config key - explicit endpoint override.
Automatic local-fallback compaction when remote compact returns auth-style rejections (the "high demand" / 5xx

pattern from chatgpt.com against unauthorized callers).

For wire_api="responses" on non-OpenAI providers, **derive the compact endpoint from

model_providers.<name>.base_url** rather than calling out to chatgpt.com.

## Mitigations I currently run

Shell wrapper aborts after 2 consecutive compact_remote failures (avoids the fork-loop where each retry inherits

a still-bloated context).

Tail-watcher warns at >=3 events / 60s.
model_context_window = 900000 in the profile defers the auto-compact firing rate.

None of these resolve the underlying break - they just contain the blast radius.

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#19979
#21343
#20931
#20439
#20160

Powered by Codex Action

gstredny · 2 months ago

Reviewed the flagged candidates (#19979, #21343, #20931, #20439, #20160).
Not closing — they all use ChatGPT Pro/Plus subscription auth; this report
is the only one against Azure OpenAI / Foundry, and it includes a
controlled A/B test reproducing the failure across two distinct Azure
resource kinds. The "We're currently experiencing high demand" error
variant (also seen in one #20931 comment by @skypher) appears distinct
from the dominant "stream disconnected" variant in the other reports —
suggests two different failure modes against the same endpoint, with
the "high demand" variant most likely being auth-rejection rather than
capacity throttling.

presidenzo · 2 months ago

Also seeing this on Codex Desktop for macOS.

Thread ID: 019e0390-d329-74c3-b8ab-13a32d339c9b
Codex App: 26.429.61741 (2429)
Error:

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

This is still happening today (2026-05-07).

gstredny · 2 months ago

Third data point — capacity is also not the variable. Tested today (2026-05-07) on a freshly-deployed gpt-5.5 deployment with 2.25× higher per-deployment capacity (4,504 RPM vs 2,000 RPM prior A/B vs 7,180 RPM original) on the same OpenAI-kind Foundry resource (championxpertazureopenai). Failed identically with 'currently experiencing high demand' at 244k tokens / ~954KB compaction request. Subscription quota at 47.9% utilization at failure time.

Three gpt-5.5 deployments tested. Three different configurations:

gpt55 (kind=AIServices, capacity 7180)
ChampionXpertAzureOpenAI/gpt-5.5 (kind=OpenAI, capacity 2000)
ChampionXpertAzureOpenAI/gpt-5.5-2 (kind=OpenAI, capacity 4504)

All three fail. Same gpt-5.4 deployment on the same tenant: also has the same failure note.

The compact_remote endpoint is failing on Azure-Foundry-hosted gpt-5.5 specifically, regardless of resource kind or per-deployment capacity. Failure pattern is consistent: large compaction request (800KB-1MB), 220k+ tokens of model-visible history.

Stealthx9 · 2 months ago

same issue

mahdikayvan · 2 months ago

@gstredny Hey — I feel this pain too. Your issue is very close to the reliability problem I’m working on.

I’m building AgaveCore, and I’d like to let a few early people use it for free while I shape it into something stronger.

It helps when a coding agent starts to drift, forget important progress, or gives you an output you do not fully trust.

In practice, it works through two habits:

tell the agent to remember-progress or remember-this when something important should not be lost
use consult-brain when the current task needs more grounded feedback on what to do next

Over time, as useful journals, decisions, and failures pile up, the product should help the agent make sharper decisions and take better actions with less drift.

If this sounds relevant, reply here and I’ll send the exact steps. You can also use the email or Telegram on my profile.

Cheers,
Mads.

skypher · 2 months ago

@mahdikayvan It's not acceptable to use Github Issues for plugging your project (plus your write up doesn't even fit the issue here). Stop doing it.

byte-rose · 2 months ago

Same issue on Azure openai deployments, Have been on codex since 5.2 this is a 5.5 issue

ericrbg · 2 months ago

I found some success using base_url = "https://<host>/openai/v1"

jordanbardwell · 1 month ago

Same issue here still with Foundry deployment.

harshith-vaddiparthy · 1 month ago

I hit the same failure pattern locally on codex-cli 0.137.0 with an Azure provider + gpt-5.5 + xhigh setup, and put together a small patch/proof-of-fix here:

Summary of the approach:

In remote compaction v2 only, keep normal retry behavior first.
If compaction fails with capacity-style errors (InternalServerError / ServerOverloaded) after the compact retry budget, retry the compact request once at low reasoning effort.
Keep normal sampling turns on the user-selected reasoning effort.
Add an integration test that asserts the failed compact request uses xhigh, the fallback compact retry uses low, and the fallback compaction output is installed for the follow-up turn.

Validation run locally:

just fmt
just test -p codex-core remote_compact_v2_retries_capacity_failure_with_lower_reasoning_effort
just test -p codex-core remote_compact_v2_retries_failures_with_stream_retry_budget
just fix -p codex-core

I attempted to open this as an upstream PR, but GitHub returned CreatePullRequest permission denied for this repo/account. That lines up with docs/contributing.md saying external PRs are invitation-only, so I’m leaving the patch and validation details here for maintainers.

etraut-openai contributor · 21 days ago

Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use /feedback and open a new bug report.