OpenClaw Main Stops Bodyless HTTP 400 Errors Triggering Compaction
A merged classifier fix prevents ambiguous bodyless provider 400 responses from being treated as context overflow, avoiding pointless compaction and retry.
OpenClaw has merged a P1 correction for provider failures that could trigger the wrong recovery: an HTTP 400 response with no body was classified as context overflow, causing the embedded runner to compact the conversation and retry.
A bodyless 400 does not explain why the provider rejected the request. Compaction spends time and tokens, mutates the session summary boundary and retries without evidence that context size was the problem.
PR #119596 removes bodyless 400 from the overflow patterns while preserving the specific bodyless 413 handling required for providers such as Cerebras. The change is on main; the sources do not identify the first package containing it.
Why the classifier matters
Error handling is active policy. Once a response is labelled “context overflow,” the runner is allowed to take recovery action rather than simply surfacing the provider failure.
Before the fix, the sequence could be:
- a provider or proxy returns HTTP 400 without a response body;
- OpenClaw interprets that sparse status as context overflow;
- the embedded runner compacts the session;
- the request is retried against substantially the same unknown failure; and
- the operator sees extra latency and usage before the unresolved provider error becomes visible.
That is a false-positive recovery loop. The absence of detail must not be converted into confidence about context size.
Bodyless 413 remains deliberately different
The merged patch does not classify every bodyless response identically. The upstream source records Cerebras using 413 status code (no body) as an overflow signal, so that narrow case remains actionable.
Descriptive 400 responses that actually identify context limits can still match specific overflow evidence. The corrected rule is:
- an ambiguous bodyless 400 is surfaced as a provider error;
- a known bodyless 413 overflow convention can trigger compaction; and
- an explicit provider message describing context overflow remains eligible for recovery.
Interpretation: status codes are transport evidence, not universal model semantics. A recovery classifier should require the smallest provider-specific fact that makes the action safe.
Who should prioritise the fix
Prioritise a containing build when:
- provider or proxy logs show bare HTTP 400 responses;
- sessions compact unexpectedly despite being comfortably below the active context budget;
- the same failed request appears twice around a new compaction summary;
- custom provider gateways remove response bodies; or
- unnecessary retries have a meaningful latency or usage cost.
Do not disable all compaction as a workaround. Real context overflow still needs bounded recovery, and removing it globally trades a false positive for failed long conversations.
Diagnose an affected run
Preserve metadata before retrying manually:
- record the exact OpenClaw version or source SHA;
- record provider, model, HTTP status and whether a body was present;
- compare estimated context use with the effective runtime budget;
- identify whether a compaction boundary appeared immediately after the error;
- determine whether the retry produced the same status; and
- check provider or proxy telemetry for the real rejection reason without copying credentials or prompt content into tickets.
If the body was stripped by an intermediary, fix that observability path as well. The classifier correction avoids destructive guesswork; it cannot recreate diagnostics the proxy discarded.
Safe acceptance test
Use a stub provider with synthetic conversation content:
| Response | Expected result |
|---|---|
| HTTP 400, no body | Error surfaces once; no context compaction or automatic overflow retry |
| HTTP 413 in the supported bodyless overflow form | Existing overflow recovery remains available |
| HTTP 400 with explicit context-limit message | Provider-specific overflow classification still works where supported |
| HTTP 400 with ordinary validation detail | Detail surfaces without compaction |
| Successful response | No classifier change affects the normal turn |
Reconcile the transcript, compaction marker, request count and provider call count. A correct visible error with a hidden extra retry is still a failure.
Evidence and limits
The official issue, merged PR and landed commit establish the false classifier path, the retained bodyless-413 exception and focused embedded-runner coverage. OpenClaw Academy did not run a paid provider or force compaction on production history.
Collector IDs 40517 and 40474 identify the merged repair and commit.
Bottom line
OpenClaw should compact only when the provider gives credible context-overflow evidence. Stage a containing build until a bodyless 400 surfaces once without mutating session context, while genuine overflow signals still recover normally.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF