A market for inference.

What is live

Provider discovery, encrypted connections, private and sponsored inference, paid listing registration, API-key management, passive health tracking, token limits and durable usage receipts are implemented. No example provider offers are seeded. A catalogue model is not an available Clear offer until someone verifies and activates a listing.

Onchain payments, seller earnings, streaming, image/audio generation and autonomous x402 payments are not enabled. Paid listings cannot serve other buyers yet. The site’s current owner-only access also restricts external API clients, even if they have a Clear API key.

1. Connect a provider

In My providers, select OpenRouter, Venice or Groq and enter a dedicated key. Clear discovers models at that provider’s model endpoint and stores the key with AES-256-GCM encryption. Model discovery alone does not prove that a key has permission or funded access to a particular model.

Every connection has a shared daily token cap across all its model listings. Keep independent provider-side limits as well. Only submit keys you control and use them within the provider’s terms.

2. Verify and list capacity

Choose a discovered model in My listings. Verification sends one short completion with a 16-token output limit; your provider may bill this call. A successful completion with usage metadata activates the listing. Clear prevents duplicate model listings for the same key and provider.

Private: only your account can route through the offer. Your provider directly bills you. Sponsored: you explicitly fund requests from other signed-in users, up to your token cap. Paid: register your asking prices now; paid execution is blocked until settlement is deployed. You can still use your own connection.

Verification tests operation and reported token usage. It does not attest model weights, privacy, or output quality. Clear only calls fixed provider endpoints and refuses redirects. No arbitrary host forwarding is available.

Routing and limits

By default, your own eligible connections are prioritized, then sponsored listings, sorted by estimated total cost for the input and requested output. Set routing to latency to prefer the lowest recorded full-response time. offer_id can pin a specific eligible listing. Requests never use another seller’s paid listing while settlement is disabled.

The router reserves a conservative token allowance atomically before calling a provider. On success it replaces that reservation with the reported usage. Failed or ambiguous calls retain the reservation because upstream quota may have been consumed. Day boundaries use UTC. Up to three eligible offers are attempted; failing offers enter exponential cooldown. Once a cooldown expires, traffic can retry them. Failed writes after successful inference do not trigger a second provider request.

The API limits request bodies to 64 KiB, messages to 40, each message to 12,000 characters, and provider responses to 2 MiB. Management and inference share an account request limit. Inference is non-streaming.

Receipts and privacy

Response headers identify the receipt, selected provider, offer, attempt count and payment mode. Clear stores model IDs, provider IDs, token counts, latency, error category and timestamps. It does not persist prompt or generated text. The selected upstream provider receives the prompt and applies its own retention policy.

USD amounts are estimates based on listing prices, not charges, earnings or settled transactions. Deleting a connection deletes its encrypted key and offers; usage receipts remain. API keys can be revoked immediately from the console.

Endpoint map

GET /api/marketplace — active public listings
GET /v1/providers — supported endpoints
GET /v1/models — eligible model IDs (authenticated)
POST /v1/chat/completions — non-streaming inference
GET /api/usage — your receipts and daily token counters
GET /api/seller/usage — receipts for your supplied capacity

Account management endpoints use the signed-in site session and enforce ownership and same-origin requests. Bearer inference keys cannot access them.

Robinhood Chain settlement

Target network: Robinhood Chain, chain ID 4663. Canonical USDG: 0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168. No settlement contract is deployed or configured in Clear yet. Deposits and paid execution remain unavailable. The next integration requires a tested escrow contract, verified token configuration, transaction reconciliation and an authorized settlement operator.

Reference: Robinhood network configuration · Token contracts

Design references

Clear’s implementation uses a seller-capacity marketplace pattern informed by Surplus’s public documentation. It is independently implemented and is not affiliated with Surplus, Venice, OpenRouter, Groq or Robinhood.