When the Agent Pays per Inference Call

The agent I built in June was a researcher that paid for premium articles, the use case one reader called the obvious first one [10]. In the production case study AWS published on 8 October, the agent buys model calls instead.

The demo from June

In June I built a Strands research agent on AgentCore payments with a $1.00 session that expired after eight hours. It bought from four simulated publishers on Base Sepolia (a test network) at $0.001 to $0.015 per article [10]. The post before it had explained why HTTP 402 waited three decades for a payer that doesn’t mind tiny charges [9], and the post after it moved the paywall onto AWS WAF so the publisher side needs no edge code [11]. The code for all of it is in the demo repository [12]. Every price in that demo was fixed and known before the agent paid, which isn’t true for metered inference.

What runs in production

AWS published the case on 2026-10-08 [1]. BlockRun is a pay-as-you-go inference router that serves more than 90 models from more than 15 providers over x402 and quotes and settles each call on its own. Incarna, built by SpreadX, gives agents a persistent identity with its own wallet. The chain shows that wallet as the payer, and Incarna ties the wallet to one agent identity [1] [2].

Incarna’s agents run on AgentCore and call BlockRun. BlockRun answers with a 402 carrying the payment requirements for that specific call. The agent opens a payment session and calls ProcessPayment. AgentCore payments checks the quote against the session’s limits and signs from the agent’s wallet. Then BlockRun verifies the signature and serves the inference [1]. Wallets are provisioned through the Coinbase CDP connector. The customer owns the wallet and grants Incarna delegated authorization to use it [1].

AWS reports that the integration took three days, one to build and two to test. The original scope had been two to three months, and the application code came to about 200 lines. Across the beta, agents processed more than 1,000 payments between $0.001 and $0.05 per call, each settled on-chain [1]. That’s a beta figure. It shows the path works end to end and says little about volume. The per-call prices, though, overlap with my demo’s article prices.

How the upto scheme works

The request loop is the one from Part 2. What changes is the 402, which can now carry a ceiling instead of a fixed price.

My demo used the exact scheme. The publisher said “this article costs $0.015” and the agent signed exactly that [10]. A metered inference call has no such price, because nobody knows how many output tokens the model will produce until it has produced them.

The upto scheme handles that case. The agent authorizes a maximum, the seller does the work, and at settlement the seller charges the actual amount, which must be less than or equal to the authorized maximum and may be zero [6]. Each authorization is single-use, time-bound, and bound to the recipient’s address, so the seller can’t redirect it or settle it twice [6]. AgentCore payments supports both exact and upto, and upto arrived with general availability in August [1] [2].

upto also comes with requirements. It needs x402 version 2 and an EVM network [13], and it settles through the Permit2 contract, so the paying wallet must first grant Permit2 an allowance. AgentCore payments can submit that approve transaction for you when you pass permit2AllowanceLimit, and the transaction costs gas, paid from the wallet’s native token balance [5]. Since approve overwrites the existing allowance, you pass the field only when the wallet needs approving, for example on its first upto payment [5]. With exact there is no Permit2 allowance to manage, which is why my demo never touched it.

upto also moves some trust to the seller. The buyer signs a ceiling and then has to trust the seller’s report of what was used, because it can’t see the seller’s meter or pricing calculation. The ceiling bounds how wrong that report can be on a single call, and the per-call settlement on-chain gives you a record to reconcile against.

Sizing the budget when the price is a ceiling

A payment session has two configurable caps, a maximum spend in a currency and an expiry time. AgentCore payments checks every payment against the session before signing and rejects anything that would push the session past its cap [2] [3]. Setting the caps is one create_payment_session call.

session = manager.create_payment_session(
    user_id="test-user-123",
    limits={"maxSpendAmount": {"value": "5.00", "currency": "USD"}},
    expiry_time_in_minutes=1440,
)

The AgentCore SDK call from the developer guide [4], with a 24-hour expiry and a $5 cap as example values for a day of inference calls.

My demo opened one session per research task, and a task bought a handful of articles and was done. Incarna sizes its sessions to a day’s budget [1], which makes sense when the agent makes calls all day.

AWS describes the budget check in three phases: the requested amount is reserved atomically, the payment is processed, and the reservation is committed on success or rolled back on failure [7]. A signing failure gives the budget back [3]. For an upto payment the requested amount is the ceiling. What the documentation I read does not say is whether the session gets back the difference when the seller settles for less. Until that is clear, I’d size a session as if each call costs its full ceiling. If AgentCore keeps the full ceiling reserved against the session, a ceiling well above the typical call could exhaust a day’s session long before the money is actually spent, so the ceiling the seller advertises matters to the buyer’s budget as much as the price does.

Demo versus production

Sources: my demo [10] [12]; production [1].

The session check is the same in both columns, and both pay from a Coinbase CDP wallet through AgentCore payments. Production adds customer ownership of the wallet and a delegated authorization to Incarna. The scheme and the session size differ because the price is not known before the call.

Why the cap lives outside the model

In Part 2 I wrote that the agent proposes and deterministic policy disposes [10]. The case study makes the same point. AgentCore payments enforces limits outside the model, so an agent can’t exceed them even if its prompt is manipulated [1], as long as its role can’t configure sessions [8]. The check is deterministic and runs at the infrastructure layer [2].

Buying articles meant a few purchase decisions per task. Paying per model call means a payment decision on every step of the loop, and any text the agent reads, including a tool result or a 402 body, can try to steer it. So the cap matters more here. It doesn’t stop the agent from wasting money inside the limit, though.

Two more controls sit next to the cap. The documented IAM pattern separates the role that configures sessions, which is explicitly denied ProcessPayment, from the role that executes payments, so no single role can both raise a budget and spend against it [8]. And the docs recommend starting with the smallest maxSpendAmount the task needs and a short expiry, then raising both as the agent proves itself [8].

What I’d change in my demo

I haven’t changed the repository for this post. If I extend it, I’d start here:

1. Add a small metered seller endpoint that returns an upto ceiling and settles the actual amount, so the buyer agent faces a price it can’t know up front.
2. Run a day-sized session next to the task-sized one, to see how a ceiling-heavy workload drains each.
3. Add a reconciliation step that compares the session’s remaining amount with the on-chain settlements for the same calls.

Questions I still have

The case study answers whether agents can pay per call. What I’d still want to know before running this with real money:

• Where does a buyer check the seller’s usage report against what the chain settled, at scale? With upto, the usage report comes from the seller and the settlement record comes from the chain.
• What happens when an inference call returns nonsense? It has still been paid for. I did not implement refund or dispute handling in my demo [10], and the production sources I cite don’t describe it.
• Who picks the ceiling, and who carries the cost when it is wrong? If it’s too low the call fails, and if it’s too high the buyer’s session may drain early, depending on whether the unused part of the ceiling comes back.

If you run agents that pay per call, or you sell inference over x402: how do you choose the ceiling?

Sources

• [1] Pay-per-inference for AI agents: How BlockRun and Incarna use Amazon Bedrock AgentCore payments — AWS Machine Learning Blog, 2026-10-08
• [2] Amazon Bedrock AgentCore payments is now generally available — AWS Machine Learning Blog, 2026-08-18
• [3] AgentCore payments: Enable secure microtransaction payments for AI agents — Amazon Bedrock AgentCore Developer Guide
• [4] Create a payment session — Amazon Bedrock AgentCore Developer Guide
• [5] Process a payment — Amazon Bedrock AgentCore Developer Guide (schemes and Permit2 allowance)
• [6] Scheme: upto — x402 specification
• [7] Technical deep dive: AgentCore payments and innovation in agentic commerce — AWS Machine Learning Blog, 2026-05-26
• [8] Payments security best practices — Amazon Bedrock AgentCore Developer Guide
• [9] HTTP 402: The 30-Year Placeholder That AI Agents Finally Activated — schristoph.online, 2026-05-19
• [10] I Built the Agent That Pays — Here’s What I Learned — schristoph.online, 2026-06-03
• [11] Getting Paid by Agents: A Managed Paywall at the Edge — schristoph.online, 2026-06-23
• [12] agentcore-payments-media-demo — demo repository on GitHub
• [13] Troubleshooting AgentCore payments — Amazon Bedrock AgentCore Developer Guide (x402 payment request errors)