Completion windows

Completion windows let you express how long your requests can wait, giving Sail room to increase cost efficiency. Sail serves low-latency inference by default for core models, at lower cost than traditional inference providers. You can opt in to the balanced or flex completion windows to cut token costs drastically, for work that is latency tolerant. Completion windows can be specified on a per-request basis. Long-horizon agents can make use of all three depending on the task at hand.

Completion windows at a glance

Window	Scheduling	Typical use case	Price vs. traditional inference providers
`asap`	Low-latency serving	Interactive UIs, human-in-the-loop	~5-35% less
`balanced`	Wider scheduling window	Background agents, subagents, and pipelines; parallel work	~45-65% less
`flex`	Best-effort scheduling	Batch processing, evals, offline	~60-80% less

Not every core model supports every completion window yet. Check Pricing for current per-model availability.

Completion window details

`asap`

asap is the default, low-latency path for Sail’s core models. Use it when a person is waiting or when one agent turn blocks the next.

GLM 5.2 FP8 TTFT & TPS

For GLM-5.2 FP8 requests using asap, Sail targets:

Average time to first token (TTFT) under 10 seconds
P90 TTFT under 10 + (input tokens / 1,000) seconds
Average generation speed of about 20 to 30 tokens per second (TPS)

These operating targets apply only to GLM-5.2 FP8 on asap and are not an SLA.

`balanced`

balanced gives Sail more time to place work on efficient capacity, greatly lowering token costs for long-horizon background agents and pipelines.

This tier enables you to run many background agents, taking on very large tasks, at reasonable cost.

`flex`

flex gives Sail the widest scheduling window and offers the lowest available token prices. It has no TTFT or TPS target. Common use cases include batch jobs, evals, and offline processing. For individual requests, flex requires the Responses API with background=True. Batch API requests can also use flex.

flex with Chat Completions and Messages

Chat Completions and Messages technically accept flex as a completion window, but both wait synchronously and may time out before the request finishes. Therefore, we recommend using the Responses API or Batch API instead.

Retries and timeouts

flex requests can spend longer queued than other completion windows. Once Sail accepts a request, Sail keeps processing it unless it reaches a terminal status. A client-side polling timeout does not cancel its background work. Keep polling the response instead of creating a duplicate request. If submission fails ambiguously, retry with the same Idempotency-Key so Sail returns the existing work instead of creating a duplicate. If the response reaches failed, inspect its error before deciding whether to submit a new request.

How to set completion windows

Set metadata.completion_window to asap, balanced, or flex:

curl https://api.sailresearch.com/v1/responses \
  -H "Authorization: Bearer $SAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.2-FP8",
    "input": "Explain the key ideas behind transformers.",
    "metadata": {
      "completion_window": "balanced"
    }
  }'

curl https://api.sailresearch.com/v1/chat/completions \
  -H "Authorization: Bearer $SAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.2-FP8",
    "messages": [
      {"role": "user", "content": "Explain the key ideas behind transformers."}
    ],
    "metadata": {
      "completion_window": "balanced"
    }
  }'

curl https://api.sailresearch.com/v1/messages \
  -H "Authorization: Bearer $SAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.2-FP8",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Explain the key ideas behind transformers."}
    ],
    "metadata": {
      "completion_window": "balanced"
    }
  }'

curl https://api.sailresearch.com/v1/batches \
  -H "Authorization: Bearer $SAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "/v1/responses",
    "label": "transformers",
    "requests": [
      {
        "custom_id": "transformers-1",
        "params": {
          "model": "zai-org/GLM-5.2-FP8",
          "input": "Explain the key ideas behind transformers.",
          "metadata": {
            "completion_window": "balanced"
          }
        }
      }
    ]
  }'

For flex, set background=true when using the Responses API. For reliable flex requests, use Responses API background mode or Batch instead of waiting synchronously through Chat Completions or Messages.

curl https://api.sailresearch.com/v1/responses \
  -H "Authorization: Bearer $SAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.2-FP8",
    "input": "Explain the key ideas behind transformers.",
    "background": true,
    "metadata": {
      "completion_window": "flex"
    }
  }'

curl https://api.sailresearch.com/v1/batches \
  -H "Authorization: Bearer $SAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "/v1/responses",
    "label": "transformers",
    "requests": [
      {
        "custom_id": "transformers-1",
        "params": {
          "model": "zai-org/GLM-5.2-FP8",
          "input": "Explain the key ideas behind transformers.",
          "metadata": {
            "completion_window": "flex"
          }
        }
      }
    ]
  }'

Default behavior

For inference requests for core models, the default behavior (when no completion_window is specified) is low-latency inference (asap). The exceptions to this default behavior are:

Batch inference requests, which default to balanced for core models.
LoRA requests, which default to balanced for core models.

For flex-only models, the default (and only) behavior is flex for all inference requests, including Batch and LoRA. Flex-only models require background requests (see examples above).

Getting started

Inference

Guides

Sailbox

Voyages

Security & compliance