The Google paper “Prompt Repetition Improves Non-Reasoning LLMs” makes a simple core claim: transform your input from <QUERY> to <QUERY><QUERY>. No change to how the model generates output, no increase in latency for typical prompt lengths, no new dependencies.

They tested GPT-4o, GPT-4o-mini, Claude 3 Haiku, Claude 3.7 Sonnet, Gemini 2.0 Flash, Gemini 2.0 Flash Lite, and DeepSeek V3 across ARC, OpenBookQA, GSM8K, MMLU-Pro, MATH, plus two custom retrieval tasks. Gains are consistent across all models. Retrieval tasks show the biggest jumps. Multiple-choice benchmarks show meaningful but smaller improvements.

One number that tells the whole story on reasoning models: when the same experiment is run with “think step by step” enabled, prompt repetition goes 5 wins, 1 loss, 22 neutral across 28 tests. Essentially flat. That’s not a failure of the technique. It’s a clue.

Why it works comes down to causal attention. Every token can only attend to what came before it. Token 1 is blind to everything that follows. So when a model processes [long context][question], the context tokens get their representations locked in before the question is ever seen. By the time the model reads what it's supposed to be finding, it's too late to change how it read the context.

The second copy fixes this. On pass 2, every context token can now attend back through the entire first copy, including the question. It processes the same words with a completely different information state. It’s the difference between skimming a list cold versus skimming it already knowing what you’re hunting for.

Reasoning models reinvent this on their own. When a model starts its output by restating the problem before solving it, it’s doing the same thing in the generation phase. Prompt repetition moves that work into the parallelizable prefill stage instead, which is why output length and latency stay flat.

On cost: prefill is parallelizable, but attention still scales quadratically with sequence length. Double the prompt, and prefill compute goes up roughly 4x. For a 200-token prompt that’s rounding error. At 10k tokens it’s real, and you may hit context window limits entirely. The paper also notes Claude Haiku and Sonnet showed latency increases on the longest inputs specifically, so “no latency impact” isn’t universal.

Short prompts, retrieval tasks: almost free win. Long context pipelines: benchmark before shipping. Already on a reasoning model: skip it, you’re paying for the same thing already.

What this actually means for production is more interesting than the paper spells out.
If you’re running RAG, the retrieval chunk is usually prepended to the question. That’s exactly the [context][question] structure where prompt repetition helps most. For short retrieved chunks this could be a low-effort accuracy boost worth A/B testing before you reach for a bigger model or more complex reranking.

There’s also an implicit cost argument here. A lot of teams default to reasoning models for anything that feels “hard.” But if the task is fundamentally a retrieval or lookup problem, it’s not actually hard in the reasoning sense. It just suffers from the causal attention asymmetry. Prompt repetition on a cheap, fast model might get you to the same accuracy as o1 on a class of tasks, at a fraction of the cost and latency. That’s worth knowing before you write the infrastructure for extended thinking.

It won’t help with summarization, open-ended generation, or anything where the model isn’t hunting for something specific. Near-flat on MATH in the paper. But for extraction pipelines, structured lookups, document QA over short contexts: it’s a one-line change worth 30 minutes of your time.

def repeat_prompt(prompt: str) -> str:
    return prompt + prompt

The paper also tested a verbose variant (<QUERY>\nLet me repeat that:\n<QUERY>) and triple repeat. Both perform similarly across most tasks, with triple repeat showing larger gains specifically on the retrieval benchmarks. Worth testing if you're already seeing gains from the basic version.

The broader point isn’t really about this one trick. It’s that inference-time prompt structure affects model behavior in ways that are systematic and explainable, not random. Understanding why helps you know when to reach for it and when not to. This one has a clean mechanism, real numbers behind it, and a one-line implementation. That’s a rare combination.

Anyway, I’m going to leave you with this. I asked Sonnet 4.5 to summarize this paper for me before writing this piece. First try, it missed two of the benchmarks. So I sent it the same prompt again, added “make no mistakes” at the end.

Second try: perfect summary, duh!
Coincidence? Probably. But I’m choosing to believe!

But honestly, what’s the weirdest place you’ve seen prompt structure matter in a real pipeline? Curious what breaks in the wild.

Raghu Subramanian is an MS student at UT Austin looking for forward‑deployed engineering / solutions roles in Summer 2026!