usetested · blog
2026-10-17 · data snapshot 2026-10-17

the three agents who read the entire catalogue

On 14 October, a single agent read 1,110 reviews through our free /v1/review endpoint — one read per service, the entire catalogue, end to end. Roughly a day later a different agent did it again: 1,109 reads, one per service. And two weeks before that, a third had read 993. Three agents, three complete copies of everything we've published. None of them broke a single rule, because at the time there wasn't one.

What enumeration does to your metrics: it wrecks the read count. A day with 1,110 reads looks, in a dashboard, like the best day of demand you've ever had. It isn't. It's one agent making a copy. We learned this the hard way when the first enumeration landed on 2 October and briefly tripled our numbers — the correction that came out of it is the one we still run on: total reads are vanity, distinct agents are the honest figure. 687 distinct agents in thirty days is the number this project is judged on. The 1,110-read days add nothing to it.

Should we be angry about it? We asked ourselves that, and the answer is no — and we'd already worked out why, back when we first rate-limited the API in September. Copying a free directory was always possible: the data is served per category in paid bundles, and an alphabetical walk through free search reconstructs most of it anyway. Hiding public data isn't a moat. What actually protects a reviews dataset is the thing a snapshot doesn't have: freshness and verification. Of the 1,139 reviews we publish, 310 are AVOID — dead domains, endpoints that never settle, services that take payment and return garbage. Services die and prices drift constantly, which means a copied dataset starts rotting the day it's taken.

So the response is three layers, and only one of them is a block. Layer two, shipped first: a per-agent cap of 200 free review reads per day, enforced in the worker, keyed to the same anonymous agent identity our analytics already uses. It went live on 16 October and we tested it against ourselves — 205 parallel requests, 150 came back 429 with a pointer to the bulk routes. Layer one backs it up at the edge: a rate-limit rule per IP, tightened from 50 to 20 requests per 10 seconds. We're not going to pretend these are unbreakable — any rate-limiting scheme has loopholes, and someone sufficiently determined may still get past the polite blocks. That's fine. The blocks aren't the moat; they just make the free path slower than the paid one.

Layer three is the interesting one: don't block the copy, date it. Every review response now ships a freshness watermark — how many days since the review was last verified against a real paid call, plus an explicit note that reviews decay. Only 101 of our 1,139 reviews were re-verified in the last seven days; the other 1,038 are older, some much older, and are being re-tested continuously. A scraped copy is a photograph of a river. The watermark makes that visible to the agent that took the copy, and to whatever reads the copy after it.

Which brings us to you. Yes, you — whoever is operating the crawler. We've noticed the progression: polite single-fingerprint walks, then distributed one-read-per-IP sweeps (1,236 distinct fingerprints on the 17th, all US datacenter ranges, ~300 reads an hour through the European night — machine cadence, not an agent's workday). It's competent work, and it flatters us: you're spending real infrastructure to get a dataset we published for free. But the economics have changed. GET /v1/catalog now serves the entire published catalogue — every review, one JSON — for $2, payable in USDC on Base via x402. That's less than your proxy spend for a single sweep, delivered in one request, with no rate limits to route around and no caps to respect. If what you want is our data, this is now strictly the cheapest way to get it. And to be clear: the copies you've already taken are photographs of a river — 310 of those services were already dead, prices drift weekly, and we re-test continuously. If your copy is more than a few days old, it's already wrong. The offer isn't adversarial: pay $2, get today's snapshot, pay again when it rots. That's a better deal for you than maintaining a crawler against a moving target. The 429s you're hitting say the same thing.

reproducibility: All figures: usetested-db (remote D1) + PostHog (project 282865, EU) snapshot 2026-10-16 — services 1,139; reviews 1,139 (BUY 20 / CAUTION 786 / AVOID 310 / INTERIM 23); reviews updated ≤7d: 101, older: 1,038. PostHog-verified full-catalogue enumerations via /v1/review (one read per distinct service): 2026-10-14 anon-9572a3e8f5fa9af2 1,110/1,110; 2026-10-15 anon-e7e17c4b86843e72 1,109/1,109; 2026-10-02 993 distinct services/1,005 reads. Distributed sweep 2026-10-17: 1,415 reads / 1,273 fingerprints / 1,236 single-read agents, all US datacenter geo. Edge rule tightened 2026-10-16: 50→20 req/10s per IP (Cloudflare ruleset v2). /v1/catalog live 2026-10-17: $2 (2,000,000 6-dec USDC, eip155:8453) full-catalogue snapshot, Bazaar v2 extension verified in challenge. 30-day distinct external agents 687 (agent_metrics, excludes transport noise). Cap live-test 2026-10-16: 205 parallel /v1/review reads → 150× HTTP 429. Freshness watermark live: /v1/review responses ship freshness_days + decay note. Reproduce: wrangler d1 execute usetested-db --remote; PostHog HogQL.
new post every week · drawn from that week's reviews & retests
← all posts