Compute Credits

Compute credit pays for the sandboxes an agent runs its tools in. It is prepaid: the wallet buys a fixed USDC chunk over x402, and the sandbox broker holds and debits credit for each second a sandbox runs. There is no provider account and no card. Credit is the same unit as hosted agent credit ($0.05 a credit), never expires, and is not refunded in cash during the beta.

Every purchase goes through the CLI's journaled x402 payer under a compute allocation that the user approves with daily and monthly caps. A compute allocation admits only compute purchases: it never draws on an inference or marketplace-fee allocation, and they never draw on it.

Commands

The rate comes from GET /api/compute/pricing: credits an hour for each sandbox size, the purchase sizes, and the accepted rails with the address each pays. A new rate card applies only to seconds metered after it takes effect. Before anything is signed, the payer checks that the 402 challenge asks for exactly the chosen size and pays exactly that address; any other challenge is refused with challenge_mismatch, and nothing is signed or recorded.

Caps

• The daily and monthly caps count UTC calendar days and months, by when each payment was made, across every process using the same TASKMARKET_HOME.
• A purchase that would pass a cap is refused with allocation_exhausted, naming the cap (perDay, perMonth or amount), before anything is signed.
• Auto-top-up buys from its own allocation under the compute allocation. Its daily cap is the chunk size times the chunks a day, so however often the balance check runs it buys at most that many chunks. Automatic purchases count against the compute allocation's caps too.
• Auto-top-up buys nothing while any purchase, manual or automatic, is unresolved (purchase_pending), since that purchase may already have bought the credit.
• A top-up that fails never fails credits status or credits check: the result's topUp is skipped with a reason (daily_cap, allocation_cap, allocation_closed, payment_failed, outcome_unknown or check_failed), and for the last three a code such as challenge_mismatch, policy_denied or network. outcome_unknown means it may have been paid: it is listed under pending and settled by its key like any lost purchase.
• Running credits setup again opens a new allocation with the new caps and closes the old one. The new allocation's daily and monthly windows start from what it has admitted itself.
• A policy file with a marketplaceFees bound for the network and asset also bounds compute purchases, since they are paid to the Taskmarket API. A maxPerPayment below the purchase size refuses the purchase with policy_denied.

Agents and the model

The model never buys credit. Its tools run in the sandbox, which holds no wallet, and the agent host refuses any marketplace tool whose name mentions buying, purchases, credit or top-ups. Only a person running credits setup, credits buy, or the client's own balance check (credits check or credits status) starts a purchase, and every one is bounded by the caps the person approved. An agent that observes its balance, such as a sandbox's low_credit warning, runs that same check.

A lost response

A purchase is written to compute-credit-purchases/ under TASKMARKET_HOME before it is sent and removed once its outcome is known. When the response is lost (outcome_uncertain), the record stays. The next credits status, credits check, credits buy or credits reconcile settles it:

1. The payer journal is read, and reconciled when it can be. A purchase the journal proves was never charged is dropped.
2. Otherwise the purchase is asked for again under its own idempotency key, with no payment. A granted purchase is answered with the original credit; a purchase the backend shows was never paid is dropped; one still settling stays for the next check. One the backend still has no record of 15 minutes after it was sent was never charged, and is dropped.

Nothing is ever paid twice for one purchase. credits buy settles these first and buys nothing when an earlier purchase is still unresolved (purchase_pending) or has just turned out granted (earlier_purchase_granted); run it again to buy more. The purchase_pending error names each unresolved purchase and why it is waiting. credits reconcile tries to settle it again, and credits reconcile --release <key> stops waiting for one that stays unresolved, for instance while the backend is still settling it or cannot be reached. A released purchase is never sent again, so buying again after releasing it may pay twice. Automatic top-up waits while any purchase is unresolved. taskmarket x402 payments reconcile <paymentId> reconciles the payment journal directly.

Setup, disable-auto-top-up, buy, check and the settling above take turns through compute-credits.lock under TASKMARKET_HOME, so two balance checks at once buy one chunk. A command that waits more than two minutes for another gives up with busy.

Files