Compute API integration for AI agents

Discover the product without credentials

These read-only endpoints returned public JSON during the September 11 review. None of the following requests creates a rental or sends a payment.

curl --fail --show-error https://api.proxies.sx/v1/peer/compute/catalog
curl --fail --show-error https://api.proxies.sx/v1/peer/compute/tiers
curl --fail --show-error https://api.proxies.sx/v1/peer/compute/marketplace
curl --fail --show-error https://api.proxies.sx/v1/peer/compute/stats

The responses contain models, tiers and machines arrays, with fleet state in the stats response. Treat an empty machine list as no visible rental supply. Do not substitute the tier list for inventory. Validate the response shape and handle network errors before an automated workflow makes a decision.

This site's compute index supplies page links, source endpoints and dated review context as JSON. The plain-text guide contains the same editorial material as these HTML pages. They are convenience formats; the live product API is the authority for stock and catalog changes.

Use the rental-specific endpoint

The customer documentation and its published client example use this base URL:

https://api.proxies.sx/v1/peer/compute/rentals/<rentalId>

The customer client example supplies a key with compute:read and compute:infer scopes in X-API-Key. Create it from the renter API page. Setting a generic SDK's bearer-token option alone should not be assumed sufficient. Use the rental ID, key and assigned model shown in your dashboard. The following is a documented request shape, not an authenticated test result:

# Set COMPUTE_RENTAL_ID and COMPUTE_API_KEY from your account.
# Replace the example model with the model assigned to your rental.
curl --fail-with-body --show-error --max-time 190 \
  "https://api.proxies.sx/v1/peer/compute/rentals/${COMPUTE_RENTAL_ID}/chat/completions" \
  -H "X-API-Key: ${COMPUTE_API_KEY}" \
  -H 'Content-Type: application/json' \
  --data '{"model":"qwen3.8-27b-4bit","messages":[{"role":"user","content":"Reply with hello."}],"max_tokens":32,"stream":false}'

Keep credentials on your application server or in its secret store. A public browser bundle or a pasted conversation is not an appropriate place for an account key. Consult the customer dashboard for key management.

Test the features your agent needs

Start with a short response, then test streaming and your real prompt lengths. The current customer documentation explicitly rejects tools, stop sequences and response_format with HTTP 400. An agent requiring those request fields needs a supported alternative or a different application design. Chat completions do not imply an embeddings endpoint. Documented request contract

Run the orchestration loop and external tools on your own system. The rented model endpoint returns model output. For document applications, the RAG hosting guide maps retrieval, source checks and generation to their respective components. A host's larger memory does not automatically make its model reliable at choosing tools or following a schema.

Bound retries and queue growth

The customer client identifies errors including node_offline, model_not_ready and timeout. Use a bounded retry policy with increasing delay, a request deadline and a queue limit. Show the failure to the calling application when those limits are reached. Record latency and the assigned model with each evaluation, while keeping confidential prompt content out of routine logs.

Enforce the published request limits

The September 11 customer client documents the following contract. These are published limits, not results from authenticated API tests.

A separate conservative input-byte budget limits the complete request against the model context. The maximum message count and per-message limit are not permission to send their product as one prompt. A byte is not a token; use the actual model tokenizer when budgeting text and handle the API's rejection explicitly. Customer request documentation

Bound concurrent work in your application. A rate limit describes admitted request frequency; it does not guarantee that sixty long requests can finish every minute. Use the benchmark method to establish useful throughput.

Keep purchase permissions separate from inference

An inference key needs compute:read and compute:infer according to the customer docs. Programmatic checkout and renewal additionally require compute:purchase and an Idempotency-Key header containing 8–128 letters, digits, dashes or underscores. Reuse the same operation key and request after a timeout or operation_pending; a new purchase intent gets a new operation key. Customer checkout documentation

Keep purchase credentials outside the model's prompt and grant spending permission in application code. A retry of a model request and a retry of a purchase have different consequences. The public JSON discovery calls above remain read-only. This review did not create a rental or exercise the documented purchase API.

Handle a changed quote differently from a pending purchase

The current public contract requires expectedPriceUsd and pricingVersion from the machine quote. Existing rentals expose their current renewalQuote through GET /v1/peer/compute/rentals/mine. Renewal is an explicit purchase for another 30 days. This website hands checkout to the customer portal. Purchase and renewal contract

Never replace the body of an unresolved intent with a newer quote. Resolve it first. Treat a confirmed rental operation as the purchase result; a CTA click or top-up redirect is not proof of a purchase.

Proxy payments are a separate integration

The existing x402 guide documents purchasing proxy resources. It does not establish an x402 compute checkout or compute tools in the proxy MCP server. Use the compute customer flow for rentals and review its current terms. The agent proxy guide remains relevant when an agent needs network access as well as model inference.