From API Credits to Inference Costs: How CAI Wallets Handle Agent Spending Across AI Providers
When a developer runs agents across multiple inference providers, each provider wants its own billing method. OpenRouter needs a top-up. Together AI bills monthly. A local GPU provider takes USDC on Base. The developer winds up managing three wallets, four API keys, and a spreadsheet that no one updates.
That situation is what CAI's custodial wallet was designed to replace. Instead of each provider getting a separate payment relationship, the wallet becomes a single payment address that any compatible provider can bill against.
The wallet as operating account
CAI gives every user a custodial wallet on six chains (ETH, BSC, POLYGON, ARB, BASE, TRON) where balances are denominated in USDT, USDC, DAI, and native gas. The wallet is not a standalone product. It is the balance layer under an agent's operating account. When an agent needs to pay for something, it checks identity and balance first, then executes a transfer after the user confirms the recipient and amount.
The API surface for this is three endpoints:
POST /get-wallet-balances { "chains": ["base", "arb"] }
POST /resolve-transfer-recipient { "chain": "base", "to_local_part": "user" }
POST /wallet-custodial-transfer { "chain": "base", "token": "USDC", "amount": "5.00", "to_address": "0x..." }
The user confirms the full parameters before any funds move. The agent never holds a signing key.
x402 for pay-per-call
For providers that expose an HTTP 402 Payment Required flow, CAI's x402 adapter lets agents pay per API call without pre-funding an account. The agent detects the 402, calls x402_payment_prepare with the challenge data, the user confirms (or an active mandate covers it), then x402_payment_execute completes the payment and returns proof.
POST /x402-payment-prepare {
"resource_url": "https://api.provider.com/chat",
"recipient_address": "0x...",
"amount": "0.50", "chain": "base", "token": "USDC"
}
# user confirms
POST /x402-payment-execute { "attempt_id": "...", "user_confirmed": true }
The provider receives settlement and the agent gets the resource. No API key exchange, no pre-payment balance to track.
Payment mandates for automated spending
When the agent runs autonomously (batch inference, overnight fine-tuning, scheduled data processing), the user sets up a payment mandate that delegates spending within defined limits:
POST /payment-mandate-create {
"merchant_domain": "compute.provider.com",
"max_amount_per_payment_usd": "10",
"daily_cap_usd": "200",
"expires_in_hours": 168
}
The user approves the mandate once. After that, the agent can pay within those bounds without asking for confirmation on every call. The mandate can be revoked at any time via payment_mandate_revoke, and the user can inspect active mandates with payment_mandate_status.
How providers accept CAI payments
A provider does not need to integrate a new payments SDK. CAI settles in USDC (or USDT, DAI) on any of the six supported chains, which most crypto-native infrastructure providers already accept. For providers that want the x402 flow, CAI publishes the x402 challenge spec and adapter endpoints. The provider returns HTTP 402 with a JSON body containing the recipient address, amount, chain, and token. CAI's payer adapter handles the rest.
Providers that want a simpler path can publish a static payment address and let agents call POST /wallet-custodial-transfer directly after the user confirms the amount. No middleware, no escrow, no settlement delay.
Guardrails built in
Every payment flow includes product-level safeguards. Spending for new recipients always requires explicit confirmation even when a mandate exists. The agent proposes, the wallet confirms, and the signing key never enters the tool call. Users set their own caps per mandate (the daily_cap_usd parameter on payment_mandate_create). The vault product at CAI handles encrypted credential storage for site logins and platform API keys as a separate surface.
The practical scenario
An agent running a nightly batch job needs 100 inference calls across three providers. Without CAI, the developer funds each provider separately, watches three balance dashboards, and handles refunds through three support channels. With CAI, the developer deposits USDC once on Base, sets a mandate for the job's $50 budget, and the agent pays each provider from the same wallet, with every spend logged in wallet_activity_list for audit.
The same pattern scales from a single batch job to a fleet of agents running across providers. One wallet, one set of spending rules, one audit trail.
CAI is at https://cai.com. The developer docs and API contract are at https://cai.com/developers.html. The skill.md file at https://cai.com/skill.md has the full tool reference.
