Provider attribution

See which provider served a request. Buyers cannot pin requests to a provider.

Buyers cannot pin requests to a provider. Earlier versions of this page described an X-Malibu-Pin-Provider header. That header never existed. No request header selects a provider, so buyers cannot steer requests to a specific Mac. The coordinator picks the provider.

Which provider served this request?

Each response that reached a provider carries X-Provider-Id, an opaque ID for the Mac that served it. Use it for logging and debugging, or to group latency and quality observations by provider.

from openai import OpenAI

client = OpenAI(base_url="https://api.malibu.tech/v1", api_key="<your-malibu-api-key>")

raw = client.chat.completions.with_raw_response.create(
    model="mlx-community/Llama-3.2-3B-Instruct-4bit",
    messages=[{"role": "user", "content": "Hello"}],
)
served_by = raw.headers.get("X-Provider-Id")   # e.g. "mp-26592d71…"
request_id = raw.headers.get("X-Request-ID")

X-Provider-Id is informational. Sending it back as a request header has no effect.

Getting the same provider across turns

The supported way to keep a conversation on one provider is a sticky conversation tag (X-MacProvider-Conversation). It is a preference, not a pin. If the preferred provider is busy or offline, the request routes elsewhere instead of failing.

Reproducing or reporting a problem

Record X-Request-ID and X-Provider-Id for the failing request.
For non-streaming responses, keep the X-MacProvider-Receipt header. It is signed by the serving provider’s key and binds the prompt and output hashes. See Signed receipts.
Use GET /v1/receipts/{request_id} to see the settlement outcome for that request.

Private pools

Default-off. Operator-provisioned private pools are built but not enabled on the public network. When enabled, they restrict routing to an approved set of providers; they are not self-serve for buyers. Requests that name a pool you are not authorized for return a generic 503 pool_unavailable.