Looks like a rate-limit error. It isn’t. It’s one of the more interesting design quirks of how AntSeed handles micropayments — and once you understand what’s happening, the fix takes about 60 seconds.
If you’re using AntSeed to route AI requests through peer providers (via OpenClaw, Hermes, or any OpenAI-compatible client pointed at the local buyer proxy), there’s a good chance you’ll eventually run into something like this:
Rate limited after 3 retries — HTTP 402: {
"error": "payment_required",
"minBudgetPerRequest": "1000",
"suggestedAmount": "1000000",
"requiredCumulativeAmount": "9998575",
"currentSpent": "9997575",
"currentAcceptedCumulative": "9980223",
"channelId": "0xb433...f7162",
"reserveMaxAmount": "10000000",
"inputUsdPerMillion": 0.12,
"outputUsdPerMillion": 0.6,
"cachedInputUsdPerMillion": 0.72
}This is exactly what happened to me, and exactly what I did to resolve it.
To understand the error, you need a quick mental model of how AntSeed handles payments.
If AntSeed sent a separate on-chain USDC transaction for every API call, you’d pay more in gas fees than the inference itself cost. So instead, AntSeed uses payment channels — a well-known crypto pattern for off-chain micropayments.
Here’s the lifecycle:
A channel is essentially a prepaid tab with one provider. Both sides agree on running totals off-chain, and only the final number ever hits the blockchain.
Now the error fields make sense. All amounts are in USDC base units where 1,000,000 = $1.00:
| Field | Value | In dollars | Meaning |
|---|---|---|---|
reserveMaxAmount | 10000000 | $10.00 | Total USDC locked in the channel |
currentSpent | 9997575 | $9.997575 | What you’ve actually spent |
currentAcceptedCumulative | 9980223 | $9.980223 | Last receipt the provider has accepted |
requiredCumulativeAmount | 9998575 | $9.998575 | What the next request would push you to |
minBudgetPerRequest | 1000 | $0.001 | Minimum headroom required to accept any new request |
suggestedAmount | 1000000 | $1.00 | What they’d suggest you add to keep going |
channelId | 0xb433…f7162 | — | The specific channel that’s full |
Translation: the channel was funded with $10, you’ve burned through $9.997 of it, and there’s only ~$0.0024 of headroom left — less than the $0.001 minimum needed for the provider to accept another request.
The provider isn’t throttling you. They’re correctly refusing to accept work they can’t be paid for. The receipts in this channel are at the cap.
This was my first reaction. I ran:
antseed buyer balanceAnd got:
Wallet: 0x42...9A9F
USDC Balance (wallet): 0.0 USDC
Deposits Account:
Available: 10.588692 USDC
Reserved: 1.016264 USDCPlenty of credits. Why is it failing?
Because deposit balance and channel reserve are two different things:
┌─────────────────┐ open / extend ┌──────────────────┐ spend per request ┌──────────┐
│ Your deposit │ ─────channel──────► │ Channel reserve │ ──────────────────────► │ Provider │
│ (escrowed pool)│ │ (this provider) │ │ │
└─────────────────┘ └──────────────────┘ └──────────┘A channel hitting its reserveMaxAmount doesn’t automatically pull more USDC out of your deposits. It needs to be settled and closed first, then a new channel opens for subsequent requests. (The proxy can sometimes auto-extend, but in many cases — and certainly in mine — it didn’t.)
antseed buyer channelsOutput:
Payment Channels (4 of 4):
0xb433...f7162 active buyer
Peer: 0e4912... Requests: 1083 Tokens: 15890994
Deposit: 10.028698 USDC Settled: 0.0 USDC Unsettled: 10.028698 USDC
0x27ae...e6xx settled buyer
Deposit: 11.063901 USDC Settled: 10.951681 USDC Unsettled: 0.11222 USDC
0x3a7d...58xx settled buyer
Deposit: 8.444783 USDC Settled: 8.444783 USDC Unsettled: 0.0 USDC
0x2e09...d9xx settled buyer
Deposit: 0.014844 USDC Settled: 0.014844 USDC Unsettled: 0.0 USDCThere it is. The active channel 0xb433… has:
The pattern across the older channels is also visible: every channel goes through active → drained → settled → closed → new channel opens. That’s the normal lifecycle.
This wasn’t a bug. The channel had simply done its job and now needed to be settled so a fresh one could take over.
antseed paymentsThis launches the AntSeed payments portal at a localhost URL in your browser.
The payments portal asks you to connect a wallet so it can authorize on-chain transactions (settling a channel is one tx; opening a new one is another). I connected my browser wallet — same address as the buyer wallet AntSeed reported (0x42…9A9F).
Important: the wallet needs a small amount of the native gas token (e.g. ETH on Base) to pay for the settlement transaction. USDC alone isn’t enough — that’s the asset being moved, not the gas. If your wallet is bone dry on the native token, top it up with a few dollars worth before continuing.
In the dashboard’s channels list, I located the row matching 0xb433…f7162 — the same channelId from the 402 error. It showed:
I clicked Close (some builds label it Settle & Close), and approved the transaction in my web wallet.
This took about 30–60 seconds to confirm.
That’s it. I opened a new chat in OpenClaw / Hermes and sent a message. The buyer proxy:
No more 402. The error was completely resolved by closing the drained channel and letting the proxy spin up a fresh one.
Clients like Hermes wrap the 402 in a retry loop (“Rate limited after 3 retries…”). That’s misleading. HTTP 402 is “Payment Required,” not “Too Many Requests” (429). The retry loop assumes transient throttling, but a payment-channel cap doesn’t go away with retries — it goes away when the channel is settled. The misleading wording is a client-side issue, not an AntSeed protocol issue.
If your client says “rate limited” and you see payment_required in the JSON body, you’re hitting the channel cap, not a throttle.
The root cause for me was that I’d been running an expensive frontier model (Claude Opus 4.7 at $0.12 in / $0.60 out per 1M tokens) through a default-sized $10 channel. At 1,083 requests per day, a $10 channel drains in about 24 hours — meaning I’d have to settle and reopen daily.
Two fixes, either of which dramatically reduces channel churn:
Edit your buyer config (typically ~/.antseed/config.json) and bump the channel reserve up to $25 or $50. Bigger channels mean fewer settlements. With a $50 channel at the same usage, I’d settle roughly every 5 days instead of daily.
For agent workflows, models like kimi-k2-thinking ($0.015 / $0.064 per 1M) deliver near-frontier performance at roughly 1/10th the cost. The same workload that was burning $10/day on Opus runs around $1.30/day on Kimi K2 Thinking. Channels last weeks instead of hours.
For most agentic use cases I now run cheaper open models as the daily driver and reserve frontier models for tasks that genuinely need them.
| Symptom | Likely cause | Fix |
|---|---|---|
| 402 payment_required with currentSpent ≈ reserveMaxAmount | Channel hit its cap | Close the channel, send a new request |
| 402 only on certain models | Per-model channel issue | Same — close that channel |
| antseed buyer balance shows ample deposits but error persists | Drained channel hasn’t been settled yet | Close it via antseed payments |
| Close button doesn’t work / nothing happens | Wallet has no native gas token | Top up wallet with a few dollars of ETH (or chain native) |
| Channel still active minutes after clicking close | Tx pending or local state not synced | Wait 1–2 min, then restart antseed buyer start |
The 402 payment_required error is not a bug, not a failure, and not a sign you’re out of money. It’s the payment-channel system working as designed — telling you that a specific channel has done its job and needs to be settled so a new one can take over.
The fix is genuinely simple once you know it:
antseed paymentschannelIdTook me about a minute. And now that I understand what’s actually happening under the hood, I treat it as a routine maintenance event rather than an error.
If you’re building on AntSeed or running agent workflows through it, learning to read the channel state is one of the more valuable skills — it demystifies basically every payment-related issue you’ll encounter.
💬 Comments