Both of these surfaced the moment a config said 131072 while the pod was still
serving the 32768 it had been launched with -- a disagreement that is normal for
a few minutes after an edit, and which compaction has to survive.

**The summarizer was sized from the configured window.** It chunks the history
it is about to summarize to fit the summarizing model's context, and that number
came straight from the backend's configured value: 131072 against a pod serving
32768, so every summarization request overflowed too. The slicer then caught the
failure, left the oversized message exactly as it was, and compaction reported
that it could not help. It now prefers a window an engine has already refused
against, like the plan itself does.

**The head's size cap was waived for its first message.** The intent was to keep
at least one anchoring turn, but it meant a conversation opening with a pasted
45,000-token document kept that document verbatim as the head, dropped the rest
of the history, and overflowed anyway -- the one shape where compaction matters
most. An opening turn too big to keep belongs to the slicer, which summarizes
its middle.

Also says on the model page what the RunPod "Max context" field actually is:
the window the pod is LAUNCHED with, which the general context field above it
does not reach, which takes effect on the next pod rather than the running one,
and which the first model to create a shared pool sets for every model on it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S8LAP3ueNzQJtwzhgVbq66