irisandClaude Opus 5 797513bb86 Raise the compaction window to 200k
100k is the cheapest window on tokens and the wrong one to sit in front
of. Measured on the session this was written against: context returns to
70-85k within ten calls of a compaction, so a 100k window compacts about
every thirteen calls, and a compaction takes roughly two minutes
(durationMs 104,346 to 147,671 across the six recorded). A 130-call
request would have spent some twenty minutes compacting -- optimising
the number that was asked about while making the thing somebody actually
waits for on a phone considerably worse.

200k keeps most of the saving against the 1M ceiling and halves the
stalls.

The comment now also says what the window does not do, because measuring
this turned up the opposite of what the byte counts suggested. Images are
93% of the bytes that tool calls put into that transcript but only 8% of
the context growth -- the adb wrapper's downscaling holds a screenshot to
a median of 476 tokens, while text-only calls add a median of 740 and a
mean of 1,139. So the file is large because of screenshots and the
context is large because of ordinary tool output, and only the second one
is what this constant governs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VETa8afmpWaYezLCqJhDB8
2026-08-29 19:43:43 -04:00
2026-08-29 19:00:59 -04:00
2026-08-24 20:32:18 -04:00
S
Description
No description provided
27 MiB
0 Stars 1 Watchers 0 Forks
Languages
Rust 54%
Kotlin 43.6%
Shell 2.4%