Feature request: optional feeless settlement rail for Upstash Vector pay-per-request metering

Start by reading the vector SDK's query and upsert client entry points and how they send requests; the issue names no specific files or tests. Before implementation, clarify whether Upstash wants this feature and agree on the opt-in settlement design; done should preserve existing billing by default and define how opting in changes settlement.

Feature request: optional feeless settlement rail for Upstash Vector pay-per-request metering

Is your feature request related to a problem?
Upstash Vector already sells retrieval the agent-friendly way: true pay-per-request on the
pay-as-you-go plan ($0.40 per 100,000 requests, a 1536-dim vector counting as 2 requests).
That per-request meter is exactly the unit a settlement rail should attach to, but on a card
or EVM-L2 (USDC) settlement path the fixed per-transaction fee can exceed an individual
metered read, so paying exactly for what an agent calls is uneconomical even though the
metering is already per-request.

The idea
Add an optional, backward-compatible way to settle metered vector reads feelessly (Nano / XNO)
beside the existing account/card billing — for example a client-side opt-in that meters a query
or upsert and settles it with a fee-free rail, defaulting to the current billing when unset.

Why Upstash Vector specifically
Upstash's "taxi meter" model is per-request ($0.40/100K), which is precisely what a settlement
rail should attach to. A fee-free final rail removes the fixed-fee overhead that makes sub-cent
per-request settlement uneconomical, so autonomous agents can pay exactly for what they call.

Existing building blocks (reuse, not from scratch)

• x402 (HTTP-402 payment standard; x402-foundation/x402) with the exact scheme used for fee-free Nano settlement.
• x402nano (x402nano.org) — permissionless exact-permit2 Nano facilitator.
• feeless402 (github.com/michardnicolas/feeless402) — Python wallet, x402 client, merchant server, MCP server.
  The request is only a client surface to opt into one; the signing/facilitation/settlement legs already exist.

A working model of the economics (tested locally — .venv/bin/python upstash_metering.py)

per query request       = $0.000004   (a single meter read)
per 1536-dim upsert     = $0.000008
tiny prototype, 10K/day  -> ~$1.20/mo usage  + one card charge fee $0.33  = 28% drag
light agent, 50K/day     -> ~$6.00/mo usage  + one card charge fee $0.47  =  8% drag
heavy RAG, 1M/day        -> ~$60.00/mo usage + one card charge fee $2.04  =  3% drag
10k upserts (~$0.08 bill): a card rail would charge ~$0.30 — ~4x the bill itself.

At split-cent per-read prices, a card's fixed charge dominates the invoice; a feeless final
rail (Nano: zero fees, final in ~1s) removes it entirely.

Requested scope

• Whether per-request settlement on a fee-free rail is something Upstash would consider for agent workloads.
• If so, an opt-in client-level settlement='nano' (or a generic per-request payment callback)
  wired through one of the x402 Nano clients above, additive and default-compatible with
  existing account/card billing.

Happy to draft a PR on the vector SDK path if the team is interested. I have not changed any
billing or security primitives; this is additive and opt-in.