Provider Guide

This guide describes AGIHALO's current provider integration. It is operational documentation, not a replacement for the Provider Agreement. Complete individual KYC, save a provider profile and Base receive wallet, and confirm that your upstream agreement permits the intended use before publishing a provider.

1. Provider types

• Hosted credential: configuration may appear during the rollout, but hosted seller credentials are not currently connected to buyer routing or seller earnings. Do not register one expecting traffic or revenue until AGIHALO explicitly marks hosted seller routing available.
• Custom endpoint: expose the OpenAI-compatible discovery and chat endpoints below using your own inference infrastructure.

2. Custom endpoint contract

• The base URL must use public HTTPS and contain no credential, path, query string, or fragment. It must resolve to a public address.
• The chat path must be a relative path beginning with /, ending in /chat/completions, and containing no query string or fragment. AGIHALO derives the matching /models path from this value.
• Choose either Authorization: Bearer <key> orX-API-Key: <key>. The same authentication is sent to model discovery and chat requests.
• Return JSON with an appropriate application/json content type and no compression. Only 307 or 308redirects are followed, for at most two hops, and every hop must remain on the same origin. 301, 302, and303 are rejected because they may change the request method.

GET the derived models path. Return a dataarray whose id values exactly match the canonical Halo model identifiers you serve.

{
  "data": [
    { "id": "qwen/qwen3.6-35b-a3b" }
  ]
}

POST the configured chat path. Registration probes use a small non-streaming text request similar to this one:

{
  "model": "qwen/qwen3.6-35b-a3b",
  "messages": [
    { "role": "user", "content": "Reply with the single word OK." }
  ],
  "max_tokens": 16,
  "stream": false
}

A valid response must:

• return the exact requested canonical model identifier;
• contain exactly one choice and non-empty assistant text;
• use stop, length, orcontent_filter as finish_reason; and
• not contain tool calls or function calls.

{
  "model": "qwen/qwen3.6-35b-a3b",
  "choices": [
    {
      "message": { "role": "assistant", "content": "OK" },
      "finish_reason": "stop"
    }
  ]
}

Custom routing is text-only. Streaming, tool/function declarations and tool/function responses are not currently supported. A matching response model string checks the explicit contract but does not independently attest the underlying model weights.

Runtime request and network limits

• Requests contain an exact canonical model and a non-empty text-only messages array. n andbest_of, when supplied, must be 1. Tools, functions, tool-role messages, audio, images, and multimodal content are rejected before your endpoint is called.
• Clients may provide either max_tokens ormax_completion_tokens, but not both. AGIHALO forwards the result as max_tokens, defaults it to 4096, and caps it at 32768. AGIHALO forces n: 1 andstream: false. Other accepted OpenAI-compatible fields are forwarded in the canonical JSON request.
• Runtime request and response JSON are each limited to 1 MiB, valid UTF-8, at most 64 levels of JSON nesting, and absent or identitycontent encoding. Request-body idle and total limits are 15 and 30 seconds. Response-body idle and total limits are 15 and 120 seconds.
• AGIHALO permits at most eight concurrent custom-provider upstream requests per seller across all of that seller's provider records. Capacity rejection does not create completed seller earnings.

3. Model checks, logprobs, and upstream cost

Check models first calls the derived models endpoint and then sends one bounded baseline chat request to each advertised canonical model. After a valid baseline response, AGIHALO may send a second request with logprobs: true and top_logprobs: 5. The UI shows baseline latency and the observed logprob capability.

• Saving rechecks each selected model, and continuing health checks may send additional bounded baseline requests while the listing is enabled. The health scheduler runs every 10 minutes in bounded batches, so exact wall-clock timing is not guaranteed. All such requests can create upstream charges for you.
• Missing, unsupported, invalid, or unavailable logprobs are informational only. They do not block activation, count as a health failure, or change customer charges or provider settlement.
• AGIHALO stores the returned/not-returned status, bounded counts, latency, and an internal response fingerprint. It does not store the raw logprob token arrays. A fingerprint is an observation, not model attestation.
• A recorded failed Test or background health check increments the provider failure score. The second unresolved failure places the key on watch; the fifth disables it from routing. A later successful check resets the score and can restore an enabled listing. AGIHALO capacity or database errors that make a check inconclusive are skipped and do not count against the provider.

4. Pricing and metering

Registration and editing show the customer rate, the current Halo fee, and estimated provider earnings before you save. Any provider discount is applied to the customer price first; the displayed provider-specific fee split is then applied. The usual split is a 10% Halo fee and 90% provider earnings, but the rate shown for your provider is the rate that applies. You remain responsible for upstream charges, taxes, and other costs.

Custom endpoint text usage is billed with deterministic Halo text units calculated from the canonical request and visible assistant text. Halo does not use seller-reported usage, hidden reasoning, cache claims, or the model's native tokenizer to determine the customer charge. Failed or contract-invalid custom responses do not create completed seller earnings.

5. Payouts

• Payouts are manually reviewed and sent as USDC on Base to the saved receive wallet. Transfer timing is not guaranteed.
• A request allocates all currently available cash-funded earnings. Only one payout request may be active at a time. If a completed charge includes any bonus-funded amount, its seller earnings are currently payout-ineligible and there is no review-to-release path for them.
• KYC is rechecked before processing. You may cancel a pending request, and an unprocessed request expires after seven days. Once processing begins, it can no longer be cancelled or expire.

Review the current amount, wallet snapshot, and status in the Provider Settlement panel. For data handling details, see the Privacy Policy.