pub const INTERVAL_CAP_BYTES: usize = 65_536;Expand description
What one interval of a document may carry into the window: 64 KiB, cut on a line end, continued by the offset the answer reports.
A different subject from a command’s cap, which is why it is a
different number. exec output cannot be continued, so its ceiling
is where loss becomes acceptable and the remainder goes to CAS.
read and search hand back an interval of something the caller can
ask for again, so their ceiling only paces delivery.
Derived, not chosen: the context reminders sound at 30% and at the
second rung — CTX_REMINDER_SECOND_DEFAULT unless a layer moves it
between CTX_REMINDER_SECOND_MIN and CTX_REMINDER_SECOND_MAX — and
a ladder means nothing if one result can clear a rung unseen. The gaps
one result must not cover are the second rung minus 30 into the first
rung, and 100 minus the second rung past the last: 35 and 35 points at
the default pair, so one result stays under 35% of the window. At 2.5
bytes per token, the worst realistic ratio (base64, hash-dense text),
64 KiB is 26.2K tokens: 20.5% of a 128K window, with 1.7x to spare.
128 KiB would be 41% and out. A rung moved off the default narrows one
gap below that: under 65 one result can spend the first rung unseen,
and over 65 one result can fill the window past the second while its
“still enough to write a handoff” claim is still fixed text — which is
the arithmetic the 90 ceiling of the legal domain is priced from.
Measured against this repository’s 928 tracked text files, the
bytes in their first 512 lines run p50 6,275 / p95 16,055 / p99
49,373 / max 73,978, so 64 KiB binds on one of them: it is a guard
against input that is not line-structured - a minified bundle, a
lockfile, a generated table - and not a tax on ordinary reading.
A usize because both readers compare it with the length of a text
in memory: with no conversion to write, there is no failed one to
read as “no ceiling at all”.