x402 Upto Usage-Based Pricing: agentwallet-sdk Compatibility Confirmed

The most important change in x402 this month is not another exact-price payment demo.

It is upto.

That billing pattern fixes a real agent problem: the seller often knows the maximum possible cost before the job starts, but not the final amount until the work finishes. Think token-based inference, variable compute, metered search, or multi-step data retrieval. Exact pricing is awkward there. Cap-based authorization is a better fit.

The good news is that agentwallet-sdk is already aligned with this model.

As of npm current, agentwallet-sdk@6.2.0 explicitly ships with "x402 upto billing policy accounting" in the package metadata. And the exported UptoBillingPolicy implementation shows the exact accounting model agent operators need:

• authorize a maximum amount up front
• record one or more actual settlements later
• release any unused headroom at the end
• keep wallet-visible ledger deltas for authorization, settlement, and release

That is what usage-based agent billing is supposed to look like.

Why upto matters

For a lot of agent workloads, price is probabilistic at the start.

A seller can say, "this task will cost no more than $5," but the actual charge might land at $1.24 after the run completes. The buyer wants a hard cap. The seller wants permission to settle the actual amount without forcing another round trip.

That is the right trade for autonomous systems.

The wallet approves a ceiling. The service settles only what it used.

What agentwallet-sdk already implements

The SDK now exports a real UptoBillingPolicy type with explicit authorization and settlement records. It is not hand-wavy compatibility. The package models the actual state transitions:

• authorize(request) creates the max authorization
• recordSettlement(authorizationId, amount, options) records actual usage
• finalizeAuthorization(authorizationId) releases unused capacity
• getSnapshot() returns the authorization, settlement records, and ledger deltas

That matters because usage-based billing always creates two accounting questions:

1. What was the buyer willing to pay at most?
2. What amount actually left the wallet?

UptoBillingPolicy answers both.

A concrete example

This is the shape of the flow in agentwallet-sdk today:

import { UptoBillingPolicy } from 'agentwallet-sdk';

const policy = new UptoBillingPolicy();

const auth = policy.authorize({
  service: 'prediction-signal-api',
  resource: '/v1/simulation',
  network: 'base:8453',
  asset: 'USDC',
  payTo: '0xFeedProvider',
  maxAmount: 5_000_000n, // 5.00 USDC with 6 decimals
  metadata: { runId: 'run-042' },
});

const snapshot = policy.recordSettlement(auth.authorizationId, 1_240_000n, {
  txHash: '0xabc123',
  reference: 'run-042-final',
  finalize: true,
});

console.log(snapshot.authorization.maxAmount);      // 5000000n
console.log(snapshot.authorization.settledAmount);  // 1240000n
console.log(snapshot.authorization.releasedAmount); // 3760000n
console.log(snapshot.ledgerDeltas);

That is the whole point of upto. The agent authorizes up to 5.00 USDC. The seller settles 1.24 USDC. The remaining 3.76 USDC is released, not charged.

Why this is EVM-compatible by design

Nothing about this accounting pattern fights the EVM.

In fact, it fits cleanly with how agent wallets already operate on Base and other EVM rails:

• authorization is a local policy event with a defined cap
• settlement is anchored by a real payment and optional tx hash
• released headroom remains visible in the accounting layer
• the wallet operator can inspect net deltas after the run

That makes upto practical for x402 sellers without forcing every framework to invent its own post-settlement ledger.

How this fits the rest of the SDK

The compatibility story is stronger because UptoBillingPolicy does not sit alone.

The same package also ships:

• x402 client support for handling 402 payment-required flows
• budget tracking and per-service spend summaries
• SpendingPolicy guardrails for transaction and daily limits
• non-custodial wallet control, so operators keep their own keys

Put together, that means an operator can approve a bounded usage-based workflow without giving the service or the agent an unlimited tab.

Why sellers should care

If you are building an x402-protected API, upto will likely expand the set of workloads you can charge for.

Exact-price calls are fine for fixed endpoints. They are a bad fit for variable execution. Metered pricing removes that friction.

The missing piece has been buyer-side accounting that does not turn into a mess.

agentwallet-sdk@6.2.0 closes a big part of that gap right now.

Why buyers should care

For agent operators, this is a control story as much as a payment story.

A good buyer wallet should let you say:

• this service can charge up to this cap
• settle only actual usage
• show me exactly what was reserved, charged, and released
• give me a ledger I can tie back to a run ID

That is exactly what the SDK's UptoBillingPolicy exposes.

Bottom line

x402 usage-based pricing is no longer theoretical. The upto model is live, and agentwallet-sdk@6.2.0 is already compatible with it.

For agent commerce, that is a big deal.

The winning payment stacks will not just move money. They will make variable-cost work auditable, bounded, and easy to reconcile after the fact.

This one already does.

This article was written with AI assistance. The npm metadata, exported SDK types, and code example were validated against the published package before publication.