> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sailresearch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Completion windows

> Trade off latency for lower token prices

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](/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.

<div className="sail-compact-accordion">
  <Accordion title="GLM 5.3 FP8 TTFT & TPS">
    For GLM-5.3 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.3 FP8 on `asap` and are not an SLA.
  </Accordion>
</div>

### `balanced`

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

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

### `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](/support#responses-api)
with `background=True`. [Batch API](/support#batch-api) requests can also use
`flex`.

<div className="sail-compact-accordion">
  <Accordion title={<><code>flex</code> 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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</div>

## How to set completion windows

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

<CodeGroup>
  ```bash Responses theme={null}
  curl https://api.sailresearch.com/v1/responses \
    -H "Authorization: Bearer $SAIL_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "zai-org/GLM-5.3",
      "input": "Explain the key ideas behind transformers.",
      "metadata": {
        "completion_window": "balanced"
      }
    }'
  ```

  ```bash Chat theme={null}
  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.3",
      "messages": [
        {"role": "user", "content": "Explain the key ideas behind transformers."}
      ],
      "metadata": {
        "completion_window": "balanced"
      }
    }'
  ```

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

  ```bash Batch theme={null}
  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.3",
            "input": "Explain the key ideas behind transformers.",
            "metadata": {
              "completion_window": "balanced"
            }
          }
        }
      ]
    }'
  ```
</CodeGroup>

For `flex`, set `background=true` when using the [Responses API](/support#responses-api). For reliable `flex` requests, use Responses API background mode or Batch instead of waiting synchronously through Chat Completions or Messages.

<CodeGroup>
  ```bash Responses highlight={7} theme={null}
  curl https://api.sailresearch.com/v1/responses \
    -H "Authorization: Bearer $SAIL_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "zai-org/GLM-5.3",
      "input": "Explain the key ideas behind transformers.",
      "background": true,
      "metadata": {
        "completion_window": "flex"
      }
    }'
  ```

  ```bash Batch theme={null}
  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.3",
            "input": "Explain the key ideas behind transformers.",
            "metadata": {
              "completion_window": "flex"
            }
          }
        }
      ]
    }'
  ```
</CodeGroup>

### Default behavior

For inference requests for [core models](/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).