What an edge metering gateway does
It sits in front of your code and decides, per request, whether the caller has paid. A crawler or an agent hits your endpoint; the gateway can answer with a payment challenge before your Worker ever runs, settle it, and only then pass the request through. It is x402's job, moved to the platform layer so you do not implement the handshake yourself.
Why platforms are building it
Because the callers changed. A site used to be read by people and indexed by a handful of crawlers. Now a large share of traffic is agents and scrapers taking content to feed models, and the platform's pitch is: charge them at the door instead of serving them for free. It is a reasonable response to a real shift in who is knocking.
Why it is off here
This deployment has no content to protect and no margin to collect. The pages it hosts are yours; the point is to give the reader the link, not to gate them. Turning on a metering gateway would charge the one person you sent the page to. It is the correct feature for the wrong shape of product.
What does the same job here, for free
| Concern the gateway would handle | Handled here by |
|---|---|
| An open endpoint being abused | A fixed-window rate limit per address |
| Pages accumulating forever | A default expiry that deletes, not hides |
| Crawlers indexing private pages | X-Robots-Tag: noai, noimageai, noindex and a robots.txt |
| Telling callers apart | An API key per client, revocable one at a time |
The one place the shift does reach this deployment
Not billing — robots. Because so much traffic is now models fetching pages, every viewer
response carries noai and noimageai alongside noindex,
and the sitemap-plus-robots.txt pair tells a well-behaved crawler not to fetch the
viewer paths at all. That is the defensible response for content you are giving away to one
reader: ask not to be trained on, rather than charge at the door.
If your product is the opposite shape
If you host content you want to charge machines to read, then the gateway is exactly right and this deployment is the wrong reference. The judgement here is narrow and stated plainly on the payments page: no marginal cost, no margin, no meter.
Does turning the gateway off cost anything?
No — it is simply not enabled. The deployment's own rate limit and expiry defaults do the abuse-control job that a metering gateway would otherwise cover.
Could I enable it on my own deployment?
You own the account, so the platform features are yours to turn on. Doing so changes what this is — from a primitive you give links away with, into a service that charges for reads.