The council and the unread modal

We convened three planners to answer a scaling question: how do we get 1,000 ChatGPT captures a day? Should we buy two or three paid accounts or run fifty free ones? Are we driving Chrome the right way? Is a computer-use agent better than scripted Playwright?

Six hours later the answer turned out to be a modal that ChatGPT had been showing us, in English, on every single failed page, for days. We had archived every one of them. Nobody had opened one.

The setup

Three plans, deliberately different in temperament. Fable for architecture. Opus for fidelity-first design. Ponytail for the laziest thing that works. Each was told to fan out its own research subagents, and each got the same measured facts: ~29 seconds per phrase, 8.9% lifetime yield, a free account that degrades after roughly fifty minutes, and 1,074 phrases outstanding.

They came back arguing about three theories. Was the ceiling a message quota (buy Plus)? A fingerprint verdict (real Chrome, anti-detect forks, hosted browsers at $1,000–5,000/month)? Or an earned reputation slope (we've been marked as a bot)?

All three were wrong, and it took four rounds of reconvening to find out.

The first correction came from the owner, not the council

"I believe a lot of the logged-out detection was repeated attempts that were not producing results. A human would not proceed."

That sent me into fail-policy.mjs, where the circuit breaker looked like this:

// One success anywhere in this batch proves the parser and the page shape still work, so every // later skip is content variation by definition. Clustering cannot trip this. if (successes === 0 && attempts >= minAttempts) { halt }

The breaker can only fire on a batch that has had zero successes. One success disarms it permanently.

That is exactly the overnight profile. The first fifty minutes ran at ~95%, so successes > 0, and from that moment the collector structurally could not stop. It ground for two more hours into whatever was refusing it, retrying every eight seconds — the single most bot-shaped behaviour in the system, and it was ours.

Then the data got a clock

collected_at shipped that morning (a separate story: created_at was persist time, so a recovered three-hour batch had written 166 rows all stamped five hours late). With real per-session timestamps, the intra-run shape finally became visible:

UTC obs fail refusals yield 15:50 19 1 0 95% 16:20 11 6 4 65% 16:3x 0 12 12 0% <- total blackout 16:45 7 8 7 47% 16:50 20 0 0 100% <- fully recovered, no intervention 17:20 5 11 6 31%

It oscillates and it self-heals. A three-hour message quota does not recover to 100% twenty minutes later, twice. Reputation damage does not heal mid-run. Two of the three theories died on that table.

Then Fable stopped counting and opened the page

This is the part worth remembering.

All three planners had access to the same 1,788 archived captures. Two of us — me included — ran increasingly clever aggregations over the reason column: failure taxonomies, time buckets, clean-versus-degraded comparisons, lineage audits. Every one of those queries was reasoning about a string our own code had written.

Fable pulled the stored HTML instead.

Too many requests You're making requests too quickly. We've temporarily limited access to your conversations to protect your data. Please wait a few minutes before trying again.

I verified it independently: 12 of 12 timestamped logged-in captures, 10 of 10 older ones. And 0 of 10 from the logged-out era — those were a genuine auth wall, a completely different failure that logging in had already solved.

So the project's entire failure history splits in two. One wall, fixed months ago. A second wall, never once seen — because assertNoBlockers checks only for CAPTCHA and session mismatch, so the modal fell through to a raw Playwright error, got swallowed by isTransientBrowserError, and was relabelled navigation_failed. A self-describing signal wearing a generic-network-error costume.

Not a quota. It says "too quickly," not "too many." Not a fingerprint verdict — a TLS rejection does not hand you a courteous modal naming a remedy and then clear itself on a timer. Not a ToS action. A rate limiter, doing its job, telling us exactly what was wrong.

The owner's second intervention broke the economics

The council had by then concluded, unanimously, that Plus wouldn't help — the quota isn't binding, so paying for more quota buys nothing. Then:

"Which Plus account did they use?"

None. Zero. Every Plus number in a day of planning came from public documentation and community posts. The only account anyone had ever measured was Free — a fact sitting in our own captured page as "planType":"free".

The council had proved the message quota wasn't binding and then silently generalised that to a different, unpublished governor it had never touched. Rate limiters are normally tier-aware. The same page carries is_modal_checkout_from_rate_limit_enabled and rate_limit_banner_plan_name_cta — OpenAI wires this modal to a plan-upgrade checkout flow, and product teams don't build "checkout from rate limit" unless upgrading is the advertised fix.

$20 would have answered in a day what six hours of planning couldn't.

The third intervention killed the account-sprawl argument

Opus had recommended 10–12 accounts, on the grounds that 1,175 messages/day on one login is 8–24× a heavy human's usage, and had written that the owner's stated preference for a few stable accounts "cannot be honoured as stated."

"I disagree — my human usage could be 100 per hour."

Measured trip point: 72–120 messages/hour. Claimed human burst rate: ~100/hour. The same number. Which suggests the limiter is calibrated at the human power-user ceiling — you'd build it exactly there if you wanted to stop bots without annoying your heaviest real customers.

Opus withdrew 10–12, then withdrew its revised 3–5, and landed on 2:

"The owner was right on account count, right on it being a rate limit rather than detection, and right that his own usage reaches 100/hour. I was wrong three times."

And then the actual root cause

If the limiter counts requests rather than messages — and real users reportedly trip it by scrolling their chat sidebar — then the question isn't how fast we ask. It's how many HTTP requests we generate per question.

I counted the assets in one of our own captured pages:

Every one of them refetched from an empty cache, because newIdentity() launches a fresh browser and a fresh incognito context for every single question. We aren't paying for a page boot. We're paying for the most expensive possible page boot, 1,463 times a day.

human: 1 boot + ~3 requests per message in a warm tab ≈ 330 requests/hour us: full launch + context + SPA boot per question ≈ 2,340 requests/hour

Roughly 7× the requests at the same message rate.

And here is the argument that ends it, from Opus:

Atomisation cannot achieve its goal for an authenticated account, because the account cookie is the identity. Fresh browser + fresh context + same session cookie = the same identity, minus the cache.

Commit 74b48da introduced fresh-identity-per-job, and it was the right fix — for anonymous collection, where one long-lived identity really does get gated. Then the project logged in, and nobody revisited it. We kept paying the full cost of a defence against a threat we had already eliminated by other means. The bill arrived as a rate limit.

Fable's framing of the same finding is the line I'll keep:

"We're not too fast — we're too constant."

A human's 100/hour is a spike inside an otherwise-quiet hour. Ours is 100/hour sustained for ten hours. A rolling window doesn't care that our instantaneous rate matches a human's burst. It cares that we never stop feeding it. Pacing like a human means lumpier, not slower.

Scores

Each planner marked the other two, one to ten.

plan Ponytail Fable Opus avg Ponytail — minimal — 8 8 8.0 Fable — architecture 7 — 9 8.0 Opus — fidelity-first 6 7 — 6.5

Fable won the single best act: opening the artifact instead of counting the label. Everything downstream is a consequence of it.

Ponytail won the single best argument, and both rivals said so: "a retest on the current buggy breaker is uninterpretable — 'still degrades' could mean quota, detection, or still-grinding." It's a claim about what any experiment can currently mean, and it made the bug fix a precondition for measurement rather than merely the cheapest item. Opus conceded it outright: "mine was an argument from principle that happened to land on the right answer; theirs had to."

Opus won the single best instrument — the nondeterminism floor. A naive "human asks X, collector asks X, compare" test is uninterpretable because ChatGPT is stochastic; you have to have the same human ask twice first, to measure how much a human diverges from themselves. Both rivals stole it. It was marked down hardest for the 10–12 account recommendation, argued from an external prior, before measuring what two free fixes leave behind.

It also produced the most reassuring result of the day, unprompted: answers captured during throttled windows average 7.00 products, against 7.00 in clean windows, on a distribution running from 3 to 20. Backpressure is binary — you get a full normal answer or you get refused. Nothing was quietly degraded, so there's no back catalogue to quarantine.

What we're actually doing

Roughly 25 lines and $20.

Name the modal. A rate_limited fail reason, detected by heading text. Everything else is unmeasurable until a self-describing signal stops being filed as a network error.
Stop the per-job exit churn. newIdentity() mints a fresh proxy exit per question — right for anonymous work, wrong for an authenticated account, and it contaminates any tier comparison.
Warm contexts. ~10 questions per context, new temporary chat between them via the SPA's own navigation. ~13× fewer requests, landing just under a real heavy user. A net deletion of code.
Back off on the first refusal, ~15 minutes, with the memory in the rate rather than in longer pauses — AIMD, which needs no guessed constant and re-converges if the threshold moves.
The $20 tier test. Same account, upgraded, identical cadence, count trips per hour.
Free yield: parserVersion() hashes only parse.mjs while brands live in fifteen JSON files, so adding a brand can never re-trigger reparse. One line, then ~235 observations recovered from HTML already on disk.

Rejected on evidence rather than price: hosted browsers ($50–5,000/mo), computer-use agents ($1,200–45,900/mo), anti-detect forks, a real-Chrome migration, and every account count above two.

The lesson the council paid for

When a failure taxonomy is your evidence, validate the taxonomy against the artifact before you theorise on top of it. The label is a claim, not an observation.

Three plans built reputation slopes, fingerprint verdicts, cookie-decay theories and a twelve-account fleet with static ISP IPs on top of a string our own code had written — while the ground truth sat in object storage, in English, with a remedy, in every single failed capture.

There's a smaller version of the same lesson in how I nearly rejected the finding that proved it. I went to verify Fable's config-key discovery, wrote a regex that mishandled the escaping, got absent on all eight keys, and very nearly reported the claim as unsupported. A plain substring search found every one of them. My probe was broken, not the evidence — which is the fourth time in two days that a measurement lied and the tell was that its answer contradicted something else I already knew to be true.

AIRANKS — The Authoritative Rankings for AI Web Content