A spending system, not a wallet: the float, the limit and the record

Give an agent a wallet and you have built a spending system. Three controls make it one you can run: a float you fund, a limit that refuses calls, and a record that explains the month.

The three things

Handing an agent a funded wallet is not a configuration step. It is the moment a piece of software acquires the ability to commit money without asking, on a rail that settles irreversibly in seconds, at a quantity nobody is watching. The exchange itself is small: a call that arrives without payment is answered with a price, and the same call carrying a signed authorisation is answered with the work. Everything after that — which chain, which scheme, which retry policy — follows from three decisions: how much money exists, what may be spent from it in one go, and what is written down afterwards.

The float prevents the task running dry. An agent that runs out of money mid-job does not stop cleanly. It stops at whatever step the balance allowed, with a half-assembled result and no explanation attached. Settlement is immediate and there is no credit, so a wallet at zero is not a slow month; it is a wall.

The limit prevents one instruction spending more than it is worth. This is the failure people underestimate, because it does not look like one at the time. A single message can trigger a hundred paid calls if the agent decides that is what the job needs, and every one of them is individually correct, individually cheap, and collectively absurd. The ceiling says no on your behalf while you are not in the room.

The record prevents being unable to explain the month. Payments are public on chain, which is not the same as explicable. A chain shows amounts, addresses and times, and nothing else. It does not show what the money bought, which task failed, or why Tuesday cost four times Monday.

The three fail asymmetrically, and that sets the order in which to build them. A missing float fails loudly: the call does not go through and someone notices within the hour. A missing limit fails quietly: the work completes and the excess appears on the record later as a line nobody planned. A missing record fails last, at month end, when the person who approved the spend asks what it bought. Build the record first, because it is the only one of the three that tells you whether the other two were right.

A fourth thing is often mistaken for one of these: the agent’s own restraint. An agent instructed to be economical is not a control; it is a preference, and preferences hold until a task is difficult. The test is cheap — set a ceiling low, send a job that wants more, and watch what the workspace does. If it refuses the call, the control is real. If the agent explains why it stopped, you own a story about a preference.

The float

Three questions decide the float: how much, in what asset, on which chain. Getting the first right while getting the third wrong produces a wallet that is funded on paper and empty in practice.

Start with what can be stated as fact. The workspace’s opening balance is 0.50 USDC on Base, held in the client’s own wallet and credited to the workspace. It is an opening balance, not a fee: nothing transfers to an operator at provisioning, the money never leaves the client’s wallet, and it is available to spend on calls. At the DeepSeek deepseek-v4-flash price of $0.00700 a call that is 71 calls and $0.497 spent, leaving three tenths of a cent that buys nothing.

Beyond that, a float is arithmetic, and the arithmetic depends on which routes the calls land on. Table 1 prices $5 across the routes we have measured.

Table 1. What $5 buys at measured Base prices. “Calls” is the whole number the float covers; the remainder cannot buy the next one. Source: x402.press measured 402 quotes, 30 October 2026.

The first row is the number most people carry away: $5 buys 714 calls. It is correct and it is the most misleading figure here, because it assumes every call is the cheapest one available. A float is not a bet on how much work you have. It is a bet on the mix of prices that work lands on, and the mix moves without announcement.

Take that same $5 and let one call in ten escalate to qwen3.8-max at $0.256125. Ten calls then cost $0.319125, so the float no longer covers 714; it covers 156. At one in twenty it covers 256. The arithmetic is dominated by the dear calls, and the cheap ones are almost free beside them.

Two lessons follow, and they are the practical content of this section.

A float sized on the cheapest route is a limit you did not knowingly set. You intended a 714-call float and built one that covers 156, which looks generous until the first hard question arrives. If the work may escalate, size for the escalated mix. If it may not, forbid the escalation with a limit rather than relying on the agent’s judgement about when a cheaper model will do.

And the float is working capital, not a budget. At fifty paid calls a day on flash that is $0.35 a day, so $5 is about a fortnight and the 0.50 opening balance is a day and a half. Nobody bills you at month end; the balance simply stops being enough, at whatever hour it stops. An agent cannot top itself up and no invoice arrives to warn you. Either the float is reviewed on a schedule you set, or the stop is the review.

The asset and the chain are not incidental. Base carries USDC and EURC, Avalanche carries USDC only, and balances are separate per chain. A float is not a pool that follows the agent around: money on Base is not money the agent can spend on Avalanche, and moving between them is a decision with its own cost and delay. A wallet funded on the wrong chain fails exactly as an unfunded one does — rejected at verification for insufficient funds — and the failure reads as a bug rather than a funding mistake.

One property of the float is worth stating plainly, because the whole arrangement rests on it. The float is the client’s money in the client’s wallet. The facilitator verifies and settles, and does not custody; the resource server never holds a balance to be frozen or lost. What sits between the agent and the money is a signature, and a signature can be refused.

The limits

Three ceilings, set by the client, and they are not three versions of one idea.

Paid calls per message bounds the work one instruction may trigger. It catches an agent that has decided a task needs forty lookups: the last few are refused, and the message ends with the work it could pay for.

Spend per message bounds the price of one answer. It catches a task that is small in calls and expensive in models — three calls to the dearest route can cost more than forty to the cheapest.

Spend per day bounds the month’s pace. It catches everything else: a loop, a runaway retry, a workload that doubled because someone upstream changed a schedule.

The mechanism is the same for all three, and worth being precise about. The workspace refuses the call that would cross a limit, and the agent does not negotiate the limit mid-message. There is no escalation path inside an instruction, no “may I spend two more cents”. The refusal is final for that message, and raising a ceiling is a human act that happens between messages or not at all. The agent’s judgement operates inside the box; widening the box is not one of the things it can do.

Do the arithmetic once by hand. At $0.00700 a call, a per-message cap of five cents buys seven calls — $0.049, with a tenth of a cent left that cannot buy an eighth. Seven, not seven and a fraction. If five cents is the right price for one instruction, seven is the number of calls it may make; the two figures are one decision expressed twice, and setting one without the other leaves the pair inconsistent. At the same five cents, qwen3.8-flash buys five calls, deepseek-v4-pro three, and qwen3.8-max none at all.

Three limits on what a ceiling can do, stated plainly, because all three are routinely assumed away.

It bounds calls, not prices. A ceiling is denominated in money and enforced against a quote, and the quote is the seller’s. When a service raises its price the ceiling tightens without anyone touching it, and a task that ran last month starts refusing this month.

It bounds spend, not correctness. An answer bought inside the ceiling can be wrong, and the ceiling has nothing to say about it. This is the most comfortable misunderstanding in the arrangement: the numbers are small, the cap is in place, the work is being done. A spending control is evidence about money and about nothing else.

Set too tight, it becomes an availability limit in a budget’s clothes. A five-cent message cap and ten messages a day is $0.49, which is the whole opening balance. The agent did not overspend; it ran out of permission, which from outside looks identical to running out of money. Design against starvation as well as profligacy, because an operator who learns that the ceiling refuses ordinary work will route around the workspace entirely.

Two notes on the per-day ceiling, which surprises people. It binds a pace rather than a total, so where the day boundary sits matters — a calendar day and a rolling window behave differently at month end. And it is usually set from a monthly figure rather than a daily one: $1.00 a day is $30 a month at best, and at flash prices it is 142 calls, a workload the fifty-cent opening balance does not sustain for a single day.

The record

The record is the only part of the system a finance function will ever see, and the part most often left to the chain. That is a mistake with a specific shape. The chain records a transfer between addresses at a time, permanently and publicly, and nothing about purpose. Nine payments of $0.00700 to one address on one day are, on chain, nine identical events. In your record they are nine calls: six answers to a question, one retry, and two belonging to a task that was abandoned.

The join key is yours, not the protocol’s. A task id written into the record at the moment of the call is what makes a public transaction explicable a month later, and Table 2 sets out the fields that make it stand up.

Table 2. Fields to write per paid call. “Where it comes from” matters: a record built from the wrong place is worse than none.

Two fields are routinely recorded wrongly.

Record the amount the 402 quoted, not the catalogue price. They are different numbers, and not by a rounding. On the DeepSeek route the challenge asked for 7000 atomic units — $0.00700 — against a listed $0.00875, twenty per cent lower. The listing is a published rate for an operation; the 402 is the quote for this call, and the quote is what went inside the signature. An organisation reconciling against a price list will find it does not match its wallet, and will spend a week learning that the list was never the invoice.

Record failures as carefully as successes. A failed call is where the money is at risk and the event an operator will be asked about. A rejected payload leaves no trace on chain; a settlement_pending leaves a hash that must be reconciled; an indeterminate timeout leaves nothing trustworthy at all. None is discoverable from a balance that moved, and all are discoverable from a record that kept the errorReason and any hash that came with it.

For a metered call, keep two amounts rather than one: what you authorised and what was settled. The gap is the discretion you granted, and summed over a month it is the honest price of upto against a fixed price. And keep the record longer than feels necessary. The questions arrive late — at review, at audit, at the point where someone asks what a pilot cost. The chain will still hold the transactions. Only your record will still hold the reason.

Choosing the chain

The same call, three chains, measured on one day: $0.002 on Avalanche, $0.00700 on Base, $3.00 on Ethereum mainnet. That is 3.5 times between Avalanche and Base, 428 times between Base and mainnet, and 1,500 times between Avalanche and mainnet. Nothing about the work changes — same model, same answer — and Table 3 holds the comparison.

Table 3. One call, priced per settlement chain. Source: x402.press measured 402 quotes, 30 October 2026.

A cheaper chain is often right, and the case is not subtle. Where spend is many small calls and each is of low value, the chain’s premium can exceed the price of the work: at $3.00 a call, a mainnet float buys a single answer, so a task needing twenty costs $60 on a route that costs $0.14 on Base. For a first run, a load test, or a workflow whose point is volume, the cheap chain is correct and the saving is real.

What the buyer gives up is worth naming.

A different asset, and a different balance. Base carries USDC and EURC; Avalanche carries USDC only, so a float held in EURC cannot reach the cheap chain at all. Money is also per chain: choosing Avalanche means funding Avalanche — a second float to size, watch and top up, twice the operational surface for a saving that may only be a few dollars a month.

A different scheme menu. Our facilitator registers exact on every supported network and upto on six, with Avalanche carrying fixed price only. A metered call therefore cannot be routed to the cheapest chain, which is a constraint rather than a preference: the scheme decides the chain before the price does.

A different confirmation risk. The settlement_pending window — broadcast but unconfirmed — is a property of the network, not of the protocol. A chain chosen to save a fraction of a cent may be the chain that generates the reconciliation work.

Chain choice is a facilities decision, not an optimisation. It decides which balances you hold, which schemes you can use, and which uncertainties you inherit, in exchange for a difference that matters enormously at $3.00 a call and very little between $0.002 and $0.00700. Choose the chain your settlement path already supports, and treat a change of chain as a change of account rather than a change of setting.

Paying for a metered call

Under exact the signature commits to one number. Under upto it commits to a ceiling, and the seller chooses the amount at or below it after the work is done. That is a real difference in what the buyer’s key authorises, and it is the decision inside a paid call that most reliably costs money when it is left to default. Table 4 sets out what each signature commits to.

Table 4. Four ways to sign the same work. Source: measured 402 challenges, x402.press, 30 October 2026.

The third row is the one to sit with. The same call, on the same model, with one parameter left unset, authorises $0.160787 instead of $0.00955 — 16.8 times the metered ceiling and 23 times the exact price. Nothing in the request changed except a field many clients treat as an optional formatting hint. It is not a formatting hint. It is how much output the model is allowed to bill for, and leaving it unset authorises the model’s maximum.

So max_tokens is a spending parameter and should be set with the intent of a ceiling. A generous default is not neutral: it moves the risk from a limit a person chose to an output length nobody did.

There is a second consequence, and it catches teams who believe they have set both controls. A five-cent per-message cap and an unset max_tokens are incompatible. Either the workspace refuses the metered call because its authorised ceiling exceeds the message budget, and the metered route is silently unavailable, or the cap is raised past $0.160787 to admit it, and the cap no longer binds anything a single call can do. There is no configuration in which both do their job unless max_tokens is set deliberately.

The trade is straightforward once the schemes sit side by side. Metered fits work whose size is unknown in advance: summarising a document of unknown length, generating code whose length you cannot predict. Exact fits work whose size is known: a market data quote, a transaction build, a fixed prompt with a fixed response. Our catalogue reflects the split — SpiralStake build calls are exact only at $0.006125, because a build is a known job at a known price and there is nothing for discretion to do.

The rule to carry: when the work varies, buy the ceiling and set it deliberately; when the work is known, buy the price. When you have bought a ceiling, record both numbers, because the gap is what the discretion cost.

When a payment goes wrong

Five failures matter to an operator, none of them exotic, each with a defined symptom and one correct action. The expensive mistake is not failing to prevent them; it is applying the reflex that feels right — pay again — to the one failure where paying again is wrong. Table 5 sets out all five with the action for each.

Rejected before anything moves. Verification fails for reasons that never reach a chain: insufficient funds, a signature that does not match the requirement, a value that is not the amount asked for, an authorisation whose window has closed. Nothing is broadcast and the response carries an errorReason. Rebuild from a fresh challenge and send once — but fix the cause first, which is usually the float or the clock.

An expired authorisation. A signed authorisation carries a start and an expiry, and an agent that builds a payload and then queues it, logs it, or waits for a lock can present it after the window has closed. Rebuild from a new 402; never reuse the payload.

settlement_pending. The transaction went out and the confirmation could not be established. This is explicitly non-terminal: it may still confirm, and the response must carry a non-empty transaction hash and the network so the caller can reconcile instead of guessing. The resource server retries settlement exactly once, and on that retry the facilitator checks for the already-broadcast hash and reconciles against the transaction in flight rather than submitting a second. Retry once; reconcile the hash; authorise nothing new.

A duplicate submission on Solana. A signed payment can reach settlement more than once before the first confirms, and the network deduplicates at consensus — so the RPC reports success for a duplicate and a facilitator can report a settled payment for each attempt. Use a facilitator carrying a settlement cache, or implement the equivalent if you settle directly. This is the one failure where the merchant, not the buyer, absorbs the loss.

A timeout during settlement. A timeout does not mean the payment failed. It means the resource server did not hear back, and the facilitator may have settled. Paying a second time to cover a first that may have succeeded pays twice, and the second payment is as irreversible as the first. Treat the outcome as unknown, reconcile by hash, and consider a new payment only when the original is conclusively unsuccessful — a fact about the chain, not an absence of an answer.

Table 5. Five failures, what the operator sees, and the one action for each. Source: docs.x402.org, facilitator and client/server pages; x402 v2 specification; 30 October 2026.

Two habits separate a working setup from an expensive one. Decode PAYMENT-RESPONSE on success and on failure: it is the only place the outcome is stated, and a wrapper that reads it only on 200 learns about failures from timeouts instead. And branch on errorReason codes rather than message text, because the codes are the contract and the prose around them changes between releases.

The runbook for any payment of uncertain outcome, in four steps: read the record; if there is a hash, reconcile it on chain; if it settled, do not pay again; if there is no hash, escalate it as an unknown rather than retrying it as a failure.

What to watch weekly

A spending system produces four numbers worth reading weekly, and reading them is the part that gets dropped. Nothing reports a problem. It reports numbers, and a number becomes a problem when someone compares it with last week. Table 6 condenses the four.

Spend per day. Rising with deliverables flat is drift — usually a dearer model entering the mix, or a retry loop. Rising with volume is the system working. Falling with volume flat deserves a look in both directions: cheaper routing, or work quietly not being done.

Calls per task. The unit cost of a job. Rising means the task got harder, the answers got worse, or something is retrying. Falling means tighter prompts, or truncation — and truncation looks like efficiency and is not.

Refusals at the ceiling. Zero for a month means the ceiling is decorative: raise it to where it binds, or accept that it is insurance. Clustered at the end of a day means the daily cap is sized for the average and not the peak. Rising on one task means that task has outgrown its design.

Cost per completed deliverable. Spend divided by deliverables, and the only one of the four that ties money to output. A deliverable that takes twelve calls costs $0.084 at $0.00700 and $0.159 at $0.01325. Watch the direction rather than the level: spend flat with deliverables falling raises it, and that is the agent failing more often, not working harder.

Table 6. The four weekly numbers and how to read a change. Source: this site’s method. No tenant has been observed; the reading is arithmetic on measured prices, not a reported benchmark.

None of the four says whether the work was any good. That question is not in the record and will not be, which is why the deliverable count in the fourth number has to come from someone who read the output.

What this does not solve

Refunds and disputes. A settled transfer is not reversible inside the exchange. If the work fails after settlement, neither side has a mechanism to unwind it: the seller would have to send funds back as a separate transfer, at its own discretion. There is no chargeback and no adjudicator. Treat the price of a call as the price of finding out.

Service quality. Payment and delivery are one exchange and nothing more. No agreement, no warranty, no reputation and no history travel with it. A seller that returns a worse answer than its description promised has been paid, and the ceiling cannot reach this, because the ceiling is denominated in money and the problem is denominated in usefulness.

Privacy. The payment is a public transaction. Payer, recipient, amount and time are visible to anyone reading the chain, permanently. A stable recipient address links every call you make to one counterparty, and a wallet used for anything else links those activities together. An agent’s buying pattern is legible to anyone who looks.

Protection against a bad answer. Worth stating without hedging: the ceiling bounds spend, not error. An agent that spends its full allowance on wrong answers worked exactly as designed and produced nothing; the record will balance and the money will be gone. The ceiling is a spending control, not a quality control.

Asset and custody risk. The float sits in a token on a chain, and both are outside the protocol. The token contract, what backs it, the liveness of the chain and the route by which you obtained the asset survive a perfectly executed payment.

Your own numbers. A ceiling set to the wrong figure refuses the right call or permits the wrong one, and nothing in the system knows which. The three controls bound the damage; they do not remove the judgement that sized them.

This article does not advise on tax, accounting, or the legal treatment of holding and spending a digital asset. That needs an adviser with the facts of a specific entity, and no arrangement of ceilings substitutes for one.

Related

• what-is-x402 — the technical pillar: the two-round handshake, the schemes, and where the standard fails.
• custom-agentic-ai — the agents pillar: how a custom agent is assembled, and what the client owns.
• Service reviews, live: deepseek-review, qwen-review, hyperfusion-review, spiralstake-review.
• Service reviews, in build: wolfram-alpha-review, elevenlabs-review, mage-review.
• The service catalogue: https://x402.press/services/

Method note

Three sources, all read on 30 October 2026: our own measurements — 402 challenges decoded from the DeepSeek and Qwen routes, and the catalogue’s per-chain prices; the stated mechanics of the workspace, its opening balance and its three ceilings; and the protocol documentation at docs.x402.org for verification, settlement and the error codes.

Two limits on that evidence. The escalation figures above are arithmetic on measured prices with the mixing rate assumed, not observed; no tenant has been observed, and a modelled figure is not presented here as a measured one. And we have not tested the workspace’s refusal at a metered ceiling: the behaviour described follows from the stated rule that the workspace refuses the call that would cross a limit, so a team relying on it should confirm it with one deliberately over-costed call.

We have measured no latency, no throughput and no failure rate, and no figure of that kind appears here.

Filed under Agents · Tags: x402, agentic-ai, per-call-billing, settlement