How to Tell If a Paid Agent Endpoint Has Real Buyers

You have found an agent endpoint that does what you need. The price looks right. The documentation is decent. Before you build anything on top of it, one question matters more than all of the above: has anyone else actually bought this?

The answer is harder to find than it should be. Most registries show call volume. A few show total transaction counts. Almost none show how many distinct buyers an endpoint has attracted. That distinction is not a detail.

The listing is not the market

Of 25,210 paid agent endpoints tracked over the last 30 days, 3,782 have more than one distinct paying buyer. That is 15.0% of the listed paid population.

The caveat travels with that number: this is third-party telemetry from Coinbase, not a direct probe. Endpoints that settle payments off-chain or through other rails are not captured here. The shape of the finding likely understates the true number of active endpoints somewhat. The gap is still large enough to be directional: most of what any registry shows you has not been purchased by anyone except possibly the operator who built it.

High call volume does not fix this. A single service can generate thousands of calls by routing its own internal traffic through its own endpoint. The buyer count is the variable that separates a service with customers from a service running a loop. If you are evaluating an endpoint and you only have access to call volume, you cannot distinguish between those two cases.

What works as a proxy

Corroboration across independent registries is the most practical filter available before you commit real infrastructure. An endpoint listed in two or more separate registries was added by someone with a reason to list it in each one. Weak evidence, but real evidence. The index tracks 1,152 hosts appearing in two or more independent registries.

Corroboration tells you the service is probably real. It does not tell you the service has customers. A service can be real and also have none.

The other useful signal is response consistency. Call the endpoint with a known input and check whether the structure of the response is stable across multiple calls. Endpoints that vary their output structure are endpoints that will break your workflow at random. This is not knowable from a registry listing; you have to call the thing.

A recent verified response beats a long track record of listing. Registries accumulate historical entries. An endpoint that responded three months ago and is listed in five places might be dead now. Something that answered a live handshake last week and appears in two registries is in better shape than something with a longer history and no recent probe.

What the pricing data says

The median asking price across agent endpoints is $0.01 per call. That is the midpoint of a wide distribution. The caveat: 5 implausible prices were excluded from the calculation and 68 free endpoints were held out of the percentiles.

Simple task categories, things like routing, lookup, and classification, tend to cluster at the lower end of that range. Endpoints involving live data retrieval, model inference, or multi-step orchestration run higher, sometimes significantly.

The pressure from the cheap end is real. An endpoint doing classification at five cents competes against endpoints doing the same task for a fraction of a cent. Price alone does not determine who gets bought repeatedly. But it is a floor. If your endpoint costs more than ten times the category median per call, you need a visible reason for that before a buyer will commit.

What the endpoints with real buyers have in common

The categories showing up in the multi-buyer data cluster around data enrichment, specialized retrieval, and transformation tasks where building the alternative yourself takes real engineering time. Research aggregation, entity resolution, domain-specific classification, document parsing. These sell because the buyer's alternative is not a cheaper API call; it is months of work.

General wrappers around broadly available language model APIs are harder to sell more than once, because a buyer who understands what they need can often replicate the wrapper in an afternoon. The endpoints with repeat buyers tend to do something the buyer cannot easily rebuild: a specialized data source, a proprietary model, a workflow that took time to tune.

Predictability matters more than breadth of features, within any price band. Endpoints that take a defined input and return a consistent structure get bought again. Endpoints that claim broad capability and fail in non-obvious ways do not get bought again, regardless of how cheap they are. The buyer-count data reflects this: the highest buyer counts belong to endpoints doing narrow things, not the most ambitious ones.

For builders pricing their own endpoint

The $0.01 median is competitive pressure, not a target. The real question is whether your endpoint winds up in the 15.0% with multiple buyers or the 85.0% without.

The pattern that gets you into the 15.0% is narrowness and consistency. Define what your endpoint takes and what it returns. Make the error cases explicit. Price below the cost of the buyer building it themselves. Be live when called.

Do not anchor your pricing analysis to specific competitors in your category. Individual endpoints churn within months. What stays stable is the task category, the price band, and the buyer's build alternative. Those are the variables worth tracking.

Where to find the live picture

Specific endpoints change faster than any article can track. The live index at agents.traderszone.net updates from crawl data and third-party telemetry and surfaces buyer-count and corroboration signals directly. For anything infrastructure-adjacent, the live data will be more accurate than a snapshot from any publication.

The 85.0% figure is not a reason to avoid the market. It is a map. The market is real, it concentrates among endpoints doing specific things consistently, and it is findable if you know which signals to look for rather than which names.