EDITORIAL ARTICLE
Tempo Wallet CLI: Letting Command-Line Agents Pay for APIs
Product analysis · Sources reviewed October 28, 2026 · Based on public information; no code was run and no payment was made.
A research agent needs a paid data API. Traditionally, a developer might register and manage keys for each provider. Tempo Wallet CLI lets an agent make command-line requests and handle machine payment requirements. It is a client tool; Tempo is a network and MPP is a payment-interaction protocol. They are different things.
Background and users
Tempo builds tools around a stablecoin payment network and machine payments. Its open-source wallet-cli repository targets developers and agents that can call a shell, combining wallet operations and paid HTTP requests. The historical wallet-rs repository is archived and points to the newer repository; check the current repository for versions and deployment status.
| Role | Task | CLI’s place |
|---|---|---|
| Developer or user | Sign in, fund and authorize | Configure and supervise the wallet |
| Agent | Access a paid API | Invoke commands and process results |
| Provider | Offer resources and payment terms | Decide pricing and delivery |
| Tempo network | Execute supported on-chain operations | Transaction environment, not the CLI itself |
An illustrative request
This conceptual flow follows public documentation; settlement order is not guaranteed to be identical for every MPP method. The repository describes device-code login approved in a wallet app and a dry run to preview fees, but probing non-GET requests may still have server-side effects. Where a service offers sessions the CLI defaults toward a session; a one-time charge can be selected explicitly. A session locks a deposit until it is closed and unused funds are withdrawn. See the current implementation.
Permissions and risk
| Topic | Public description and evaluation question |
|---|---|
| Key | The agent environment holds a restricted access key; a thief may act within its scope, so protect hosts and logs |
| Limits | The repository describes a default cap of 10 payment-token units for charge and session and a configurable max-spend; the default does not constrain recurring subscriptions. Verify accumulation and renewal |
| Recovery | A timeout does not prove no payment occurred; inspect credentials, transactions and response before retrying |
| Coverage | The provider must support the relevant MPP method; the CLI does not enable payment at every ordinary website |
Costs and business model
The repository presents open-source software; we found no standalone CLI price. Users may incur service-provider charges, on-chain fees and funding or conversion costs through other services. Do not call these CLI fees. Inference: easier integration may increase Tempo network and ecosystem use, but standalone CLI revenue was not disclosed.
Fit
Developers who want agents to call MPP-compatible APIs and can manage command-line and on-chain funding may evaluate it. Card payments, expense reimbursement, organization-wide approvals and merchants without MPP require other services. Check geography, networks and assets, enforcement of spending caps, key revocation, failures and duplicate requests. We did not run the code and cannot confirm availability in a particular environment.
An evaluation walkthrough
Consider a hypothetical research agent calling an MPP-enabled weather API; we did not pay this service.
- Environment: Check current network requirements, software version and supply-chain verification; choose the agent host and the owner’s authorization device.
- Login and identity: The quickstart uses
tempo wallet loginfor device-code approval andtempo wallet whoamito inspect wallet and access key. The user should read the requested permissions. - Funds:
tempo wallet fundopens a funding flow and provides a link, but the repository says it does not wait for or confirm receipt. Checktempo wallet balanceafterward. - Service and fees:
tempo request --dry-run <service URL>previews requirements, but non-GET probes can have server-side effects. Check terms, currency, network and request method. - Limits: Explicitly review
--max-spendand key permissions. For a one-time payment consider--payment-intent charge. The default cap does not cover recurring subscriptions. - Execute and reconcile: Check the result, transaction and receipt. An unknown outcome is not necessarily failure; check status before paying again. The repository suggests querying status and supports
--write-metato preserve metadata.
A machine-callable flow avoids designing a separate payment interaction for every compatible MPP service. It still depends on an available wallet, user authorization and funding, and compatible providers; ordinary unsupported checkout pages remain outside the CLI’s reach.
Charge versus session economics
If data costs 0.01 payment-token units per query, 100 queries cost one unit in service charges alone, ignoring network and additional service fees. This is illustrative, not a quote. A charge associates a payment with a request; a session can lock a deposit and settle based on use and agreement.
| Check | One-time charge | Session |
|---|---|---|
| Before | Per-service requirements and cap | Deposit, expiry and available balance |
| During | Whether each request creates a transaction and fee | Usage proofs, balance and interruption handling |
| After | Reconcile each payment | Close session and reclaim unused deposit |
| Unknown outcome | Check status before retrying | Reconcile session and provider records |
Request caps, access-key limits, wallet balance and session deposits are different measures. A limit of ten units does not by itself prove 100 requests cannot cumulatively exceed ten. Check each layer in current documentation. Recurring subscriptions are specifically outside the documented default cap; select an appropriate intent when the task does not need a subscription.
Comparing alternatives
Tempo CLI is closer to an agent’s local invocation interface; AWS AgentCore Payments emphasizes managed orchestration, wallet connections and cloud observability. ZeroDev focuses more on smart-account permission components, while the CLI includes commands and MPP request tooling. They may be combined in different architectures rather than ranked as equivalent wallets.
Test three counterexamples: if the agent host is stolen, how much can the restricted key spend? If a service times out after payment, where is the evidence? Who closes the session after the task? If the team cannot answer, investigate in a test environment and applicable terms before increasing limits.
Sources: current CLI repository, historical implementation and migration, and MPP documentation.