Nobody reads to the end. Build for the part that quits early.

A frontier model shipped this month with a number that’s easy to skim past and worth stopping on. Google’s Gemini 4 Argon, previewed at the start of October, raised its output ceiling to a million tokens — not how much it can read, how much it can write in a single go. For scale, that’s several times the output limit of the models it’s competing with. A machine can now hand you a book’s worth of answer to a question you asked in a sentence.

Here’s the thing nobody on the launch slide says out loud: you will not read it.

Not because you’re lazy. Because of how the mind handles a pile too big to finish. In the 1950s Herbert Simon put a name to it — satisficing, a splice of satisfy and suffice. His argument, which won a Nobel and has aged extremely well, is that people don’t optimize over every option and weigh them all. We can’t; the world is too big and attention is too small. Instead we set a rough bar for “good enough,” search until something clears it, and then we stop. Not the best answer. The first acceptable one. Simon called the broader idea bounded rationality: real minds reason inside hard limits on time, information, and attention, and they’re built to cut the search short.

Which means the constraint that just got lifted off the model landed squarely on the reader. The expensive, scarce resource in that transaction was never the model’s capacity to generate. It’s the human’s capacity to attend — and the human is a satisficer who will bail the instant the answer feels good enough, somewhere in the first screen, long before token nine hundred thousand.

If you build with these tools — and increasingly, if you build anything that returns a block of text, a list, a report, a diff, an explanation — this is a design brief, not a trivia fact. A satisficer is coming to your output, and they will stop early. You can fight that and lose, or you can build for it.

Building for the satisficer is mostly one move repeated: put the load-bearing thing where the search ends, not where the logic ends. The model’s instinct (and, honestly, ours when we write) is to build the argument and deliver the conclusion last, like a proof. The reader’s instinct is to read the first acceptable chunk and leave. So lead with the answer. Then the one reason it’s probably right. Then — for the minority who keep going — the depth, the caveats, the work. Invert the pyramid every time there’s a chance the reader stops.

The second move is to make the “good enough” bar cheap to clear honestly. Satisficing is only dangerous when the first acceptable-looking answer is wrong and the reader has no way to tell. So give them the tell: a visible confidence signal, a “here’s what I’m unsure about” line, a one-glance way to spot that this is the case you shouldn’t trust. You’re not trying to make them read more. You’re trying to make their early stop a safe stop — raising the floor on the answer they’ll actually consume, which is the top of the thing, not the bottom.

The temptation with a million-token ceiling is to use it — to let the model pour, because it can. Resist proportionally. More output is not more value delivered; it’s more raw material placed in front of a mind that was going to stop at good enough anyway. The win isn’t the length you can produce. It’s how little of it a satisficer has to read to get the thing right.