Z levels

Three levels of Z, served from servers we own.

Pick a level in your integration: z-ultra, z-pro or z-fast. Each level describes a kind of work and carries a published reasoning policy. The API, keys and EU-resident serving stay the same.

Z levels

Choose the work, not the hardware.

Same API, same keys, same servers at every level. GET /v1/models lists the levels your key can use and the reasoning values each one accepts. Choose the level by the work you need to do, and keep the same integration as your needs change.

  • Deep reasoning

    Z Ultra

    Reasoning on by default for agents, long documents and work that takes several steps before an answer. The most capable level, with the longest answers and the highest cost per token.

  • Balanced capability

    Z Pro

    The default for coding, documents and assistant work. Raise reasoning.effort on the requests that need more. The middle ground on capability, answer length and cost.

  • Short-path tasks

    Z Fast

    Reasoning off by default for extraction, classification, routing and high-volume requests where a direct answer is the point. The quickest answers and the lowest cost per token, for work that does not need reasoning.

How to choose

A clear capability contract.

  • Choose by the work.

    Z Ultra is for multi-step reasoning and long documents. Z Pro is the balanced default for coding, documents and assistants. Z Fast is for direct, high-volume tasks where a short path is the point.

  • One integration.

    Put z-ultra, z-pro or z-fast in the model field. The endpoint, authentication and response shapes stay the same as you move between levels.

  • Reasoning is explicit.

    Each level publishes its default reasoning policy. Use reasoning.effort when you need to adjust the depth for a particular request.

  • Changes are announced.

    A level is a stable product name. When the model behind a level changes, we announce it with 14 days of notice and keep the previous behaviour available during a grace period, so your integration has time to adapt.

  • Pin a date when you need to.

    Each level also exposes a dated pinned identifier, for example z-pro-2026-10, that maps to one published checkpoint. Use the level to follow improvements; use the dated identifier when an evaluation must stay stable. Dated identifiers change only with notice.

  • Dedicated capacity by agreement.

    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.

The API contract

Keep the API as your workload changes.

Early-access partners get the levels that match their workload, with keys and usage accounted for per account. Shared capacity runs on servers NPAW owns and operates in the EU, under the same data path described on the Sovereignty page.

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.

If your workload changes, change the level in the model field. Your request and response handling stays the same. Model changes behind a level are announced with 14 days of notice plus a grace period during which the previous behaviour stays available; price changes are announced with 30 days of notice.

Tell us which capability your team needs.

Request access and describe the work you want to run. We reply with the right level, the access terms and the data path.