Five hundred at once

Nothing was filtered first

Every cell above is one story, and every one of them was judged: the 500 newest submissions to Hacker News, roughly the last eight hours, with no keyword filter and no shortlist taken from them. The whole board is read on its own merits. That is only possible because judging is cheap enough not to bother economising: five hundred stories, three questions each, fifteen hundred judgements, for under half a cent.

They arrive in four requests fired at once. Measured against the live API while building this: thirty questions in a single call took 1.1 seconds, four hundred and fifty took 2.3, and six hundred took 2.6. Latency grows far more slowly than question count, because the stories are read once and every question runs against them in parallel. Filtering first would save almost nothing and would lose whatever the filter threw away.

Then change your mind, for free

Drag any weight under What you care about, or change how much you have time for. The whole board re-ranks under your hand and the counter stays at 0 calls, $0.00 — because the judging already happened and its answers are sitting in memory. Re-ranking is arithmetic over numbers you already own.

This is the part a language model cannot do. Ask one for a relevance score and you get a number it wrote — bimodal, tied by the thousand, with no distribution behind it. You cannot slice rank seventeen out of that, and re-thresholding it is superstition. A Score answer here is a probability-weighted position across levels the model was shown, which is what makes the dial mean something rather than merely move.

Writing a new question would cost another sweep, and the interface would say so. Moving a weight never does.