Amazon Bedrock Mantle /responses/compact retains all supplied assistant items across repeated CLI 0.147.0-compatible calls
Summary
In two direct calls to the native Amazon Bedrock Mantle compact endpoint using a CLI 0.147.0-compatible request schema, every supplied assistant response-item ID remained in the returned canonical window. The linked two-pass raw evidence contains 64 assistants after pass 1 and 80 after pass 2, with zero pass-1 assistant IDs missing from pass 2. A separate nine-pass rerun retained every redacted request/response array and reports assistant counts of 8, 12, 16, 20, 24, 28, 32, 36, and 40, with zero request or cumulative historical assistant IDs missing and zero duplicate output assistant IDs at every pass.
These are direct Mantle fixtures, not an end-to-end CLI wire capture. The nine-pass fixture includes the session-scoped prompt_cache_key and representative client identity and metadata headers, but it uses simplified base instructions and user-agent text. Those fidelity limits should be considered when assessing whether the same retention shape occurs in a live CLI session.
The OpenAI compaction guide permits retained items and instructs clients to reuse the returned canonical window without pruning. The integration concern is therefore narrower: over the tested calls, the assistant-message class made no reduction while the V1 compact-output processing in this client preserves returned assistant items in replacement history. If that behavior persists in live CLI sessions, it consumes increasing context. Whether Mantle's retention policy is intended remains unresolved.
Environment
- CLI source reviewed: 0.147.0
- AWS region:
us-east-1 - Model:
openai.gpt-5.6-sol - Endpoint:
https://bedrock-mantle.us-east-1.api.aws/openai/v1/responses/compact - Controlled evidence captured:
2026-08-12T16:26:12Zand2026-08-13T00:02:39Z - Authentication: AWS SigV4 signed for service
bedrock-mantle
Version 0.147.0 enabled Bedrock V1 remote compaction in #36981. Version 0.146.1 did not advertise remote compaction for Bedrock.
Direct two-pass reproduction
The linked reproducer creates 64 synthetic user/assistant turns, calls Mantle compact directly, appends 16 more turns to the returned canonical output, and calls compact again. All user/assistant message content and IDs are synthetic; provider-generated response and compaction IDs are retained for traceability. The linked response arrays redact only opaque encrypted_content values.
The client sends model-visible history, base instructions, and model-visible tools to /responses/compact, subject to its existing context-fit rewriting of function outputs. This fixture matches the compact request schema and uses no tools so assistant retention can be measured independently, but it is not byte-for-byte identical to an emitted CLI request; the fidelity limits are stated above.
Results
| Pass | Mantle input tokens | Assistants returned | Prior assistants removed | Assistant items, serialized bytes |
|---|---:|---:|---:|---:|
| 1 | 4,261 | 64/64 | — | 21,922 |
| 2 | 5,042 | 80/80 | 0 | 26,290 |
“Assistant items, serialized bytes” is the sum of each assistant item's UTF-8 byte length after individual minified JSON serialization. It is directly reproducible from the redacted response JSON. This is a serialized-size measurement, not a token estimate. usage.input_tokens is reported exactly as returned by Mantle.
Response IDs:
resp_kdtb5sdn2nfbyq5qfsgfmyrj77inmx3c37n6oq6aii3nbityq6garesp_3ychnhro2cnddgvfyijqayzdlxpnmujykj2xaccuwulaagpspzkq
The separately generated trace-headers.json record reports that a direct trace against the same endpoint and model at 2026-08-12T15:52:40Z returned HTTP 200 with both x-amzn-requestid and x-request-id; each contained:
req_6detnlh66smu7waxw7pqqnaukk4xu7lzwqopp5ul3mpnourrfdaq
Nine-pass direct reproduction
The second fixture called the native AWS Mantle endpoint with SigV4 authentication and representative CLI 0.147.0 identity and metadata headers for this path. The exact header names and synthetic values are retained in the evidence and reproducer.
It is not an exact wire capture: the fixture sends the session ID as prompt_cache_key, but the CLI uses a full platform-specific user agent and its actual base instructions.
| Pass | Request assistants | Returned assistants | Request IDs missing | Historical IDs missing | Duplicate output IDs | HTTP | Redacted output-array bytes |
|---|---:|---:|---:|---:|---:|---:|---:|
| 1 | 8 | 8 | 0 | 0 | 0 | 200 | 3,261 |
| 2 | 12 | 12 | 0 | 0 | 0 | 200 | 4,841 |
| 3 | 16 | 16 | 0 | 0 | 0 | 200 | 6,433 |
| 4 | 20 | 20 | 0 | 0 | 0 | 200 | 8,025 |
| 5 | 24 | 24 | 0 | 0 | 0 | 200 | 9,617 |
| 6 | 28 | 28 | 0 | 0 | 0 | 200 | 11,209 |
| 7 | 32 | 32 | 0 | 0 | 0 | 200 | 12,801 |
| 8 | 36 | 36 | 0 | 0 | 0 | 200 | 14,393 |
| 9 | 40 | 40 | 0 | 0 | 0 | 200 | 15,985 |
The linked redacted arrays independently reproduce each request/output count, missing-ID check, duplicate-ID check, and redacted serialized-size measurement. After the documented encrypted_content redaction, each request after pass 1 contains the preceding redacted response output as an exact prefix and appends four new user/assistant pairs. The reproduction script constructs each live follow-up request from the preceding raw .output before redaction. The script records curl's exact HTTP status for every call; all nine were 200.
Across these nine tested calls, assistant count increased from 8 to 40 and the independently reproducible redacted serialized output-array size increased from 3,261 to 15,985 bytes. This demonstrates no assistant reduction over the tested range. It does not demonstrate infinite growth or a context-limit failure.
Client integration incompatibility
The current V1 compact-output filter intentionally preserves assistant messages returned by Mantle, so those messages enter the canonical replacement history. It drops developer messages, some user messages, reasoning, and function/tool artifacts rather than installing every returned item literally unchanged. See process_compacted_history in core/src/compact_remote.rs at tag rust-v0.147.0, lines 304–368.
Preserving returned assistant messages is consistent with the OpenAI compaction guide. A global client-side assistant-pruning rule would therefore be the wrong general fix.
The common remote-compaction mock used by the Bedrock coverage currently retains user/developer messages, drops assistant/tool history, and appends a compaction item. The helper describes that as current remote compaction behavior. The directly observed Mantle response shape does not match that assumption. See core/tests/common/responses.rs at tag rust-v0.147.0, lines 1112–1185.
Client context threshold
The Bedrock catalog declares a 272,000-token context window for GPT-5.6. From that entry, the client exposes a 258,400-token effective input window (272,000 × 95%) and ordinarily derives a 244,800-token automatic-compaction threshold (272,000 × 90%). The 95% input-window default and 90% automatic-compaction calculation are separate in protocol/src/openai_models.rs at tag rust-v0.147.0, lines 357–359 and 466–476.
AWS's current GPT-5.6 Sol model card also states a 272K-token context window. This report therefore makes no separate context-catalog mismatch claim.
Scope and non-claims
- Retained items are permitted by the public compact API contract.
- This report does not claim that any individual retained assistant message violates that contract.
- The observed behavior is no reduction of the assistant-message class over the tested two-pass and nine-pass ranges.
- The direct requests use a CLI 0.147.0-compatible schema; they are not an emitted CLI wire capture.
- Both fixtures call the native AWS Mantle endpoint with Bedrock SigV4 authentication.
- The nine-pass fixture includes
prompt_cache_keyand uses representative, not byte-identical, client headers and metadata. - All user/assistant message content and IDs are synthetic. Provider-generated response and compaction IDs are retained for traceability, while opaque compaction
encrypted_contentis redacted in the linked arrays.
Related issues
The closest prior report is #14365, which documented the same assistant-retention failure shape on the older OpenAI remote-compaction path and was closed when those sessions moved to local compaction. This report is distinct because #36981 later enabled V1 /responses/compact for Amazon Bedrock in 0.147.0, and the linked evidence directly captures the native Mantle response shape over repeated calls.
This is not a clean duplicate of #24191. That report concerned very large remote-compaction records and was closed after the affected sessions moved to local compaction; Bedrock V1 remote compaction was enabled later in 0.147.0.
Two open issues limit mitigation:
- #24418: no supported override to disable remote compaction
- #37010: remote-compaction capability cannot be configured per model
Requested resolution
- Confirm whether Mantle's retention of all supplied assistant messages across repeated compact calls is intended.
- Decide and document the intended reduction behavior for repeated Bedrock compaction, then add a test using the live response shape over multiple calls.
- If this Mantle behavior is intended or cannot be changed promptly, do not enable Bedrock V1 remote compaction unconditionally; provide a supported local-compaction fallback or provider/model override.
- Do not implement a global rule that discards assistant items from compact output, because the public compact contract allows retained items and instructs clients not to prune the returned canonical window.
Evidence and reproducers
The complete sanitized evidence is available in this public Gist. It contains:
- both reproduction scripts;
- the two-pass request/response arrays and summary;
- all nine redacted request/response pairs and the corrected per-pass summary;
- exact assistant-ID arrays and hashes, response IDs, HTTP statuses, and serialized-size measurements; and
- the separate direct-trace status and request-ID record.
2 Comments
Hi @davelindo, that rollout size is valuable stress evidence. Codex Rescue Alpha5 scans large local session histories with bounded memory and produces aggregate size, media, and compaction diagnostics without loading the whole file into RAM or dumping full payloads.
If you still have an affected closed rollout, you can test it locally:
No raw session upload is needed; sanitized aggregate output is sufficient.
One client-side observation to add to this (thorough) server-side evidence: the V1 compact-output path has no effectiveness check at all.
compact_remote.rsinstalls whatever canonical window the endpoint returns — it counts rewritten function outputs, but never compares the returned window's size against the input, so a compaction that removes zero assistant items is accepted silently and even recorded as a successful compaction. That matters because compaction triggers are context-pressure-driven: if the provider's policy retains everything, the session re-triggers compaction repeatedly at full context, each pass paying the compact call while the window monotonically grows (your 8→40 nine-pass series is exactly that trajectory).Regardless of whether Mantle's retention is intended, the client should defend itself: after installing the returned window, compare effective size (items/bytes/tokens) to pre-compact; if reduction is ~zero, surface a warning and either fall back to local compaction (
core/src/compact.rs) or stop re-triggering against that endpoint for the session. That converts a provider-policy question into a bounded degradation instead of unbounded context growth.