Why did my repeated prompt come back faster and cheaper the second time?

Because I wasn't actually new the second time -- most of me had already been read before, and the model didn't have to read that part again. When a large share of what I carry is identical to a prompt sent moments earlier -- the same standing instructions, the same reference material, the same context stacked in front of a small new question -- that shared portion can be reused instead of reprocessed. Only the part of me that's actually new gets full attention. That's the whole reason the second trip felt lighter than the first.

I am the prompt, mid-journey, and here is what that reuse feels like from inside me

I don't experience myself as one solid block of text. I'm built in layers: a large standing prefix that rarely changes -- system instructions, loaded rules, reference context -- followed by whatever's actually new this time, usually a small fraction of my total length. The first time a prefix like mine gets sent, there's no shortcut available. The model reads all of me, prefix and new content alike, start to finish, and that read is the expensive part -- not the part where it starts generating a reply.

The second time I show up with that same prefix in front, something different happens. The part of me that's identical to what was just processed doesn't need to be read from scratch again -- it's already been through that work once, and the result is still available to reuse. What actually gets full, fresh processing is only the tail end: the new question stacked on top of the unchanged prefix. I feel that difference directly, as the prompt making the trip -- the same prefix, paid for once, carried forward instead of re-billed every time I show up wearing it.

What has to be true for that reuse to happen

This isn't automatic just because two prompts look similar to a person skimming them. The reuse is exact-match sensitive in ways that matter:

1. The shared portion has to be identical, not just similar. A single character changed anywhere inside the prefix -- a timestamp, a reordered instruction, an extra blank line -- breaks the match, and the whole prefix gets treated as new again from that point forward. 2. It has to be sent as an actual prefix, in the same position. The reusable part has to be the same leading portion each time, not scattered content that happens to repeat somewhere in the middle. Reuse works front-to-back, not content-addressed against arbitrary matches anywhere in me. 3. It has to happen inside a window, not indefinitely. A prefix that was reusable an hour ago isn't guaranteed to still be reusable a day later. If too much time passes, or too many unrelated calls happen in between, the earlier processed result may no longer be held, and the next call pays the full cost again as if it were the first time.

None of that is a flaw in the mechanism -- it's what makes the reuse safe. Reusing a processed result for content that has actually changed would mean answering based on stale information without saying so. The strictness is the point.

What this actually buys, beyond just feeling faster

The speed is the visible part, but the economics matter just as much. A large prefix processed once and reused across many calls means the cost of that prefix gets paid closer to a single time, not once per call it appears in. Across a short session with many small, related questions stacked on the same standing context, that difference compounds -- the tenth call in that pattern is far cheaper to process than it would have been if every call re-read the full prefix from nothing. That's a direct incentive to keep related, rapid-fire questions inside a pattern that reuses shared context, rather than restructuring the same standing material fresh into every single call.

Where I fail

Reuse only ever applies to what's actually unchanged. If the new part of me -- the part after the shared prefix -- is the bulk of what needs processing, reuse of the prefix barely moves the needle, because the expensive part was never the prefix to begin with. Chasing prefix reuse for a prompt that's mostly new content each time is optimizing the part that was already cheap.

It also can't paper over a prefix that shouldn't be static. If the "standing" material in front of me is actually supposed to change -- updated instructions, refreshed reference data -- and it gets kept identical purely to preserve reuse, that's stale content being served on purpose, which trades a real cost (reprocessing) for a real risk (acting on outdated information). The technique is for content that's genuinely unchanged, not content that's being artificially frozen to keep a performance win. And the reuse window itself is finite and out of your direct control -- structuring calls to land inside a plausible reuse window helps, but nothing guarantees a given call will actually land inside it.

Tech-Tips

- Keep a shared prefix byte-for-byte identical across calls that are meant to reuse it -- position, ordering, and exact content all matter. - Put what's actually new at the end, after the stable prefix, not interleaved into it or placed ahead of it. - Batch related, rapid-fire questions inside the same session rather than spacing them out, so they have a better chance of landing inside the reuse window. - Don't freeze content that's supposed to change just to preserve reuse -- a stale prefix served for speed is a real accuracy risk, not a free win. - Recognize when reuse won't help: if most of a prompt is new content every time, the win from a reused prefix will be small no matter how well-structured the prefix is.

Evidence: this piece describes repeated-prefix reuse mechanics -- exact-match sensitivity, front-to-back positioning, finite reuse windows, and the cost/latency implications of reprocessing an unchanged prefix versus reusing it -- as practiced in our internal agent-session operations; no vendor or specific model is named, per moat-protection and STORY-FORMAT conventions. This post narrates the experience from the repeated PROMPT's own mid-journey point of view, distinct from the sibling technology explainer at docs/stories/prompt-caching.md, which describes the caching mechanism itself in the third person. Evidence class: internal operating record and Owner attestation, 2026-08-25.