Franklin Agent: a USDC wallet wired into an agent loop, and what that changes about cost control

The problem Franklin targets: agents that can reason but cannot buy anything

Most agent frameworks stop at tool calling. The model can decide it needs a price feed, but the developer has to pre-provision that feed, hold the API key, and absorb the cost whether or not the agent ever uses it. Franklin inverts that. The README describes it as an autonomous economic agent that holds a USDC wallet and spends it to get work done, with trading named as the flagship arena. The intended user is someone who wants an agent to buy live market data, call a paid model, or run a long task without a human topping up a provider account first. The pricing model is stated as provider cost plus 5%, settled per action in USDC, with no monthly fee and no rate limit. That last clause matters more than it looks. Rate limits are the usual reason agent workloads get shaped around a provider's quota rather than around the task, and Franklin's claim is that the wallet balance becomes the only ceiling.

Two funding paths and the trade-off between them

Franklin accepts either a funded USDC wallet or a prepaid balance. The wallet route is `franklin setup solana` or `franklin setup base`, followed by `franklin balance` to show the address and current USDC. The README states there is no signup, no account, and that the wallet is the identity. The alternative is `franklin login brk_live_...` with a key obtained after topping up at user.blockrun.ai. Both routes unlock the same catalogue, and the README puts the entry point at $5. The distinction is operational rather than functional. A wallet key is a spending key. If it leaks, the loss is bounded by the balance, but the balance is directly spendable by whoever holds it. The API key route adds an account layer and a revocation path that the wallet route does not describe. The README does not document key rotation, spending caps per session, or a kill switch, so anyone choosing the wallet route should treat the balance itself as the blast radius and keep it small.

What actually runs when you type franklin

Installation is `npm install -g @blockrun/franklin`, or `npx @blockrun/franklin` if you would rather not install globally. Running the bare `franklin` command works without funding, using NVIDIA Nemotron and Qwen3 Coder as the free defaults. The architecture described in the README is a router sitting in front of a gateway. Paid actions route through the x402 micropayment protocol and settle on-chain, and the agent selects a model per task from what the README calls 55+ providers. Around that sit three behaviours that distinguish it from a chat wrapper: trade plans are proposed and require approval before any money moves, goals persist across sessions, and the agent keeps a trading journal bound to the wallet. The approval step is the most consequential design choice in the whole project. An agent that can spend autonomously but must surface trade plans first is a deliberate half-step, and it suggests the authors do not consider unattended trading safe enough to enable by default.

The Node version constraint is a real first-run failure, not a footnote

Franklin requires Node.js 20.19 or newer, with Node 22 LTS recommended. The README is unusually direct about why: the Solana dependencies need the require(esm) support added in 20.19.0, and older runtimes crash at startup with ERR_REQUIRE_ESM originating in rpc-websockets and uuid. The troubleshooting table names this as the number one cause of a crash on first run. The second documented failure is an EACCES error when creating /usr/local/lib/node_modules, common when Node was installed from the macOS .pkg and the global folder is owned by root. The README's advice is not to use sudo but to either run via npx or move to a user-owned Node through nvm or fnm. Both fixes are correct and both are ordinary Node hygiene problems rather than Franklin defects, but they will consume the first ten minutes of an evaluation if the environment is not already clean.

Where Franklin is the wrong tool

The README does not describe a stable public API, a versioned SDK contract, or a compatibility policy for the agent loop itself. Desktop releases are labelled beta, with three beta builds pushed within three days in early September 2026, which is a normal cadence for something still settling. If you need to embed agent behaviour in a production service with predictable interfaces, the CLI and extension are the documented surfaces and neither is presented as a library. The second limitation is accounting. Per-action USDC settlement produces a stream of small on-chain transactions rather than a monthly invoice. For a solo operator that is fine. For a team that needs a single line item per vendor, it is a reconciliation problem the README does not address. The third is model quality variance. Routing across 55+ providers means behaviour changes with the chosen model, and the README does not describe how the router scores or selects, so results are not reproducible across runs unless the selection is pinned somewhere the documentation does not cover.

How this differs from a subscription coding agent

The obvious comparison is a subscription agent such as Claude Code or Cursor, where a flat monthly fee covers model access and the marginal cost of a long session is zero. Franklin's approach is the opposite: the marginal cost is visible on every call, and the README frames this as YOPO, you only pay outcome, at provider cost plus 5%. The practical difference shows up in how you use it. A flat subscription encourages long exploratory sessions because the next token is free. A per-action wallet discourages them, because every data fetch and every model call has a price attached. That is a genuine behavioural difference, not a marketing one, and it cuts both ways: you get cost discipline, and you get an agent you are less inclined to leave running. Franklin also bundles paid third-party APIs into the same wallet, which a coding subscription does not, so the comparison is only clean for the model-calling portion of the work.

Maintenance cost and the Apache-2.0 terms

Franklin ships as a single npm package under Apache-2.0, which permits commercial use, modification, and redistribution provided you retain the licence and notice files and state significant changes. It also includes an express patent grant, which matters if you intend to build on the router. The licence covers the code, not the services. Model calls, paid APIs, and the 5% markup are commercial terms set by BlockRun and are not governed by the repository licence, so the two need to be evaluated separately. On maintenance, the README documents a shared ~/.blockrun/ directory holding config and session history across the CLI, the VS Code extension, and Desktop. That sharing is convenient and it also means a schema change in that directory affects all three clients at once. The Desktop line is on 0.2.0-beta.3, so expect churn there rather than in the CLI. Nothing in the material describes a migration path for the config directory between versions.

Editorial conclusion

Adopt Franklin if you want an agent whose spending is bounded by a wallet you control and you are comfortable approving trade plans before funds move. Do not adopt it if you need a stable, versioned API surface or if your finance team cannot account for per-action USDC settlements. Verify three things first: that your Node build is 20.19 or newer, that `franklin setup solana` or `franklin setup base` produces an address you recognise, and that the 5% markup on provider cost is acceptable against whatever you pay today.

Official sources

1. BlockRunAI/Franklin on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases