Very frequent session compacting notifications when using hearoom with claude

[Depechie]

I'm trying to use headroom together with claude at our company.
The setup is a bit specific, we are connected to AWS Bedrock and not straight to Anthropic.
Secondly, I'm using the headroom docker setup, because I can't local install and use the wrap command.

Everything is configured in such a way that headroom will make the Bedrock connection and claude points to headroom.

It 'works', but I get almost instant compacting events. Making the setup not usable, because often I will even get a compacting failed event.

Anyone has any clever idea? Or maybe pointers on trying to find a possible solution?

[Depechie]

While I posted it here, I also tried to find the cause with Claude and we got through!

This turned out not to be a headroom issue at all, and the fix is a one-line change on the client side.
Posting the full diagnosis since I expect anyone putting headroom in front of Bedrock (or in front of anything, via ANTHROPIC_BASE_URL) hits exactly this.

TL;DR: Claude Code was giving itself a 180,000-token context window instead of 880,000. Adding a [1m] suffix to the model name fixes it. Same session, nothing else changed: effectiveWindow 180000 → 880000.

headroom-side requirement: headroom must tolerate the suffix. PR #3073 fixed [1m] stripping in get_context_limit() and landed in 0.36.0, so be on ≥ 0.36.0. On an older image, map claude-sonnet-5[1m] → your real model id via modelOverrides instead.

How to see it

claude -p "Reply with exactly the word: pong" --debug-file /tmp/x.log \
  --output-format text --no-session-persistence
grep -aoE 'effectiveWindow=[0-9]+|dispatching to [a-zA-Z]+ model=[^ ]+' /tmp/x.log

Always read the two values together. The dispatching to … line is the only proof of which route was actually live for that run, and pairing them is what caught a test run of mine that otherwise looked like a clean refutation.

Root cause

Claude Code decides its own context window client-side, before any request leaves the process - so headroom never gets a say in it. The bundled JS inside the native CLI binary is stored as plaintext, so grep -a on claude.exe (v2.1.246) recovers the real logic:

effectiveWindow = window − min(maxOutputTokens, 20000)   // reserve capped at 20000

// the ceiling:
wE(model, betas):
  if (/\[1m\]/i.test(model))                    return 1e6   // ← the fix
  if (betas.includes("context-1m-2025-08-07")
      && supports_1m_beta(model))               return 1e6
  if (Vo(model))                                return 1e6   // native_1m_3p[provider] === true
  …
  return 200000                                              // the default ceiling

Vo → QI(provider, ctx): switch (provider) {
  case "bedrock": case "vertex": case "foundry":
    return ctx.native_1m_3p?.[provider] === true
  case "gateway": return all three true
  default: return false }                                    // ← no "firstParty" case, ever

200000 − 20000 = 180000. That is the number I was seeing, exactly.

Why headroom triggers it. To route through headroom you drop CLAUDE_CODE_USE_BEDROCK (headroom does its own SigV4 signing upstream), so Claude Code sees a generic ANTHROPIC_BASE_URL plus a dummy key and dispatches as provider firstParty. QI has no firstParty case at all, so the capability check returns false and the ceiling collapses to the 200k default — for every model.
This is not Bedrock-specific: any OpenAI-/Anthropic-compatible proxy sitting on ANTHROPIC_BASE_URL will do the same thing.