The floor is a diagnostic. A provider that cannot find 1,024 matching tokens caches nothing at all, not a partial hit [5]. So when hundreds of calls in one log record exactly that number, the longest matching prefix ran out just past the floor and the provider kept the smallest slice it is permitted to keep [12]. Prefix matching is byte for byte from the very first token, and it stops at the first character that differs [4]. Put a customer name about a thousand tokens in [13] and every token after it is dead weight, however stable that text is.
That sets a ceiling worth the arithmetic. The team's dev.to writeup says its prompt is several times bigger than the minimum [8]. Take several at three: 1,024 cached out of 3,072 prompt tokens is 33% [17], which is the best those calls could have scored with the name still in place, before anyone argues about server affinity. The reported blend was around 40%, with about a third of eligible calls caching nothing [8], and the split by direction was fifty points [9]. A fifty point gap around a 40% blend puts outbound below 40% and inbound above 50% [16].
Pre-warming is the part I would push on. Firing a throwaway request with the same system prompt before the call connects does work, and the team does it on every call [2]. What it buys is reuse inside one call: turn 2 reuses turn 1, turn 3 reuses turn 2, and once a call has made a couple of requests against the same machine the later turns fix themselves [15]. Turn 1 has no earlier turn in its own call to reuse [15], and most of their outbound calls never get past turn 1 or 2 [11]. The writeup does not say whether the pre-warm request carried that call's customer name. If it did, turn 1 should have matched, and the gap would have to come from the third condition, which is the machine the request landed on [6]. If it did not, the name accounts for the asymmetry on its own. The average was never the number either way.
For 24% and 40% to say anything about your agent, the prompt has to clear the provider floor [5], at least one per-call field has to sit inside the prefix [13], and your traffic has to be weighted toward one and two turn calls [11]. Break that last condition and the problem mostly self-corrects: on a ten turn call the average heals itself, and turn 1 becomes a rounding error on the bill. It is still the turn where the caller is sitting in silence, and prefix caching is worth hundreds of milliseconds of time to first token [14].
The byte-for-byte rule also makes the remedy mechanical rather than clever: everything that varies per call goes after everything that does not [4]. In my context I would ship that ordering change before touching the warm-up, because the reorder is a text edit and the pre-warm is an extra request on every call [2].
