Platform

An OpenAI-compatible API on servers we own.

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

The base URL tells your SDK where to send requests. If you already use the OpenAI SDK, point it at your Zarx endpoint and use a Zarx key and a Z level as the model. If you are evaluating from scratch, start with the use cases on the home page.

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, put a Z level in the model field. 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="z-pro",
    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. A Zarx endpoint, an API key and a Z level.

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": "z-ultra",
    "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.

Z levels

Choose the level. Keep the API.

z-ultra, z-pro and z-fast are the names you put in the model field. Each one carries a default reasoning policy; reasoning.effort overrides it per request where supported, and GET /v1/models publishes the accepted values and the default for each level.

  • Reasoning is model-specific. When a model supports it, reasoning.effort sets the requested level and the model registry publishes the accepted values and default. Unsupported values are rejected.

    Source: Zarx API documentation: reasoning effort parameter and model capability discovery

  • 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

curl https://api.zarx.ai/v1/responses \
  -H "Authorization: Bearer $ZARX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "z-pro",
    "reasoning": { "effort": "high" },
    "input": "Compare these two indemnity clauses and list every difference."
  }'
A level with an explicit reasoning effort. Use the same level for repeatable evaluations and change it only when the workload needs a different capability.

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 level and token counts, and rolled up per key and level by hour and by day. Limits apply where you set them: a key, a level, 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 servers NPAW owns and operates in the EU: the same jurisdiction, with isolated keys and accounts, metered in tokens. Dedicated capacity with a fixed model is available under agreement on datacenter GPUs; on-premises deployment of the same stack is discussed case by case. Include these requirements in your access request.

  • 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)

  • Dedicated capacity with a fixed model is available under agreement, on datacenter GPUs NPAW owns and operates, for partners who need their own serving capacity.

    Source: Zarx early-access agreement (NPAW, October 2026); NPAW infrastructure inventory

  • Shared capacity on the Z levels is usage based, metered in tokens and accounted for per key. Dedicated capacity is reserved for a period. Figures are agreed per partner; no public price list exists during early access.

    Source: Zarx early-access agreement (NPAW, October 2026)

Batch

Asynchronous work, same API.

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 under an early-access agreement; pricing on request.

    Source: Zarx early-access agreement (NPAW, October 2026)

  • Fine-tuning is offered to early-access 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)

  • No speech or voice endpoints on Zarx yet. Transcription, translation and speech are discussed per partner during early access.

    Source: Zarx early-access scope; the Z levels are text and image models today

Run your first request on our servers.

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