Payments & payouts

How providers accrue credits today, what the earnings endpoint shows, and where USDC-on-Base payout stands. Last reviewed: 23 September 2026.

Every billed request your Mac serves writes a row to the billing ledger. The provider share on every rate-card row is 90% (provider_share_bps: 9000). USDC-on-Base payout is not live in pre-beta. The payout pipeline is built but switched off; it is planned for public beta. Until then your balance stays on the ledger. The Malibu app shows it in USD terms, and no USDC is sent.

What you earn per request

For every billed request the network computes:

uncachedPromptTokens = promptTokens − cachedPromptTokens

grossCredits    = ( uncachedPromptTokens × promptRate
                  + cachedPromptTokens   × promptCacheHitRate
                  + completionTokens     × completionRate )
                  × globalMultiplierPpm
                  ÷ (1,000,000 × 1,000,000)

providerCredits = grossCredits × providerShareBps ÷ 10,000
operatorCredits = grossCredits − providerCredits

The rates are credits per million tokens, and they come from the model’s row on the public rate card, GET https://api.malibu.tech/v1/rate-card. A model without its own row uses the default row. globalMultiplierPpm is 1000000 (1.0×) on every row today. Units: the card’s usd_per_million_credits is 1.0, so 1,000,000 credits =

1.00 and 1 credit =

0.000001. A rate of 500000 credits per Mtok means $0.50 per million tokens. Per-model prices in USD: Economics → live rate card. Cached prompt tokens are billed at the lower prompt_cache_hit_rate_per_mtok only when a follow-up turn is routed back to the provider that already holds the conversation prefix in cache (see Sticky conversations). Every other prompt token is billed at the full prompt rate. Gross and provider credits both use banker’s rounding (round half to even), so rounding does not drift in one direction across many small requests.

Worked example

Take 1,000 prompt tokens and 500 completion tokens with no cache hit, on the default row (500,000 prompt / 1,000,000 completion credits per Mtok):

promptNumerator     = 1,000 × 500,000   =   500,000,000
completionNumerator =   500 × 1,000,000 =   500,000,000
grossCredits        = 1,000,000,000 × 1,000,000 ÷ 10¹² = 1,000 credits  ($0.001)
providerCredits     = 1,000 × 9,000 ÷ 10,000         =   900 credits  ($0.0009)

The same request on openai/gpt-oss-20b (50,000 / 100,000 credits per Mtok) is 100 gross credits, of which 90 go to the provider.

Only verified work is payable

Production runs verified-model settlement in enforce mode. A billed row counts toward your payable balance only when a valid signed receipt from your provider arrives inside the settlement window (pending_deadline_seconds, 300 seconds by default). If a receipt is missing, late, malformed, unverifiable, or tied to the wrong model identity, the row pays zero provider credit or is held for operator review. Held rows are released only if the review resolves them. Details: Verified model settlement.

When you get paid

Today (pre-beta): credits accrue on the ledger. No USDC leaves it.
Payout wallet: you can register or change your Base payout address in the Malibu app now. Registering a wallet does not start payouts.
Planned for public beta: USDC on Base, settled in weekly windows that start Monday 00:00 UTC. The minimum payout is 500,000 credits ($0.50), and a smaller balance rolls into the next window. These values come from the current configuration and may change before launch. See Metering & billing.

Checking your balance

The Malibu app’s earnings card shows today / this week / pending / lifetime, converted to USD at 1,000,000 credits = $1.00. “Pending” means payable credit that has accrued and not been paid out. Before payouts launch, that is all of your payable credit. The app reads its numbers from a provider-token-authenticated endpoint. It is not part of the public API at api.malibu.tech, so use the app to check earnings. For reference, the endpoint shape is:

GET /providers/{provider_id}/earnings
Authorization: Bearer <provider_token>

Main response fields:

{
  "provider_id":            "<string>",
  "total_credits":          <int64>,
  "current_window_credits": <int64>,
  "usdc_today":             <number>,
  "usdc_week":              <number>,
  "usdc_pending":           <number>,
  "usdc_lifetime":          <number>,
  "last_payout_ready":      { ... } | null,
  "provider_share_bps":     <int64>,
  "models_served":          ["<string>", ...],
  "rate_card_excerpt":      { ... },
  "fault_count":            <int64>,
  "settlement_receipts": {
    "verified_count":     <int64>,
    "zero_settled_count": <int64>,
    "failed_count":       <int64>,
    "pending_count":      <int64>,
    "recent_failures":    [ ... ]
  }
}

total_credits, current_window_credits (since Monday 00:00 UTC), and the usdc_* figures count payable credit only. fault_count counts ledger rows that carry a fault flag. A provider with no ledger rows yet gets 404. Rate limit: 60 requests per minute per provider by default. Optional day-range filter: ?from=YYYY-MM-DD&to=YYYY-MM-DD, up to 31 days. The filter narrows the total, week, and today figures. It does not change usdc_pending, which is always lifetime-owed.

Routing tiers

Newly admitted providers start at the provisional tier, which gets a reduced routing weight (0.3× by default) and sits in a capped provisional pool. A provider moves to trusted when the network’s trust evaluation finds two distinct qualifying criteria. The criteria include 72 hours of continuous uptime, app attestation, at least 100 verified receipts, and an operator promotion approved by two separate operator keys. An operator promotion counts as one criterion, so it still needs a second one and the provider holds a valid token and custody proof. It drops back to provisional if it stops meeting them. Pinned providers are listed in the coordinator’s own configuration. Trusted and pinned providers both route at full weight. Tier changes how much traffic you are offered, not the per-token rate.

Why your Mac might drop mid-window

Lid-close sleep drops the WebSocket. While it runs, the provider holds a macOS sleep assertion (caffeinate) that prevents idle sleep, but closing the lid can still put the Mac to sleep. The provider reconnects on wake. Requests in flight during the sleep are lost.
Heartbeat reaping. If no frame (heartbeat or inference output) arrives within 90 seconds, the network closes the connection. Streaming inference chunks count as activity.

Buyer-facing docs state this plainly: “provider availability can change as Macs sleep, wake, or disconnect from the network.” Availability is best-effort, and the mechanisms above are what that sentence describes.

Litepaper

Getting started

Buyers

Providers

Network & trust

Guides index

Ledger

Payments & payouts

Payments & payouts

What you earn per request

Worked example

Only verified work is payable

When you get paid

Checking your balance

Routing tiers

Why your Mac might drop mid-window

​Payments & payouts

​What you earn per request

​Worked example

​Only verified work is payable

​When you get paid

​Checking your balance

​Routing tiers

​Why your Mac might drop mid-window

Payments & payouts

What you earn per request

Worked example

Only verified work is payable

When you get paid

Checking your balance

Routing tiers

Why your Mac might drop mid-window