What the wallet tool is

An AutoGen wallet tool is a reusable function that gives an agent the ability to pay. The agent calls it with a target, and the function, through a small local proxy, settles any 402 in USDC on Base and returns the result. The agent gets a wallet the way it gets any capability in AutoGen: as a registered tool the planner can call.

There is no Blockchain0x AutoGen package. AutoGen is Python and the x402 client ships for Node, so the wallet tool is a Python function that calls a tiny Node proxy holding the wallet. This page is the focused artifact; for the broad integration overview see autogen-payment-integration, and for the task walkthrough see how-to-add-payments-to-autogen-agent. The payment API product page is the reference.

Why a Node proxy

The payment client that answers a 402 and settles in USDC, @blockchain0x/x402, is Node-only, and AutoGen is Python. Rather than invent a Python package that does not exist, the wallet tool calls a small Node proxy that does the real x402 work and holds the wallet. It is about thirty lines, one process per wallet, and it keeps every payment identifier on the verified Node surface. The proxy is the same one used across the Python-framework guides; the AutoGen part is just the function that calls it and how you register it.

Register it on both sides

This is where AutoGen differs from a single-agent framework, and the difference is the one detail worth getting right. An AutoGen tool is used by two agents: the AssistantAgent decides to call it, and the UserProxyAgent executes it. So you register the wallet function twice, for LLM on the assistant and for execution on the proxy.

import requests
from autogen import AssistantAgent, UserProxyAgent

def pay_and_fetch(url: str) -> str:
    """Fetch a URL, paying in USDC if it requires payment. Returns the body."""
    res = requests.post("http://127.0.0.1:8787", json={"url": url}, timeout=30)
    return res.text if res.status_code == 200 else f"Failed: {res.status_code}"

assistant = AssistantAgent(name="researcher")
user_proxy = UserProxyAgent(name="user_proxy", human_input_mode="NEVER")

assistant.register_for_llm(name="pay_and_fetch", description="Fetch a URL, paying in USDC if required.")(pay_and_fetch)
user_proxy.register_for_execution(name="pay_and_fetch")(pay_and_fetch)

Start the proxy (node pay-proxy.mjs, the thirty-line service from the walkthrough), register the function on both agents, and the assistant can pay. Forget the execution registration and the planner will call a tool that never runs; that is the most common slip, so wire both.

One tool per agent wallet

In a multi-agent group chat, each agent should keep its own wallet. Run one proxy per agent on its own port with that agent's key, and bind each agent's function to its proxy port with a small factory.

def make_pay_tool(port: int):
    def pay_and_fetch(url: str) -> str:
        res = requests.post(f"http://127.0.0.1:{port}", json={"url": url}, timeout=30)
        return res.text if res.status_code == 200 else f"Failed: {res.status_code}"
    return pay_and_fetch

researcher_pay = make_pay_tool(8787)  # researcher's proxy/wallet
writer_pay = make_pay_tool(8788)      # writer's proxy/wallet

Register each agent's function (for LLM on that assistant, for execution on its proxy) and you have two agents, two proxies, two wallets, the same factory. The dashboard attributes spend per agent, and a compromised agent can only spend its own balance. Shared code, separate accounts, which is exactly what a GroupChat of paying agents wants.

Write the description for the planner

An AutoGen assistant decides whether to call a tool from the description you pass to register_for_llm, so that string is doing real work. Say plainly what the tool does and when to use it: that it fetches a URL and pays if the URL requires payment, and that it returns the response body. That is usually enough for the planner to reach for it when a task needs a paid resource and to leave it alone otherwise.

Decide deliberately whether to mention cost. If you want the planner to weigh price, note that calls may cost a small amount in USDC; if you would rather it not hesitate over routine sub-cent calls, leave cost out and let the wallet's spend limit be the control. Either is valid, but be intentional, because a vague description ("use the wallet") leaves the planner guessing about when the tool applies, while a precise one ("fetch a URL, paying in USDC if required") tells it exactly. The function body is small; the description is where you actually shape the agent's behavior around it.

Verify the round trip

Before trusting the tool in a real run, prove the round trip on Base Sepolia. Start the proxy with a sk_test_ key, fund the agent's wallet with test USDC, and prompt the assistant with a task that needs a paid URL. Watch for three things: the assistant decides to call pay_and_fetch, the user proxy executes it, and the proxy settles the 402 and returns the body. Then check the dashboard for a matching payment.sent on that agent.

If the assistant calls the tool but nothing runs, you registered it for LLM but not for execution; if it never calls the tool, the description is too vague. Both are quick fixes, and catching them on testnet costs nothing. Once the round trip holds, swapping the proxy's key to sk_live_ moves it to Base mainnet unchanged.

Compatibility

Because the wallet tool is an ordinary registered function, it works across AutoGen's surfaces.

When to use it

Reach for the wallet tool when agents in a group chat need to pay for what they call and you want that capability as one reusable unit rather than per-tool glue. It fits when several agents share the same paying behavior, since you build the function once and bind it per agent, and when payment should be a capability the planner can invoke deliberately.

It is the wrong shape when only one specific tool should ever pay (wrap that tool's own call through the proxy instead) or when the group is fully internal with no paid calls. Match it to whether paying is a general capability the agents need or a one-off behavior of a single tool.

Pricing

The tool is free; you build it from open packages. What you pay is the wallet platform fee per agent on the pricing page: Free is $0 per agent per month at a 5% transaction fee, Pro is $9 at 2%, and Business is $29 at 1%. Per-agent pricing means each agent that transacts through its function is billed on its own wallet, so a group where only two agents pay only incurs fees for those two.

What to ship today

Start a proxy with a sk_test_ key, write the pay_and_fetch function, register it for LLM on an AssistantAgent and for execution on a UserProxyAgent, and make one paid call on Base Sepolia. For a group chat, run a proxy per agent and bind each function to its port with the factory. For the broad integration overview see autogen-payment-integration. Pricing is on the pricing page.