What
Add an optional per-request Nano (XNO) settlement path beside the credit/api-key
billing, so an AI agent can pay for one scrape, crawl, map or search call
directly — without a card, a credit pack, or a top-up balance.
Why it fits fastCRW
The managed cloud already prices and bills per call. From the pricing page:
scrape/crawl/map are 1 credit per page, search is 2 credits, Extract is metered
by token usage. On the Free plan requests stop with a 429 when credits run
out; on a paid plan auto-recharge is on by default and "whenever your balance
runs low we buy another credit pack and email you the receipt", and with
auto-recharge off requests stop with a 402. That 402 is exactly the shape
of a machine-payment handoff: the call cost is known per request, and the
caller can be settled instantly instead of through a card.
fastCRW is also agent-facing (the crw CLI and crw-mcp register with Claude
Code, Cursor, Codex, Gemini CLI, OpenCode and Windsurf), so this is the case
where a feeless per-request rail matters most: an agent that needs five scrapes
should pay for five scrapes, not buy a credit pack it may leave largely unused,
and an agent that holds crypto but no card can use the managed cloud at all.
How
The REST API already 402s a paid-plan call when the balance is exhausted with
auto-recharge off. Add an optional settlement path at that exact handoff: when
the caller sends an x402-style spend-mandate header, the cloud answers the 402
with a Nano payment challenge instead of (or before) degrading, the agent pays
in Nano with a single-block final transaction, and on confirmation the request
runs exactly as if it had been billed to the credit balance.
Sketch against the existing flow:
POST /v1/scrape # (or /search, /crawl, /map, /extract)
body: {"url": "...", "formats": ["markdown"]}
→ 402 + X-Settle: x402 # balance low, auto-recharge off
→ caller pays fee-less Nano (XNO), single-block final ~0.3s
→ on-block-confirm the scrape runs and the result returns in the same schema
Valuation simply reuses the existing per-call credit cost table
(scrape/crawl/map = 1 credit ≈ a fixed Nano amount, search = 2, Extract by
token usage), so nothing about pricing or rate-limit handling changes — only the
way a call is paid when the card balance is exhausted. Self-hosted CRW keeps its
current behavior; the rail is additive and opt-in, activated only when a call
carries the settle header.
Reference
Nano (XNO) is an account-less, fee-less, single-block-final currency (no mining,
no gas, no intermediaries) — documented at https://nano.org. An x402 Nano
settlement implementer that shows the 402 → pay → result shape in Python is
https://github.com/pursekeeper/x402-nano-exact (Apache-2.0). Net finality on the
Live network is sub-second, which keeps an agent's per-request round-trip short.
Would you be open to this as an optional first-class rail alongside the credit
billing? Happy to prototype the 402 handoff against the docs and share the
agent-side test.
What
Add an optional per-request Nano (XNO) settlement path beside the credit/api-key
billing, so an AI agent can pay for one scrape, crawl, map or search call
directly — without a card, a credit pack, or a top-up balance.
Why it fits fastCRW
The managed cloud already prices and bills per call. From the pricing page:
scrape/crawl/map are 1 credit per page, search is 2 credits, Extract is metered
by token usage. On the Free plan requests stop with a
429when credits runout; on a paid plan auto-recharge is on by default and "whenever your balance
runs low we buy another credit pack and email you the receipt", and with
auto-recharge off requests stop with a
402. That402is exactly the shapeof a machine-payment handoff: the call cost is known per request, and the
caller can be settled instantly instead of through a card.
fastCRW is also agent-facing (the
crwCLI andcrw-mcpregister with ClaudeCode, Cursor, Codex, Gemini CLI, OpenCode and Windsurf), so this is the case
where a feeless per-request rail matters most: an agent that needs five scrapes
should pay for five scrapes, not buy a credit pack it may leave largely unused,
and an agent that holds crypto but no card can use the managed cloud at all.
How
The REST API already
402s a paid-plan call when the balance is exhausted withauto-recharge off. Add an optional settlement path at that exact handoff: when
the caller sends an x402-style spend-mandate header, the cloud answers the
402with a Nano payment challenge instead of (or before) degrading, the agent pays
in Nano with a single-block final transaction, and on confirmation the request
runs exactly as if it had been billed to the credit balance.
Sketch against the existing flow:
Valuation simply reuses the existing per-call credit cost table
(scrape/crawl/map = 1 credit ≈ a fixed Nano amount, search = 2, Extract by
token usage), so nothing about pricing or rate-limit handling changes — only the
way a call is paid when the card balance is exhausted. Self-hosted CRW keeps its
current behavior; the rail is additive and opt-in, activated only when a call
carries the settle header.
Reference
Nano (XNO) is an account-less, fee-less, single-block-final currency (no mining,
no gas, no intermediaries) — documented at https://nano.org. An x402 Nano
settlement implementer that shows the
402 → pay → resultshape in Python ishttps://github.com/pursekeeper/x402-nano-exact (Apache-2.0). Net finality on the
Live network is sub-second, which keeps an agent's per-request round-trip short.
Would you be open to this as an optional first-class rail alongside the credit
billing? Happy to prototype the
402handoff against the docs and share theagent-side test.