agentwallets.si
← Back to Blog

EDITORIAL ARTICLE

Tempo Wallet CLI: Letting Command-Line Agents Pay for APIs

Article concepts · illustration
01Command-line tools02MPP interaction03API payments

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

sequenceDiagram participant U as User participant C as CLI / Agent participant S as Data provider participant N as Payment network U->>C: Log in and authorize restricted access key C->>S: Request paid data S-->>C: Return MPP payment requirements C->>C: Check requirements and configured permissions C->>N: Sign or submit payment C->>S: Retry with payment credential S-->>C: Return data if conditions are met

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.

  1. Environment: Check current network requirements, software version and supply-chain verification; choose the agent host and the owner’s authorization device.
  2. Login and identity: The quickstart uses tempo wallet login for device-code approval and tempo wallet whoami to inspect wallet and access key. The user should read the requested permissions.
  3. Funds: tempo wallet fund opens a funding flow and provides a link, but the repository says it does not wait for or confirm receipt. Check tempo wallet balance afterward.
  4. 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.
  5. Limits: Explicitly review --max-spend and key permissions. For a one-time payment consider --payment-intent charge. The default cap does not cover recurring subscriptions.
  6. 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-meta to 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.