31 July 2026

We made our prompt bigger, then measured where bigger stops helping

unPaper publishes one prompt that works with any AI. It carries an example deck, and we had been shipping a small one — ten slides — while the rules it came with named a dozen layouts the example never showed. We had already learned that a name without a worked example gets ignored, so we made the example bigger. Then the obvious question: how much bigger can it get before it starts doing harm to the small models most likely to receive it?

What we did

Three sizes of the same prompt — roughly thirteen thousand, twenty thousand and twenty-five thousand tokens of example — sent to four open-weight models people actually run, on two fixed briefs. Everything else was held identical, including the ceiling on how much each model was allowed to write back. So any difference is the size of the example and nothing else.

What we found

Digesting it was never the problem. Every deck came back complete. Not one was cut off, and speaker notes were present on every slide at every size. The worry we started with — that a longer prompt would overwhelm a smaller model — did not happen at all.

What scales is length. The bigger the example, the longer the deck: models roughly doubled their slide count between the smallest and largest example. They do this even though the instructions say, in as many words, that the example is a style reference and not a script to follow.

But the thing we actually wanted stops improving. The whole reason to show examples is so a model reaches for the right layout instead of defaulting to bullet points. Going from the small example to the medium one nudges that up. Going from medium to largest does not: the biggest example, twice the length of the smallest, produces decks that use no more of our layouts than the smallest one did. It buys length, not variety.

The risk our own test could not see

One model wrote 28,110 tokens of HTML on the largest example — 88% of the ceiling we allow in testing. Nothing was cut off here. But a chat window, or a model running on someone’s laptop, often stops far sooner than our ceiling does, and a deck that stops early is not a worse deck — it is no deck. That risk grows with the example, and it is a second reason not to ship the largest one even though it passed.

What we changed

The published prompt sits at the medium size. The largest version was built, run, and not shipped: it costs every user extra tokens, makes decks longer without making them better, and pushes models closer to a limit that varies by where they are running. Cheaper and no worse is an easy call.

Twice in one evening, a thin sample told us a better story than the truth

Two decks in the first pass came back truncated, both on a bigger prompt — exactly the result we had predicted out loud beforehand. It would have made a tidy finding. Checking why they stopped showed both had failed upstream at the provider; one of those models failed four separate times that evening, including on the smallest prompt of all. Nothing to do with prompt size. We now record the reason a generation stopped, so a provider having a bad night can never again be counted as damage our prompt did.

Then it happened again, to the finding itself. With those two failures excluded we were left with four complete comparisons, and they showed the largest example doing measurably worsethan the smallest — a sharper, more quotable result than the one above. We re-ran the missing pieces before publishing rather than after. With all six comparisons in, that drop disappeared: the largest example is not worse, it is simply not better. The original version of this page said “worse”. It was written from four samples and it was wrong.

How honest this is