MPP Chat Completions

POST /v1/mpp/chat/completions is the accountless paid inference endpoint for Tempo MPP session payments.

This production endpoint is open to paid Tempo MPP agents. Existing Virtual Key endpoints remain bearer-auth only.

POST /v1/mpp/chat/completions

Send an unpaid request first. A valid unpaid request returns 402 Payment Required with a WWW-Authenticate: Payment challenge.

Native Tempo agents can use tempo request directly:

tempo request -X POST \
  --json '{
    "plan":"Starter",
    "model_optimization":false,
    "model":"Qwen/Qwen3-8B-AWQ",
    "messages":[{"role":"user","content":"what is the capital of america?"}],
    "max_tokens":32,
    "temperature":0
  }' \
  https://inference.andoai.xyz/v1/mpp/chat/completions

Retry with:

Authorization: Payment <base64url-credential>

Successful paid responses include:

Payment-Receipt: <redacted-receipt>

The receipt is success-only and appears only after paid usage is committed. For the first production rollout, the challenge amount is a 1 USDC.e cumulative voucher bucket and the challenge includes suggestedDeposit: 5000000 as a reusable-session hint. Native Tempo clients may open a smaller channel when their payer-side deposit policy caps the suggestion; Ando accepts the session when the SDK-verified channel deposit covers the active voucher authorization. Each HTTP turn still uses a request-bound MPP credential, but cumulative voucher authorization only needs to increase when the current bucket is exhausted or stale.

Custom clients should treat Tempo session vouchers as cumulative authorization, not per-turn charges. Reuse the current cumulative voucher until Ando returns mpp_voucher_bucket_refresh_required; do not add the challenge amount on every paid retry.

HEAD /v1/mpp/chat/completions

HEAD on this URL is a different HTTP operation from POST. It is reserved for later MPP challenge or state metadata, is disabled in the first rollout, and must not be used as a model execution path.

Request Body

{
  "plan": "Starter | Plus | Premium",
  "model_optimization": true,
  "model": "required only when model_optimization is false",
  "messages": "[OpenAI-compatible chat messages]",
  "max_tokens": 1024,
  "stream": false
}

stream must be false for the first rollout.

Payment Challenge

The challenge binds:

• HTTP method and path
• exact request-body digest
• selected plan
• resolved model/runtime
• pricing snapshot lineage
• input/output caps
• Tempo Mainnet session rail
• accepted token and escrow contract
• recipient configured by Ando
• expiry and opaque replay metadata

Clients must not reuse a payment credential across a modified request body.

Stable Error Codes

• payment_required
• mpp_session_deposit_below_request_cost
• mpp_malformed_credential
• mpp_method_unsupported
• mpp_invalid_challenge
• mpp_body_digest_mismatch
• mpp_request_quote_invalid
• mpp_request_exceeds_voucher_bucket
• mpp_payment_verification_failed
• mpp_payer_not_allowed
• mpp_voucher_bucket_refresh_required
• mpp_reservation_failed
• mpp_commit_failed
• mpp_session_close_unavailable
• mpp_session_close_failed
• mpp_streaming_unavailable

mpp_session_deposit_below_request_cost means the paid retry reached Ando, but the verified Tempo session deposit or available escrow is lower than the active voucher authorization. Open or top up the Tempo session so the channel deposit covers the current voucher bucket, then retry the exact same request body. If the Tempo client fails locally before sending the retry with Deposit too low for request, Ando cannot emit this API error because no paid retry reached the gateway.

mpp_voucher_bucket_refresh_required means the accepted cumulative voucher bucket is exhausted, expired, or not yet authorized. Sign a fresh or higher cumulative Tempo session voucher and retry the exact same request body.

Privacy

Do not include raw payment credentials, signatures, wallet addresses, idempotency keys, receipts, or prompt content in logs, traces, analytics, or support messages.