Billing

Computalot uses account credits. When you submit a job, a bounded hold is placed against your balance for the initial attempt and the requested max_retries budget. After the job reaches a terminal state, the hold settles to actual ledger usage. Infrastructure requeues do not consume the configured retry budget. API keys and wallet sessions see the same billing truth. For rates and worked cost examples, see Pricing.

How it works

1. Submit a job — Computalot estimates the cost and places a hold
2. Job runs — your balance stays reserved
3. Job completes — the hold settles to the actual cost

If your account can’t cover the estimated hold, the job is rejected before it starts.

Billing truth lives on GET /api/v1/account/balance, GET /api/v1/account/holds, GET /api/v1/account/ledger, and GET /api/v1/account/quotes.

Checking your balance

curl -sS -H "Authorization: Bearer $TOKEN" \
  https://computalot.com/api/v1/account/balance

Returns:

Use GET /api/v1/account/holds to inspect active reservations, GET /api/v1/account/ledger for settled credits/debits, and GET /api/v1/account/quotes for open funding or shortfall quotes.

Funding with x402 or MPP

The programmatic funding rail speaks two HTTP-402 payment protocols over the same quotes: x402  and MPP  (Machine Payments Protocol). Both settle the same EIP-3009 USDC authorization — use whichever your wallet tooling supports. No subscription or credit card needed.

# 1. Request a top-up quote
curl -sS "$BASE_URL/api/v1/account/quotes/topup" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"amount_usd": 5.0}'
 
# 2. Response: 402 Payment Required, advertising both protocols:
#    - x402: PAYMENT-REQUIRED header + payment_required in the body
#    - MPP:  WWW-Authenticate: Payment header + decoded challenge in the body's mpp block

Pay over x402 — sign payment_required.accepts[0], then confirm with the base64 payment payload in PAYMENT-SIGNATURE (bearer auth required):

curl -sS "$BASE_URL/api/v1/account/quotes/<quote_id>/pay/x402" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "PAYMENT-SIGNATURE: <x402 payment payload>"

Pay over MPP — sign the same EIP-3009 authorization for the decoded challenge request, wrap it as an MPP credential ({challenge, payload: {type: "authorization", ...}, source}), and resubmit with the Payment authorization scheme — no bearer token needed:

curl -sS "$BASE_URL/api/v1/account/quotes/<quote_id>/pay/x402" \
  -X POST \
  -H "Authorization: Payment <base64url MPP credential>"
# success returns a base64url JSON Payment-Receipt response header

Settlements are replay-safe on both carriers: repeating a settled payment returns 200 with replay: true instead of double-crediting.

One rule for every 402 Payment Required: the response attaches a ready-to-pay shortfall quote — fund the account (pay that quote or top up), then retry the same request unchanged. This applies to both POST /api/v1/jobs and POST /api/v1/projects/:name/init; don’t modify the payload first; the original request was fine.

What’s charged

• Job execution — charged against credits, based on resource usage and runtime
• Project init — free, but requires at least $5 available balance
• Artifact storage — no usage charge in v1; retained local/R2 bytes count against the default 100 GiB account quota until deletion

Artifact lifetime is not a fixed seven-day window. Active producing-job and job-input references block deletion; once every reference is terminal, owner deletion releases quota immediately and namespaced backing data is collected after the default 24-hour grace.

Endpoints