​
Overview

How the Malibu network is put together.

Receipts

Ed25519-signed inference receipts.

Security model

Trust boundaries and threat surface.

Billing

Credits, rate card, settlement.
Malibu has three moving parts:
  • Providers are Apple Silicon Macs running MLX.
  • The coordinator handles provider admission, routing, the credit ledger and settlement.
  • The gateway at api.malibu.tech is the OpenAI-compatible API buyers call.
It is a coordinated inference network. Buyers never connect to provider Macs directly.

​
Data path

  1. The buyer sends POST /v1/chat/completions to https://api.malibu.tech/v1 with an OpenAI-shaped request.
  2. The gateway authenticates the API key, reserves tokens against the account’s daily quota, and forwards the request to the coordinator.
  3. The coordinator picks a provider that has a free serving seat for that model. If the request carries a sticky conversation tag (X-MacProvider-Conversation), the provider that served the earlier turn is preferred, but the preference only wins when that provider is also the top-ranked choice (see Discovery & routing).
  4. The coordinator sends the request down that provider’s outbound WebSocket.
  5. The provider Mac runs MLX inference, streams tokens back, and finishes with a signed receipt.
  6. The coordinator writes the ledger row, settles against the receipt, and returns the OpenAI-shaped response to the gateway.
  7. The gateway returns the response to the buyer. It adds X-Provider-Id (the serving provider) and, when one is available, a buyer-visible receipt header (see Receipts).

​
Components

​
Trust posture

  • Provider Macs hold their own model weights and receipt signing keys. They never open an inbound port.
  • The coordinator sees prompts and responses in plaintext, because it routes and meters them. It does not hold model weights.
  • The gateway sees the same, plus buyer identity.
  • Provider Macs process prompts in plaintext too. Encryption that hides requests from the relay exists only as a default-off pilot.
  • Buyers can read the live trust posture from the tier1_disclosure object in GET /v1/models. See Trust disclosure.
Full trust boundary: Security & trust model.

​
Provider onboarding

A new public install joins as a provisional provider. Provisional providers get a lower routing weight and an hourly request quota. A provider moves to trusted when the network’s trust evaluation finds a qualifying pair of criteria (for example verified work plus 72 hours of continuous uptime, or an operator promotion approved by two separate operator keys) and the provider holds a valid token and custody proof. No inbound port-forwarding is needed on the provider Mac. See Reputation for how tiers affect routing.