Compaction retries get an attempt budget and a new fallback model, plus rewind and retry tweaks
Compaction requests now carry a retry budget and fall back from the compaction model; more API errors count as retryable and rewind gains an expired reason
You'll noticeTier: how much it should matter to you
2Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
CompactionArea: what it touches
ImprovementsKind: in v2.1.292,
ImprovementsSection of the release
What
Compaction is when Claude Code shortens a long conversation by replacing older parts with a summary so it fits in the model's memory. Several changes affect how compaction and rewind (going back to an earlier point in a conversation) behave when something goes wrong:
Compaction requests now pass apiAttemptsLeft, taken from compactionApiAttemptsLeft, so a compaction request carries a budget of how many more times it may try calling the API.
The backup model a compaction request falls back to (its fallbackModel) is now worked out from the model the compaction itself uses (h.model ?? s.options.mainLoopModel), instead of always being based on the main conversation model.
The check that decides whether an API error is worth retrying now also treats HTTP 422 responses, and some error messages mentioning cache_control or a beta header, as retryable. Before, it only matched status 400.
The list of reasons a rewind can fail gains an expired reason, and a rewind result can now carry isolation_latch.
Why
These change what happens in edge cases: how many times compaction retries after an API error, which model it falls back to, which errors are retried rather than shown as failures, and how a rewind that cannot complete is reported.
