Latest in AI
Brave Search x402: Pricing, Payment Limits and HTTP 402 Troubleshooting
Brave removes the account requirement for agent search, but a payment-enabled request needs tighter controls than an ordinary retry loop.
Brave added x402 payments to its Search API on November 12. An agent can buy a search without creating a Brave account or managing a Brave API key, using USDC on Base. The listed search price is $0.005 per request, but the payment challenge is the price to check before authorizing a transaction.
This is useful when a short-lived agent needs a small amount of web context. It is less compelling as a reason to replace a working, centrally billed search integration. Removing an API key does not remove the need to control spending.
What does Brave Search x402 cost?
Brave's announcement lists $5 per 1,000 requests for LLM Context and supported search endpoints. Gas is covered temporarily, not promised free indefinitely. The supported payment currency at launch is USDC on Base, so a balance on another chain should not be assumed usable.
For a hypothetical research workflow making 12 searches per task, the search charge is $0.06 per task. At 10,000 tasks, that becomes $600 before model inference or future transaction costs. If an agent doubles its searches while investigating weak results, the search bill doubles too. A per-request cap cannot enforce a per-task budget by itself.
There is no Brave subscription balance to top up on this route. The wallet holds the funds, and each search needs its own payment. The agent-payments guide identifies https://search.agent.s.brave.app as the account-free proxy and says the HTTP 402 response is authoritative for that exact request.
Check the payment challenge without spending money
A normal, unsigned GET is enough to inspect the offer. This command supplies no wallet or payment credential:
curl -i \
'https://search.agent.s.brave.app/res/v1/web/search?q=rust'
An unauthenticated request checked on November 13 returned HTTP 402, an empty body and a Payment-Required header. Decoding that header showed x402 version 2, Base network eip155:8453, an amount of 5000 and a 300-second timeout. No payment was signed and no paid search results were tested.
The amount uses six-decimal token units: 5000 means 0.005 USDC, not 5,000 dollars. Treat the decoded response as an offer to validate, not an instruction to spend. Check the expected host, route, network, token, recipient and amount against your application's payment policy before handing anything to a signer.
Why a client keeps getting HTTP 402
The proxy's current integration reference documents x402 V2 headers. An older client sending X-Payment is not using the expected payment header. The signed retry uses Payment-Signature; Payment-Response carries the receipt. A missing payment is supposed to receive a challenge; it is not evidence that the search service is broken.
| Response | First thing to check |
|---|---|
| Empty 402 with challenge headers | The initial unpaid request is behaving normally |
| 402 after an attempted payment | Client version, offer expiry and whether the exact advertised offer was accepted |
| 400 with conflicting payment headers | Remove the extra authentication/payment route |
| 404 | Confirm that this endpoint is sold through the proxy |
The Answers API, autosuggest, spellcheck and deprecated Summarizer are not sold through this proxy. Do not assume every endpoint supported by the conventional Brave API is available just by changing its hostname.
Keep payment retries outside the model's control
The reference says verification happens before search and settlement afterward. A failed search is not charged, and a returned result means payment settled. That still leaves an application problem when the client loses its connection and cannot tell whether a response arrived successfully.
A timeout is not proof that nothing was paid. Preserve request and payment records, distinguish an explicit failure from an uncertain outcome, and reconcile the latter before buying the same search again. Do not give the model an unrestricted instruction to keep paying until it gets a useful answer.
A sensible first deployment has an approved endpoint list, a maximum price per search, a search-count limit per task and a separate overall spending ceiling. Cache reusable results where appropriate. Keep private keys out of prompts and logs, and make the payment layer enforce limits even when the agent asks for more.
The interesting change is that search can become a capability an agent purchases at the moment it needs it. The engineering work moves from provisioning access to deciding exactly how much autonomy that purchase deserves.
I’m Paras. I work at the intersection of AI, engineering and distribution.
I help technical founders explain agent infrastructure and product changes in content developers can actually use.