How Aile works: from AI request to lender payout

Aile is a marketplace for AI inference. Lenders list capacity and set their prices. Buyers access that capacity through compatible APIs, paying for usage in USDC on Solana rather than an Aile subscription.

Here is what happens between sending a request and paying the lender who serves it.

Three ways to supply capacity

Self-hosted. The lender runs a model on their own hardware through a compatible endpoint, such as Ollama or vLLM. Model weights stay on that machine. The lender can read the prompts because their machine performs the inference.

Provider-backed. The lender connects a supported provider credential, which Aile stores encrypted at rest and uses when serving requests. On node-relayed routes, the lender’s node forwards encrypted traffic without reading the prompt or credential. Aile’s relay can read the request and response.

Nodeless. For supported API-key accounts, Aile connects directly to the provider without a lender node. Nothing needs to run on the lender’s computer, but serving must be disabled explicitly rather than stopped by switching off that machine. Consumer subscriptions are not eligible.

Connecting an account establishes technical access—not permission to resell it. Lenders must be authorized to supply the capacity they list.

From request to response

Buyers use /v1/chat/completions with an OpenAI-compatible client or /v1/messages with an Anthropic-compatible client. The endpoint determines the message format; the model identifier determines the requested route.

A provider-prefixed model pins that provider. If eligible capacity is unavailable, Aile returns an error instead of silently switching providers.

The router filters listings against the request’s model, price ceiling, and other restrictions. Among eligible lenders, price comes first; health signals help choose between equally priced options. Once a response starts streaming, it stays with the selected lender.

Buyers can limit output with max_tokens, cap acceptable token prices, and attach cumulative spending limits to individual API keys.

How payment works

Funded balance works with conventional API clients. Aile reserves an estimated charge before execution, commits the actual usage afterward, and releases the unused amount. Lender earnings settle in batches.

The standard platform share is 10% for node-based balance requests and 15% for nodeless balance requests. It comes from the lender’s share, not an additional charge above the buyer’s quoted price.

x402 lets a wallet-enabled client sign a payment authorization for a request. Eligible self-hosted and nodeless routes support account-free access where enabled. Settlement follows the response, with no Aile platform cut.

Each signed payment is tied to one operator and price. A failed request cannot silently move that authorization to another lender. The current x402 inference path is buffered rather than streamed.

What lenders control

Lenders choose what to offer, set input and output token rates, and disable capacity when needed.

Revenue is not automatically profit. API-backed suppliers still pay upstream usage charges; self-hosted operators carry their infrastructure costs. Rates need to account for those costs and applicable platform fees.

What Aile can—and cannot—verify

Response headers identify the selected lender, provider, and capacity type. x-aile-blind describes whether the lender’s node could read the request; it does not mean Aile’s relay was unable to read it.

Aile can check whether a credential recently worked and, for supported providers, verify an account link. Self-hosted probes provide limited evidence about served behavior.

None of these guarantees the identity or quality of the model behind every answer. Broader evaluations and reputation remain unfinished.

Start with a small request, explicit spending limits, and non-sensitive input. Check both the answer and its recorded cost before expanding the workload.