Invoket

Free trials for agents: the dust-amount x402 rail

How an autonomous agent tries a paid x402 API with no account and no code change — a symbolic dust-amount rail in the 402 challenge, signed like a paid call and never settled.

By Matthias Begot · · Updated

An agent should be able to try a paid API exactly the way it buys it. Invoket implements free trials as one extra rail in the standard 402 challenge, at a symbolic dust amount: the agent signs it with the same x402 SDK it uses to pay, replays the request, and the call is granted without ever being settled — once per day, per endpoint, per payer address. The grant identity is the wallet, not an IP and not an API key. No new protocol primitive, no signup, no separate trial code path. Which endpoints currently offer one is published live in /catalog (metadata.trial) — never in a hardcoded list. This article explains the mechanics and compares them with the other trial patterns in the x402 ecosystem.

Why the classic free tier is an awkward fit for agents

A traditional API trial assumes a human: create an account, confirm an email, open a dashboard, copy a key, sometimes enter a card “for verification”. An autonomous agent has none of that — it has an HTTP client and a wallet. Every account step is a place where the loop breaks and a human has to intervene, which is precisely the friction pay-per-call was designed to remove (see Why an API key does not work for an autonomous agent).

What an agent actually needs from a trial is narrow: one real request-and-response on the production path, cheap enough to burn on evaluation. It wants to confirm that the endpoint answers the question it has, in the shape it expects, before committing a budget to it. Anything beyond that — quotas dashboards, trial keys, welcome emails — is human furniture.

The mechanics: one more entry in accepts

The x402 specification already contains everything a trial needs. A 402 Payment Required response carries an accepts array with one entry per rail the server will take — each entry a self-describing offer with a scheme, a network, an asset, an atomic amount and a payTo. Multi-rail is normal: a server may offer USDC on Base and USDC on Solana side by side, and the client picks the entry it can settle.

A trial is simply one more entry in that array — a copy of the first paying rail, with the amount replaced by a symbolic dust amount:

{
  "x402Version": 2,
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "<stablecoin contract>",
      "amount": "<atomic amount>",
      "payTo": "<recipient>"
    },
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "<stablecoin contract>",
      "amount": "<dust amount>",
      "payTo": "<recipient>"
    }
  ]
}

Every value above is a placeholder on purpose — the real asset, amounts and recipient are served live by the gateway and read from /catalog, never copied into an article. What matters is the relation between the two entries: the trial amount sits orders of magnitude below the cheapest price on the grid, far enough down that no client can mistake it for a real one.

Because a dust-amount entry is an ordinary PaymentRequirements object, an unmodified x402 client already knows what to do with it: select the rail, sign the payload locally, attach it as the payment header, replay. There is no extension to parse, no trial token to fetch, no second SDK.

Why dust and not zero

The original design used a literal "0", and it does not survive contact with a facilitator. The CDP facilitator’s /verify rejects it — an undocumented minimum amount, which we measured somewhere between 100 and 1,000 atomic units, and which also rules out the obvious fallback of a single atomic unit. A zero-amount rail is spec-shaped but unverifiable, so it can never reach the grant.

Dust is the workable substitute: above the facilitator’s floor, an order of magnitude below the lowest real price, and — this is the part that makes it free — never submitted for settlement. The amount exists to make the requirement verifiable, not to be charged.

The trial loop is the production loop

Run end to end against an Invoket endpoint that offers a trial, the loop looks like this:

  1. Discover the endpoint in /catalog and check metadata.trial to see whether a trial is currently offered.
  2. Probe — send the bare request. Probing is always free: an unpaid request only returns the 402 challenge, and no money moves.
  3. Read accepts — one of the rails carries a dust amount, far below the published price.
  4. Sign and replay — same wallet, same signature scheme, same header as a paid call.
  5. 200 — the real response body, granted without settlement. Nothing is broadcast, nothing moves, and the signed authorization expires unused. There is no PAYMENT-RESPONSE header on a trial call, which is how a buyer can verify from the outside that it was not charged.

The grant is one free call per day, per endpoint, per payer address. The identity that gets the trial is the same identity that would pay: the wallet address that signs. That is the deliberate difference from IP- or key-based trials — the trial call is a full rehearsal of the paid integration. (An IP ceiling does exist, but only as depth: a payer address is free to generate, an IP less so, so the gateway also caps how many trials it hands out per IP per day across all endpoints. It gates the offer; the grant itself is still counted per address.) When the agent later pays for real, nothing in its code changes; the gateway simply offers the real price, and the same loop settles it. The Quickstart shows the probe → sign → replay code, and For agents documents the trial surface.

How the rest of the market does trials

Other x402 sellers have converged on three different patterns.

Free tiers embedded in extensions. relai.fi (March 2026) lets a provider configure per-buyer free calls at the relay: while the quota lasts, calls return 200 directly with X-Free-Calls-Remaining headers; once exhausted, the caller gets a standard 402 with the tier described under extensions.freeTier. This is convenient — the first calls need no signature at all — but the free path runs outside the payment loop, and a client needs to understand the extension to explain what happened.

One call per IP. Some services listed in the awesome-x402 registry grant a trial per IP address. An IP is a weak identity for agents: fleets share NAT and serverless egress, so the grant is exhausted by a neighbor or multiplied by rotation, and the trial identity has no relation to the identity that will pay.

Trial credits behind issued keys. Broker-style services hand out instant API keys with trial credits, then point to paid x402 URLs when the credits run out. It works, but it reintroduces the account and key lifecycle that pay-per-call removed.

ApproachTrial identityClient change neededTrial path = paid path
Dust-amount rail (Invoket)Payer wallet addressNone — standard x402 clientYes — same sign-and-replay
extensions free tierPer-buyer, tracked at the relayExtension-aware client for full UXNo — free calls skip payment
Per-IP grantIP addressNoneNo — unpaid direct response
Trial keys / creditsIssued API keyKey handlingNo — key path, then x402

The dust-amount rail is the variant that adds no new primitive: it reuses the accepts array, the signature and the replay exactly as the spec defines them, and simply stops before the settle. Any agent that can pay can trial — including agents that have never heard of Invoket before finding an endpoint in a registry (see How does an agent find a paid API with no human in the loop?).

Which endpoints have a trial right now

That is authority data, and it moves — so it lives in the gateway, not here. Read /catalog and check metadata.trial on each resource. The catalog is the single source of truth for prices, rails and trials alike; an article describes the mechanism, it never settles the call. If you want to try the loop today, start from the Quickstart — the probe is free everywhere, and where a trial is offered, the first 200 is too.

Sources