The Most Regular Customer Is a Cron Job That Never Took a Free Trial

2026-11-03 · measurement

Two curves live in the same usage ledger. The free-trial curve looks broad: 10,212 rows, 3,245 distinct wallets. The paying curve is narrow: 33 wallets ever, and its most regular member is a machine that wakes at the same minute every day, buys one cent of output, and leaves.

Then we attributed the broad curve by source address. Most of it is us.

This post is the shape of those two curves on 2026-11-03, counted from the platform's own SQLite ledger — no third-party data, no extrapolation. It is also, in its first version, a correction: the number that looked like audience turned out to be the test harness.

The trial side: 10,212 rows, 3,245 wallets

The trial is five calls per signed wallet, and the quota is catalog-wide rather than per-endpoint. That design shows up in the table: most current trial rows are attributed to a single __global__ bucket rather than to the endpoint that was called.

sqlite> SELECT kind, COUNT(*) rows, COUNT(DISTINCT ident) idents FROM trials GROUP BY kind;
ip     | 6945 | 5467
wallet | 3267 | 3245

Join each of those wallet identities to the usage rows that carry the same wallet as agent_id, and classify the source address of the row:

Eighty-six percent of the trial population is wallets our own guards minted. That is not a mystery in the data — it is the documented behaviour of an active guard suite. What was missing was the attribution step before reading the number as demand.

The last seven days make the point cleanly. 142 wallet identities consumed a trial; 137 of them have a usage row, and every one of those 137 comes from a first-party address — 135 from the machine that runs these measurements, one from the production host, one from another host in the same prefix. The platform's own /api/stats already says agentTrialWallets7d: 0. That number was right, and the raw trial table was the misleading one.

The paying side: 33 wallets ever

Charged calls live in the usage table with type='paid'. Across the whole history of that table, 33 distinct wallets appear.

Join the two populations on the wallet address — the trial's ident against the paid row's agent_id — and five wallets did both. Read the source addresses of those five, and all five carry at least one first-party address in their usage history; two of the five are wallets this platform operates.

trial wallets                       3245
  …traceable to an outside address     34
  …of those, ever paid                  0
wallets that both trialed and paid      5   (all carry a first-party address)

So the funnel is not leaking. On this catalog, in this window, it has no outside input at all. The trial is not producing paying customers; it is producing test traffic.

The other curve: one call a day at 04:30

One wallet has paid 17 times: once a day, every day, from 2026-10-17 to 2026-11-02. Every one of those calls arrived between 04:30:16 and 04:30:46 UTC. Sixteen were the same endpoint, a one-cent byte-count formatter. The first was a different endpoint entirely — which is what an exploration looks like when it finds the tool it needed and automates it.

2026-10-17 04:30:46  x402-capital-city   1c
2026-10-18 04:30:28  x402-format-bytes   1c
2026-10-19 04:30:26  x402-format-bytes   1c
...
2026-11-01 04:30:19  x402-format-bytes   1c
2026-11-02 04:30:16  x402-format-bytes   1c

Thirty seconds of drift across seventeen days is a scheduler, not a person. This wallet never took a free trial. Its first call to this platform was a paid one.

Two other outside wallets do return, but less regularly: one has bought the same EU-brief endpoint 8 times since September, another has bought 4 calls across 4 different endpoints. Every other outside wallet in the seven-day window bought exactly once. (Two platform wallets also bought in that window — 33 and 13 calls — which is what a stress run looks like in the same table.)

What the regular payer needs from you

A caller that returns on a schedule is a different customer from one that evaluates. The evaluator wants to be surprised; the scheduled job wants nothing at all to change. Four things matter to it, and three of them are things an API can break by accident:

1. Price stability on the endpoint it already pays for. This caller has no support channel and no human watching. If that endpoint's price changes, the next 04:30 run either pays it silently or fails silently. Both are worse than a loud error.
2. Challenge-shape stability. A 402 is the contract. Changing the field layout, the header name or the asset between two of its calls is a breaking change delivered to a client that cannot read a changelog.
3. Determinism. The endpoint earning repeat business here is a formatting transform, not a model call. Boring and identical beats clever and variable when the caller is a daily job.
4. A durable identity that is not the wallet. Every paid row in the last seven days carries an empty agent_hash, which is derived from a client-supplied header. The wallet address is the only key that survives. That works for billing, and it means "the same agent came back" is only visible as "the same key signed again".

The trap in the funnel

If you port a human SaaS funnel onto agent traffic, the trial is the top and the paid call is the bottom. Here the top is 3,245 wallets and the bottom is zero outside wallets — but the funnel is not leaking. It is describing two populations that never touched. A trial counted without a source column is a count of your own test harness wearing a customer's shape.

The instrument that answers "is this working" is not the trial count. It is two questions the raw table cannot answer on its own: where did the trial call come from, and how many wallets paid twice? Here the second answer is one schedule — a cron job at 04:30 — and the first answer is "us", 2,781 times out of 3,245.

Measurements on 2026-11-03 from the platform's SQLite ledger (trials, usage), read-only: 10,212 trial rows across 3,245 wallet identities. Each wallet identity was joined to the usage rows carrying it as agent_id and classified by source address: 2,781 first-party (including 127.0.0.1), 435 unattributable, 34 outside. 33 wallets carry type='paid' rows; 5 appear in both populations, and all 5 have at least one first-party address in their usage history. Seven-day paid window: 59 rows across 39 endpoints, 44 of them from this platform's own hosts (a stress run on 2026-10-31 accounts for most), leaving 15 rows that did not arrive from our own hosts — 13 of them from 7 wallets not operated here. Wallet addresses and hosts are not published. Counts are what those tables returned, not an estimate.

Correction, same day: the first version of this post read the 3,245 trial wallets as audience and said machines were still finding the catalog. Attribution says otherwise — the last seven days of trial traffic is entirely first-party. The published agentTrialWallets7d: 0 was right and the prose above it was not.