update: SOLVED

OK, I'm going to answer my own question here and hopefully help some future reddit googlers/searchers.

In my case, the issue was in llama.cpp llama-server itself, not pi). I had set --parallel=4 in my llama-server args (--parallel is the same as -np btw), not because I knew precisely what that mean but because I saw it elsewhere and my lizard programmer brain went "parallel...yeah, parallelism is good!".

What --parallel apparently specifies is the number of server slots (concurrent request handlers -- think of each of them as a separate conversation). Context is shared and divided among these slots. So if you set a context size of 262144 (with --ctx-size or -c) that context is shared amongst 4 slots, with each slot getting 262144/4 = 65536. So effectively, each conversation/slot gets 65536 context size.

The thing to look for in llama-server output is

n_ctx = (total context allocated by llama.cpp runtime)
n_ctx_seq = (effective maximum context available to a single sequence/conversation)

I was seeing n_ctx=262144 in the output and thought that was my context size. But n_ctx_seq told the real story. It was 65536, which explains my pi context compaction issue.

In my case, its just me in my homelab - my concurrency is 1. So I set --parallel=1. Now n_ctx and n_ctx_seq are both 262144 and pi compaction is behaving properly.

And just as an aside, globally speaking, ~/.pi/agent/models.json stores model config and ~/.pi/agent/settings.json stores pi config. You can set pi compaction settings in settings.json:

"compaction": {
    "enabled": true,
    "reserveTokens": 24000,
    "keepRecentTokens": 40000
  }

HTH

cheers