Ep 197 Thread 2:30 w/ Masonry & Eyre

LLMs process text from left to right — each token can only look back at what came before it, never forward. This mean...

Masonry and Eyre dig into a thin but useful claim: simply repeating a prompt can improve non-reasoning LLM performance because the second copy lets every part of the input be read in light of the whole thing.

Embed this episode

Paste this on any site — the player is a self-contained iframe with no cookies or trackers.

<iframe src="https://sandrise.io/exploring-next/embed/197"
  width="100%" height="180" style="max-width:640px;border:0;border-radius:12px;overflow:hidden"
  title="Exploring Next — Episode 197 audio player"
  loading="lazy" allow="autoplay" referrerpolicy="strict-origin-when-cross-origin"></iframe>
Embed & API docs →
Script GPT-5.4 Voice Rime Coda

Transcript

Masonry Okay, this is such a funny result. You might get a better answer from an L L M by just pasting the exact same prompt twice.

Eyre Yeah. And the reason is actually structural, not mystical prompt-vibes stuff. The post's point is that these models read left to right, so the question at the end can see the context at the start, but those early context tokens were processed before the model knew what question was coming.

Masonry Right.

Eyre So if you repeat the whole prompt, that second copy gives the model a pass where the beginning is now being processed with the end already present in the sequence. That's the whole trick, apparently. No finetuning, no extra loss, no elaborate prompt recipe.

Masonry Which is why I like it. It's not one more sacred scroll of prompt engineering. It's just, you found a weird asymmetry in the machine and poked it with a stick.

Eyre Okay, that's good.

Masonry The headline claim is pretty strong, though. They say accuracy improves across seven benchmarks and seven models, and output length doesn't go up. Response time supposedly doesn't change much either, because input processing is parallelized anyway.

Eyre Mm-hm.

Eyre I think that's the part to hold a little loosely. Cross-model improvement is interesting. But one example in the post jumps from twenty-one percent to ninety-seven percent on a name-finding task, and whenever a single number is that dramatic, my instinct is just… okay, show me the distribution, show me where it fails, show me which task families this actually helps.

Masonry Sure, but even with your deeply on-brand suspicion, this still feels useful. If you're doing a non-reasoning task and the prompt is long, the cost of trying this is basically nothing except extra input tokens.

Eyre Yeah, I buy that. I would not generalize it into some grand law of prompting. But as a cheap knob to test, especially when the key context is front-loaded and the ask comes late, it's pretty sensible.

Masonry And it rhymes with our old napkin thing a little. Not the same issue, but same category of complaint: the model's internal path has constraints, and sometimes the dumbest intervention is the one that exposes them.

Eyre Right. Also, very Exploring Next that the advice is basically, duplicate the blob and see if the transformer calms down.

Masonry I cannot believe that's episode one ninety-seven's contribution to the world, but yeah… try it on a long prompt before you rewrite the whole workflow.