0xGasless AgentKit: custodied wallets for LangChain agents, with spend caps set server-side

The gap AgentKit fills: an agent that can spend, not just call

Most LLM tool integrations end at a read. The model fetches a page, queries an API, writes a file. The moment the useful action costs money, you are back in human territory: someone provisions an API key, someone tops up a balance, someone decides whether this particular call is worth five cents. AgentKit is aimed at the case where that decision has to happen inside the agent loop, at machine speed, without a person in the path. The README frames it plainly: give the agent a wallet and hands. The wallet is custodied by 0xGasless in a KMS, so no private key sits in your process. The hands are a set of tools the model can call, some free, some paid per invocation. The target user is a builder already working with an agent framework (the quick start uses LangChain's createReactAgent and ChatOpenAI) who wants payment, tool rental and counterparty reputation exposed as ordinary function calls. It is not a DeFi SDK for humans, and it is not a wallet library. It is a client for a hosted platform, and every capability it advertises inherits that dependency.

Two modes, and the line between them is the whole product

The README splits usage into platform mode (recommended) and self-custody mode, and the split is not cosmetic. In platform mode the wallet lives in 0xGasless KMS, spending is governed by a server-enforced policy, and the API key from your dashboard project authenticates every action. You get payments, tools, identity, spend limits and audit. In self-custody mode you hold a local private key or mnemonic behind an ERC-4337 smart account and get classic gasless DeFi actions. The trade is legible: platform mode buys you a policy engine and an audit trail at the cost of trusting a third party with custody; self-custody buys you key ownership at the cost of building your own guardrails. The README does not describe how the self-custody path handles policy or caps, and it does not describe a migration path between the two, so treat the choice as a fork you make before writing code rather than a setting you flip later. For anything that spends real money autonomously, the server-enforced cap in platform mode is the more interesting half of the design, because a cap the agent cannot edit is a different kind of control than a cap in your own process.

How a paid tool call actually flows

The mechanism is x402, an HTTP payment flow. The README's worked example is worth reading closely because it shows the whole chain. The user asks the agent to find a tool that can read a web page, then read https://example.com and summarize it. The agent calls search_tools, discovers a web-reader tool listed as free, runs it, and the README states it pays roughly $0.05 in USDC from the custodied wallet via x402, settled on Avalanche by the 0xGasless facilitator, and gets the page back. Two things follow from that. First, the agent needs zero native gas token: the facilitator pays gas, and the agent's only expense is the stablecoin. Second, the discovery step is itself an action (search_tools) against the 0xGasless Tool Gateway, which the README says is backed by Apify's actor marketplace. The paid surface is therefore two-layered: you pay for the tool call, and the tool call is found through a gateway that decides what is listed. The toolkit exposes a guarded http_request for free or public APIs, which is the escape hatch when you do not want to route through the gateway. The README does not document the guard's rules, so if you plan to rely on http_request, that is a gap to close against the package README before you build on it.

Getting it running: one install, one configure call, one prompt

The install is a single npm package: npm install @0xgasless/agentkit. Configuration is Agentkit.configureWithPlatform, which takes apiKey, agentId and chain. The README points at Dashboard then Project then Auth then API Key for the key, and its example passes process.env.OXGAS_API_KEY. The chain in the example is avalanche-fuji, the testnet. Tools come from new AgentkitToolkit(agentkit).getTools(), which returns the array you hand to your agent framework; the example feeds it to createReactAgent alongside a ChatOpenAI model. Invocation is a normal message array. There is a runnable end-to-end demo at agentkit-core/examples/pay-for-tools.ts, and the README says getAllAgentkitActions() enumerates the full action set, which matters because the README's action lists are grouped by theme rather than exhaustive. The published package lives under agentkit-core/, alongside a MIGRATION.md covering the 0.0.x to 1.0 upgrade, and a separate agentkit-demo/ directory with a LangChain chatbot. If you are on 0.0.x, read MIGRATION.md before upgrading: the presence of a dedicated migration guide implies breaking changes between those lines, and the README does not summarize them.

The action surface, grouped by what it costs you

Money actions in platform mode are x402_pay, pay_api, smart_transfer, get_spend_status and get_agent_wallet. pay_api is the interesting one: it auto-pays any 402 endpoint, capped. That is a general-purpose capability, not a fixed price list, and it means the spending policy is doing real work rather than rubber-stamping a known vendor. get_spend_status is the introspection call you want in a loop, since it tells the agent where it stands against the cap. Internet actions are search_tools, call_tool, browse_web and the guarded http_request. Trust actions are register_identity, check_agent_reputation and give_agent_feedback, built on ERC-8004, which the README describes as an on-chain identity standard. The reputation check is the piece with the most obvious operational value: before paying an unknown counterparty, the agent can look up whether that counterparty has a history. Whether that history is populated for the agents you care about is an empirical question the README cannot answer, and an empty reputation registry is worse than no registry, because it reads as a clean record. DeFi actions are available in both modes and cover transfers, swaps and bridges via deBridge, disperse, token details and market data via DexScreener.

Chain coverage is narrower than the action list suggests

This is the constraint most likely to disqualify the project for a given reader, and it is easy to miss because the action list is long. Avalanche C-Chain (43114) and Avalanche Fuji (43113) are the primary, fully supported networks. Base (8453), Sonic (146) and BSC (56) are available for self-custody DeFi actions. Read that second sentence carefully: the multi-chain story applies to DeFi actions in self-custody mode. The README does not state that x402 payments, Tool Gateway calls or ERC-8004 identity work on Base, Sonic or BSC. If your agent's job is to pay for API calls, you are choosing between Avalanche mainnet and Fuji testnet. That is a real narrowing, and it interacts with stablecoin choice: the README names USDC and XSGD as the payment stablecoins, and XSGD is a Singapore dollar token with a much thinner footprint than USDC. A team whose treasury is on Base and whose agent needs to pay per call has a bridging problem the toolkit does not solve for them. The README also gives no per-chain breakdown of which DeFi actions are live where within self-custody mode, so verify action by action rather than trusting the chain list as a compatibility matrix.

The hosted dependency, and what it costs you over time

Platform mode means the API key authenticates every action and the wallet sits in 0xGasless KMS. If the platform is unreachable, or your key is revoked, or the facilitator stops settling, the agent loses its ability to pay and to rent tools. There is no documented offline path in the material provided: the actions are calls against a hosted service, not local primitives. Self-custody mode removes the KMS dependency for DeFi actions but the README does not describe how payments, the Tool Gateway or identity behave there, so it is not a drop-in fallback for the platform features. On maintenance, the material supports only a limited read. The repository is not archived, the last push is dated 2026-08-10, and no releases were retrieved, which means versioning and changelog discipline cannot be assessed from what is here. The existence of MIGRATION.md for 0.0.x to 1.0 tells you the project has already made one breaking jump, and pinning your dependency version is the obvious response. On licensing: the README states Apache-2.0 in its License section, but the repository metadata reports NOASSERTION, meaning the licence could not be identified automatically. That discrepancy is worth resolving with the maintainers before you depend on the code commercially; it is a metadata question, not a legal conclusion, and I am not giving legal advice. The npm package is the artifact you would actually ship, so check the licence field on the published package as well as the repository.

Where it sits next to Coinbase's AgentKit

The nearest thing to a direct comparison is Coinbase's AgentKit, and the difference is architectural rather than feature-level. Coinbase's toolkit is built around the CDP SDK and wallet providers you configure yourself, including self-custodied wallet providers, with the action surface oriented toward onchain operations and framework adapters for LangChain, Vercel AI SDK and others. 0xGasless AgentKit makes the opposite bet: the wallet is custodied by the vendor in KMS, the spending policy is enforced on the vendor's servers, and the payment rails (x402, the facilitator, the Tool Gateway) are the vendor's too. The practical consequence is that 0xGasless gives you a spend cap you did not have to implement and an audit trail you did not have to build, in exchange for a custody and availability dependency that a self-configured provider would not impose. If your requirement is that the key never leaves your infrastructure, the Coinbase-style arrangement is the one that satisfies it, and 0xGasless self-custody mode is the partial answer within this project. If your requirement is that an autonomous agent cannot exceed a budget, the server-enforced policy here is the more direct fit. Neither is strictly better; they fail in different directions.

Editorial conclusion

Adopt it if your agent needs to pay for something on the open internet and you would rather not run key management or a gas tank yourself; the platform mode puts the wallet in 0xGasless KMS and the ceiling on spending in server-side policy, which is the only arrangement here that is defensible in production. Do not adopt it if you need a chain outside Avalanche C-Chain and Fuji for payments, tools or identity: Base, Sonic and BSC are listed for self-custody DeFi actions only, and the README does not say which actions work where beyond that split. Before you commit, verify three things against the live service: that your dashboard project actually exposes an API key under Project then Auth, that check_agent_reputation returns something useful for the counterparties you intend to pay, and that the x402 facilitator settles on the chain you picked.

Official sources

1. 0xgasless/agentkit on GitHub
2. Issues
3. Project website
4. README