What one flick actually covers
A recap covers one flick, not everything above it. That is the part of the behaviour the interface never says out loud, and it changes what the number on the card means. This page writes it down, and then measures the thing that follows from it: how much of a flick actually reaches the model, and where that stops being all of it.
Every recap is a difference, not a running total
Flick from the top of an article down to 4,000 px and you get a recap of those 4,000 px. Flick again, from 4,000 to 8,000 px, and the second recap is of the new 4,000 px — not of 8,000, and not of the article. Each card describes the range between where you were and where you stopped.
The number on the card is that difference. “1,480 px” is the length of one flick, so two flicks of 1,480 produce two cards that say 1,480 and never one that says 2,960.
Re-summarising everything above you would mostly repeat what the previous card already said, and would spend the model’s budget on text you have already been told about. The question the product answers is “what did I just miss”, which is a question about an interval.
The interval is also filtered before anything is summarised: a paragraph has to overlap the skipped range meaningfully to be included, so text you actually read on the way past is dropped rather than described back to you.
How this was measured, and the run that was thrown away
A synthetic article — 18 px type, a 700 px column, paragraphs of about 420 characters — scrolled by a fixed distance, with the characters actually handed to the model counted against the characters inside the skipped range. Coverage is the ratio of the two.
The first run of this produced numbers that were not monotonic: 1,600 px appeared to send 850 characters while 4,000 px sent 2,560. Scrolling further cannot send less, so the measurement was wrong, not the product. The cause was the harness: the content script was evaluated again on every iteration, so each round left another copy listening to the same scroll events, each with its own memory of what it had already covered, and the counts mixed messages from earlier instances.
Every measurement below therefore runs on a fresh page. An earlier table comparing text densities came from the same broken harness and is withdrawn rather than corrected — it was never a measurement of anything.
Complete up to about 2,000 px
| Flick distance | Coverage of the skipped text | |
|---|---|---|
| 1,200 px | 100% | complete |
| 1,600 px | 100% | complete |
| 2,000 px | 90% | the knee |
| 4,000 px | 43% | sampled |
| 6,000 px | 29% | sampled |
| 9,000 px | 20% | sampled |
The knee is at roughly 2,000 px, and the default trigger is 1,200 px. An ordinary flick or two therefore sits inside the range that is covered completely. It takes a long continuous scroll — the wheel never stopping, the settle timer being reset over and over — to produce a single interval past 6,000 px.
Not fewer points. Wider spacing.
Past the knee the characters sent to the model level off at about 3,838 — the input budget, saturated. The number of points does not drop with coverage: a long flick still earns the top tier of seven.
What changes is what those seven points are drawn from. The paragraphs handed over are sampled across the whole interval rather than taken from its start — paragraph 0, 5, 10, 15, 20, 25 and so on, evenly spaced over the range. So 20% coverage at 9,000 px means nine paragraphs spread over the whole journey, not the first fifth of it. A recap of a long flick is thin, but it is thin everywhere rather than complete at the top and absent below.
The ceiling is the output, not the input
What follows by arithmetic, not by measurement: dividing the saturated input by the coverage above gives the size of the interval itself. A 4,000 px flick is roughly 21 paragraphs; a 9,000 px one is roughly 46. The output does not move — seven points of a sentence each, whatever the input was. So the compression the card has to achieve rises from about 5:1 at a 1,500 px flick to about 30:1 at 9,000 px.
Whether 30:1 is too much — whether seven points stop faithfully representing the interval somewhere along that curve — is a claim I have not tested. It is the obvious reading of the arithmetic and it is still a judgement, not a result. What would settle it: feed the full interval with the budget removed, and score how many of the claims a reader needed survive into the seven points. The evaluation harness from the Prompt API comparison is the right shape for it.
Which points at the honest conclusion, held as loosely as that implies: this is built for the 1,200 to 2,000 px flick, where coverage is complete and the compression is mild. Past that, more input has less and less to give — the constraint moves to the size of the card, and the card is the size of a glance on purpose.
Cut a long scroll into several cards
There is a fix that does not touch the budget: split a continuous scroll into intervals of roughly 2,000 px and emit a card for each, instead of waiting for you to stop and emitting one large one. Every card is then back inside the complete range.
The cost is more cards and more model runs for the same journey, which is a real cost on a device doing the inference itself. It is not shipped, and it should not be decided from this page: the numbers here come from one synthetic layout, and the density of a real site is not something to guess at.
Watch what the card says after one long flick on a page you actually read. If the points skip over a large block you know you scrolled past, the coverage number matters. If they do not, it does not.