Platform

An OpenAI-compatible API on iron we own.

Zarx is the inference gateway NPAW runs in production, opened to design partners. Same endpoints, same SDKs, same streaming events. The difference is where the request is processed and who operates the servers.

Access is by invitation during early access. The base URL in the samples, https://api.zarx.ai/v1, is the design target; partners receive their endpoint and keys when onboarded.

API

The API you already integrate.

Zarx speaks the OpenAI API. Point the official SDK at api.zarx.ai, keep your request and response handling, change the model id. The Responses endpoint is primary; Chat Completions is there for code that has not moved yet.

  • Zarx is an OpenAI-compatible API: the official openai SDKs work by changing the base URL, and requests and responses keep the OpenAI shapes.

    Source: Zarx API documentation: OpenAI compatibility matrix and Node.js SDK compatibility (base URL swap)

  • POST /v1/responses implements the OpenAI Responses API with identical request and response shapes: string or chat-array input, instructions, tools, structured JSON output, metadata and server-side conversation chaining with previous_response_id.

    Source: Zarx API documentation: POST /v1/responses

  • POST /v1/chat/completions serves the Chat Completions shape (choices, message, usage with prompt, completion and total tokens) for the models we run ourselves.

    Source: Zarx API documentation: POST /v1/chat/completions

from openai import OpenAI

client = OpenAI(
    base_url="https://api.zarx.ai/v1",
    api_key=ZARX_API_KEY,
)

response = client.responses.create(
    model="glm-5.2",
    instructions="Answer in the language of the question.",
    input="Summarise the attached contract clause in three sentences.",
)
print(response.output_text)
The official openai SDK against Zarx. Only base_url and the model id change.

Streaming

Tokens as they are produced.

Set stream to true and read Server-Sent Events. The event names are the OpenAI ones, so streaming code written against api.openai.com runs unchanged. Nothing is buffered between the GPU and your client.

  • Streaming uses Server-Sent Events with the official OpenAI event names (response.created through response.completed), each chunk relayed as the model produces it, without buffering.

    Source: Zarx API documentation: streaming (SSE, OpenAI event shapes)

  • Errors use the OpenAI envelope: { error: { message, type, code, param } }, with the usual HTTP status codes.

    Source: Zarx API documentation: error catalog

curl -N https://api.zarx.ai/v1/responses \
  -H "Authorization: Bearer $ZARX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k2.6",
    "input": "List the data residency questions a bank should ask an inference provider.",
    "stream": true
  }'
A streamed request with curl. Replace the key; the endpoint is the design target for early access.

Tools and structure

Function calling and strict JSON.

Declare functions, let the model choose, feed the result back. Ask for output that validates against a JSON schema when a downstream system needs a contract, not prose. Retries are safe with an idempotency key.

  • Function calling (tools, tool_choice, parallel_tool_calls) and structured output with a strict JSON schema are supported on the Responses endpoint.

    Source: Zarx API documentation: tool and function calling; structured JSON output

  • An Idempotency-Key header makes retries safe: the same key returns the same response id.

    Source: Zarx API documentation: idempotency

Keys and usage

Every token accounted for, per key.

Keys belong to an account. Each request is recorded with its model and token counts, and rolled up per key and model by hour and by day. Limits apply where you set them: a key, a model, or the whole account.

  • Every request is authenticated with an API key scoped to an account; usage is recorded per request and aggregated per key and model into hourly and daily usage.

    Source: Zarx API documentation: authentication and usage accounting

  • Limits are enforced per key, per model or per account: requests per minute, tokens per minute, daily token limits and monthly spend limits, returning an OpenAI-shaped 429 with Retry-After when a hard limit is hit.

    Source: Zarx API documentation: rate-limit enforcement

  • GET /v1/models lists the models available to your key, with the reasoning effort levels each one supports.

    Source: Zarx API documentation: listing available models; reasoning effort parameter

Deployment

Shared capacity today. Dedicated capacity by agreement.

Early-access partners use shared capacity on NPAW iron: the same servers, the same jurisdiction, isolated keys and accounts. Dedicated GPUs for one customer, and on-premises deployment of the same stack, are discussed case by case.

  • NPAW owns and operates the servers that run Zarx. They are not rented cloud instances.

    Source: NPAW infrastructure inventory, 2026-09-03 (server-by-server record of NPAW-operated GPU hosts)

  • Models are served with vLLM and SGLang, open-source inference engines, on ROCm for the MI300X.

    Source: NPAW infrastructure inventory and model registry (vLLM and SGLang on MI300X hosts)

Batch

Asynchronous work, same models.

Upload a JSONL file of requests, create a batch, collect the results when they are ready. Useful for backfills, evaluations and anything that does not need an answer while a person waits.

  • An asynchronous Batch API (POST /v1/batches with JSONL files) is available for the models we run ourselves.

    Source: Zarx API documentation: Batch API

Not yet

What Zarx does not do yet.

Said plainly, so you can plan around it.

  • No self-serve signup and no public pricing during early access. Access is by invitation; pricing on request.

    Source: Zarx early-access terms (NPAW, September 2026)

  • Fine-tuning is offered to design partners as a managed engagement, not as an API endpoint.

    Source: Zarx early-access scope; the API exposes no fine-tuning endpoint today

  • No hosted tools (web search, file search, code interpreter). Use a function tool and your own backend.

    Source: Zarx API documentation: compatibility matrix (built-in tools)

  • No background mode. Long requests use an Idempotency-Key and a retry instead.

    Source: Zarx API documentation: compatibility matrix (background mode)

Run your first request on our iron.

Early access is a small program by design. Tell us what you run inference on today and what has to stay in your jurisdiction.