diff --git a/README.md b/README.md
index fbaeec4..0924ff1 100644
--- a/README.md
+++ b/README.md
@@ -48,7 +48,9 @@ substandard shows a badge when the site you're visiting has a standard.site publ
   following and unfollowing stay on the profile the card links to. An account
   you have blocked never gets the line: blocking does not delete the follow
   record it supersedes, and a card that is already refusing to show someone
-  must not announce that you follow them.
+  must not announce that you follow them. No line is never "you do not follow
+  them": it is also what a signed-out popup, a failed read, and a follow list
+  past its 10,000 cap all look like.
 - The popup shows how many accounts subscribe to the publication, and the
   faces of the ones you follow. Subscriptions are public records in other
   people's repos, so the count comes from Constellation, microcosm's free
@@ -122,9 +124,9 @@ substandard shows a badge when the site you're visiting has a standard.site publ
 - Your follow list is the exception, and keeps for a day on disk. Nothing
   here creates or deletes a follow, so a stale set cannot hide something you
   did; and reading it is one request per hundred follows against your own
-  PDS, which is five hundred requests for an account following fifty
-  thousand people. That is not a walk to repeat every time the browser
-  restarts. It is the one value allowed on disk because of what it is not: a
+  PDS, up to a cap of 10,000 — a hundred requests. That is not a walk to
+  repeat every time the browser restarts. It is the one value allowed on
+  disk because of what it is not: a
   follow list is your own public social graph, and unlike the rest it records
   nothing about where you have been. The walk runs in the background worker,
   starting when you sign in, so no popup ever waits on it — the subscriber
diff --git a/TODO.md b/TODO.md
index 9277374..3d5965d 100644
--- a/TODO.md
+++ b/TODO.md
@@ -235,27 +235,29 @@ intersecting two lists, and both are capped:
   exact past that — it comes from the index's own total — but a followed
   subscriber past the cap is not drawn. `truncated` records this and the row
   says so in its tooltip.
-- The follow set comes from `listRecords`, which stops at 2000 records. An
-  account following more than that silently loses the tail, and unlike the
-  scan cap nothing reports it beyond the count `src/background.ts` logs.
+- The follow set stops at `FOLLOWS_CAP` (10,000 records, so a hundred
+  requests). `truncated` records this too, and the row's tooltip names
+  whichever cap could be hiding a face.
 
 The first cap binds on a publication and has not bound on any measured so far
-(the largest had 53 subscribers). The second binds on the *reader*, and now
-costs more than a face: the owner card's "Following" line reads the same set,
-so a reader with more than 2000 follows can be told they do not follow an
-account they followed early.
-
-Raising the second is cheaper than it was. The walk runs in the background
-worker and is cached for a day on disk (`graph` in `src/lib/cache.ts`), so its
-cost is once-a-day and off every render path; 2000 is a number inherited from
-when the popup did this inline, and the question is now how many requests a
-reader's own PDS should take once a day (a 50,000-follow account is 500) rather
-than how long a popup may hang.
-
-The alternative is to stop holding the whole set and ask about the one account
-in question — Constellation, or the reader's own repo by rkey. That answers the
-owner card directly; the subscriber row would need the reverse question, which
-of a publication's subscribers the reader follows.
+(the largest had 53 subscribers). The second binds on the *reader*, and costs
+more than a face: the owner card's "Following" line reads the same set, so a
+reader past the cap can be told they do not follow an account they followed
+early. Both now say when they bit, which is the part that used to be
+invisible; neither is fixed.
+
+10,000 is bounded by the MV3 worker, not by the PDS. The walk is once a day and
+off every render path (`graph` in `src/lib/cache.ts`), so the cost is fine, but
+a service worker only stays up while its event is being handled and a walk
+killed mid-flight caches nothing to show for it. Covering the tail above 10,000
+therefore wants a walk that can resume from a stored cursor across worker
+lifetimes, not a bigger constant.
+
+The other direction is to stop holding the whole set and ask about the one
+account in question — Constellation, or the reader's own repo by rkey. That
+answers the owner card directly and makes its cap irrelevant; the subscriber
+row would need the reverse question, which of a publication's subscribers the
+reader follows.
 
 ## Let the user manage their labelers