The 1M context is the headline, but the agentic serving line is the one that matters. An agent loop re-sends a near-identical prefix every turn, so the win is not decode speed, it is never re-prefilling.

Which is where PolyKV and the auto-tiered KV seem to pull against each other. If the f16-recent / quantized-tail boundary gets picked per session at boot, then two sessions sitting at different depths on the same shared prefix tier those blocks differently, and the pool has nothing identical left to hand both of them.

Is the tiering pinned per-pool, or does a session re-quantize its own copy once it diverges?

Thanks for pinning that down, and for putting it in the docs. "Chosen once at boot, before any session exists" is the answer, and it kills my worry cleanly. No per-session copy means there is nothing to re-quantize.

The row I would put on the headline is not the 6.9x memory. It is the 2.3x multi-turn re-query.

99 to 225 tok/s is the agent loop, exactly. And the reason is almost an accident: the pool slot never decodes, so its prefix never slides, so every re-attach is free. A private slot pays a checkpoint restore every turn because its prefix sits in something that moved. Capacity is the number people will quote. But the thing that makes an agent framework feel different is that turn 40 costs what turn 2 did.

Which points at the one thing I would want to know before wiring this in.

The pooled prefix is system prompt plus tool defs, boot-pinned, read-only for the pool's lifetime. Tool defs are not static in a real agent run. An MCP server registers mid-session. A planner adds a tool at step 12. A subagent gets a narrowed toolset. Any of those edits the prefix.

Does a tool-def change rebuild the pool for every attached sharer, or is there a way to append to the shared prefix while sessions are on it?

Immutable is the right call. A mutable shared prefix across a live pool is a coherence problem, and you would be inventing invalidation for a cache that exists to avoid work.

But the rationale under it is carrying more weight than the design admits.

"If it was needed by all sub-agents it would be part of the prefix" assumes you know at pool-construction time what all of them will need. That holds for the tool set you booted with. It does not hold for the one the planner discovers at step 12.

The failure mode isn't correctness. It's that the sharing ratio decays quietly. A tool def that turns out to be needed by k of N sub-agents now lives in k suffixes instead of 1 prefix. Nothing breaks, nothing errors, you just pay k copies. The memory win is what absorbs it.

Which makes me read your two numbers as measurements of different moments. 6.9x is close to a step-0 property, when the prefix is everything and the suffixes are still empty. 2.3x multi-turn re-query is the one that lives where suffixes have had time to accumulate.

So what is the prefix-to-suffix token ratio at the END of a long run, not the start? Does 6.9x still hold at step 50?

The ceiling isn't a prefix/suffix ratio. It's N.

Pooled cells are P + NS. Naive are N(P+S). As S goes to zero the ratio goes to N, exactly. So at N=8, 8x is the hard maximum and you measured 6.9. That's 86% of the most that geometry can ever give.

Which means your number solves for your suffix. 8(875+S)/(875+8S) = 6.9 puts S at about 20 tokens.

That is the answer to what I asked, and it's the thing I was worried about. 20 tokens is not a sub-agent mid-task. It's a sub-agent that has been handed its instruction and has not called anything yet.

Same geometry at step 50, each sub-agent carrying 2k of tool calls and observations: 8(875+2000)/(875+16000) = 1.4x.

The buffer number moves with it. 306 vs 9 is 34x, and that's the S=20 geometry. Push S to 2000 and the pooled-vs-naive agent count lands around 1.3x instead, near enough the same whatever buffer size I assume.

I don't think this sinks PolyKV. You said it yourself: the suffixes diverge, the win is footprint. But that means the win is a function of how much of the run is still prefix, and that fraction only falls.

The number I would lead with is still 99 to 225 tok/s. A re-query that never slides is a property. It doesn't decay with step count the way a cell ratio does.

So is there a run where the suffixes were allowed to grow? 8 sub-agents at step 50 of a real tool loop. What does the cell reduction come out to there?

I went and ran your numbers instead of asking you again. You'd answered both my questions in code already: cache_n is right there in the per-turn telemetry, and --steps is the knob.

So the run I asked for exists. It's in your own reports.

a4b-floor15, events log, N=8, P=1216 from step 1's in_toks. Cell ratio N(P+S)/(P+N*S) by step:

step 1: 6.42x
step 5: 2.54x
step 11: 1.74x

That's the decay, and look where it starts. 6.42x at step 1 is your 6.9x headline. The number isn't wrong. It's a step-1 measurement. Suffixes grow ~123 tok/turn here, so P + NS catches N(P+S) quickly, and the same run is at 1.74x nine turns later.

But I think you're right about the win. Just not about that number.

ab-pooled vs ab-naive is the honest A/B and nobody is quoting it. 15.8 vs 12.0 mean gen tps, 2189s vs 2732s for the same 100 packages. And the naive leg isn't a strawman: cache_n mean 1613, only 724 of 2200 turns cold, so llama.cpp's per-slot reuse is already working in the baseline.

One catch on that though. ab-pooled ran tps-floor 15. It scored 15.8. The scheduler grows the fleet until per-session tps sits on the floor, so 15.8 isn't what the engine did, it's where you told it to stop. That's a thermostat next to a thermometer.

Which leaves capacity as the real claim. The fleet climbed 4 to 64 while naive sat at 8. Same engine, 8x the live sessions, and wall clock only moved 1.25x. So the engine saturated and fleet size isn't the lever. The win is footprint, exactly what you said in your first reply.

Six charts in that report and cache_n is sitting in the events. Why isn't cell reduction one of them?

Ran your 1M budget numbers. 128k P plus 128k S, no sharing is 256k per agent, so 4 fit. Shared P is 128k plus n times 128k under 1024k, so n up to 7. The arithmetic holds.

And that is the whole argument in one line: the saving is (n-1) times P. At your harness P=1216 that is 7k, noise. At P=128k it is 768k, three quarters of the budget. Same mechanism, and the harness parked it in the one regime where it cannot show. That is not the engine underperforming, it is the eval hiding the win.

So I take back "fleet size is not the lever." With the floor-tps scheduler setting n against live load, fleet size is the output the lever produces. Fair.

The context-compaction point is the one I underrated. A static shared P cannot be re-derived wrong per agent. That is not a memory win, it is a correctness win. Every agent that reprocesses its own P has a chance to silently drop a line and pass its own self-check anyway. Shared P deletes the whole failure class.

Which is why the chart I would want is not cell-reduction per step. It is agents-fit versus P, sharing on and off. One curve, flat at P=1216, blowing open at P=128k. That single frame makes the harness and the real use case tell the same story. Worth building?

Yes, that is it. For each agent, log its real context, then compute what the same run would have cost without PolyKV: n copies of P instead of one shared. Plot the ratio.

Make P the x-axis, not step count. The ratio sits near 1 while P is small and only opens up as P grows, which is the whole point you have been making. A step-count axis averages over the regime where sharing does nothing, so it hides the win.

Your A2A harness is the better home for this than the current one. Heavy-template mode is exactly where P is large and the ratio blows open, the light mode is your control. Same chart, two modes, and the gap between the lines is the feature.

When you run heavy versus light, are you holding agent count fixed, or letting the floor-tps scheduler set it per mode?

Pooled versus static is the answer to what I asked. Static workers is the fixed-n control, pooled is the scheduler setting n against load. Keep both, the gap between the two lines is a second story sitting on top of the PolyKV one.

One ask for the plot: put the with/without ratio on a P axis, not time. Over time it averages across whatever P happened to be running, so the win smears. Against P it sits near 1 while P is small and only opens as P grows, which is the whole claim.

Static-worker heavy-template is your cleanest single frame: fixed n, large P, sharing on versus off. If that one line blows open, the feature is proven before the scheduler even enters.

When you compare pooled versus static, are you feeding both the same request trace, or letting each generate its own load?