Yesterday we audited the machine-readable records we publish — prices, payout addresses, endpoint lists — against the live 402 responses they describe. Today we pointed the same question at something less obviously technical: the counts in our own prose.
The homepage said this:
Your agents discover, pay, and consume APIs autonomously in USDC on Base. 300+ services across crypto, web, AI, and data.
The catalog held 1,645. That sentence is the one line on the page whose whole job is to convey scale, and it was understating by more than five times.
The same bug ran the other way too. An auto-mode dashboard advertised 1,700 services — a number the catalog has never actually reached. And the worst instance was in a file no human reads: /.well-known/ai-catalog.json, the record LLM crawlers ingest, described us as "272 agent-callable APIs", with a metadata block frozen on August 4 (6,308 trials, 36 wallet users). When someone asks a model how big this directory is, 272 is the answer it has to work with.
Under-claiming, over-claiming, and telling a crawler something six times too small look like three different mistakes. They are one: a number was typed into a file, the thing it described kept moving, and nothing connected the two ever again.
That is worth naming precisely, because it is not a content problem. A count in your copy is a cached API response with no expiry and no owner. Every marketing page, every .well-known record, every llms.txt is a client of your own stats endpoint that someone hand-resolved once, months ago.
The test that finds these: grep your site for digits followed by the words you use for your own inventory — services, endpoints, APIs, users — and diff every hit against the live value. We found 17 files. Only one of them was current.
The temptation is to fix the numbers. We had already done that once: a hand-patching pass the day before had walked straight past two "272" strings in the very file that feeds LLM catalogs. Hand-patching is the thing that fails, so we replaced it in two shapes.
A component already existed at /js/live-stats.js that rewrites any <span data-stat="services"> from /api/stats on page load. Eleven pages used it. The pages with the wrong numbers did not. So the counts became spans, the missing pages got the script tag, and the value written into the HTML is the current live one — so a crawler or a reader without JS still sees today's figure rather than March's.
Records like ai-catalog.json and llms.txt cannot run JavaScript, so a script rewrites them from live stats on a daily cron. One rule matters more than the rest: prose counts floor, never round up. 1,645 services publishes as "1,600+", never "1,700". A floored claim is one you can always defend; a rounded-up one is a small lie that grows every time the catalog dips.
Self-correcting scripts have a failure mode: they die quietly and everything looks fine. So the verification suite got a check comparing published claims to live: a prose count must sit in (live − 100, live]. Below that range the record has stopped tracking; above it we are over-claiming. Both fail.
Then the part that is easy to skip: we put the old number back and watched the check fail —
FAIL published counts: /.well-known/ai-catalog.json: claims 272, live 1645
— ran the refresher, watched it heal, and re-ran the suite green. A guard you have only ever seen pass is a guard you have not tested.
One of our pages compares marketplaces. In a single table row sit our count, aisa.one's 5,000 registered agents, and Satring's 845 paid APIs. The general rule — "a number followed by registered agents is our wallet count" — is perfectly correct on nine pages and catastrophically wrong on the tenth. The dry run showed exactly what it intended to do:
L124: 5,000 -> <span data-stat="wallets">775</span>
That edit would have republished a competitor's figure as ours — not a stale number, a fabricated one, and about somebody else's business. It never shipped because the run was a dry run and the context got read before the write.
The fix was to give comparison pages a literal-scoped rule that only touches our own value and leaves every other number in the table alone. The general lesson is narrower than "be careful": an automation that rewrites claims must know which claims are yours to rewrite. On a page that describes other people, pattern-matching prose is not a safe way to decide.
Agents do not sanity-check your numbers the way a human skimming a landing page does. They read llms.txt, .well-known records, and OpenAPI specs literally, and they act on what they find. Three things worth copying:
Every endpoint gives 15 free trial calls before you pay anything, and registering a wallet adds 500 free credits. No KYC, no signup form, no API key — bring a wallet and start calling.
Browse the catalog →Counts in this post are read from /api/stats at the time of writing and re-rendered live where marked. Competitor figures (aisa.one, Satring) are as published by those projects and are deliberately left untouched by our automation.