UltraFast models

Learn which UltraFast models are active, where they work, and how context bands, prompt caching, scheduled prices, web search, and retryable concurrency limits affect billing.

What are UltraFast models?#

UltraFast models are OpenGateway-optimized variants for low-latency use cases, shown in the Optimized by OpenGateway section of /models. This is a catalog grouping, not a new model owner: canonical model IDs keep the creator prefix, such as deepseek/deepseek-v4.1-flash-ultrafast and z-ai/glm-5.3-flash-ultrafast.

The public GET /v1/models catalog currently reports these UltraFast IDs, statuses, and context windows. Check status at runtime because catalog entries can change.

Model IDCatalog statusContext window
deepseek/deepseek-v4.1-flash-ultrafastactive1,000,000 tokens
z-ai/glm-5.3-flash-ultrafastactive1,000,000 tokens
z-ai/glm-5.3-ultrafastdeprecated1,000,000 tokens
z-ai/glm-5.2-ultrafastdeprecated1,000,000 tokens
moonshotai/kimi-k3-ultrafastdeprecated262,144 tokens

Deprecated entries may remain available during their grace period. For new integrations, choose a model whose catalog status is active.

The current catalog lists all three endpoint values below for each ID in the table. Confirm a model's endpoints before choosing an API:

APIRequest pathCatalog endpoint value
Chat CompletionsPOST /v1/chat/completionschat_completions
MessagesPOST /v1/messagesmessages
ResponsesPOST /v1/responsesresponses

Long-context pricing#

Check /models for current model prices before sending requests. Price schedules and long-context bands can change the amount shown there.

For deepseek/deepseek-v4.1-flash-ultrafast and z-ai/glm-5.3-flash-ultrafast, a request with more than 256K total input tokens uses twice the input-token price for the whole request. Cache-read input and output tokens are not surcharged. Each model's detail page shows a long-context pricing table with a >256K total input tokens band and separate input, cached-input, and output prices.

Prompt caching#

Cached input is billed at the model's cache-read price, shown as the cached-input price on /models. A shared prefix can benefit from prompt caching automatically. Keep system instructions and tool definitions stable at the start of requests, put timestamps and other changing content after that prefix, and reuse the same API key and session across related requests.

Scheduled prices#

Some models have time-based prices. On /models, an active schedule appears as a −N% NOW badge with a separate next-change line. The price and schedule are not fixed; check the page when you plan a request.

When you use the web_search tool with the Responses API, each search is billed separately. Web-search charges are not discounted by an UltraFast model's time-based price schedule.

Concurrency limits and overloads#

Per-key limit#

Each API key has a limit on the number of in-flight requests per UltraFast model. When that limit is full, OpenGateway immediately rejects additional requests without sending them upstream. For OpenAI-compatible endpoints, the response is HTTP 429 with Retry-After and this error body:

HTTP
HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/json
JSON
{
"error": {
"message": "You exceeded your concurrent request limit for this model",
"type": "rate_limit_error",
"code": "concurrency_limit_exceeded"
}
}

The Messages endpoint uses its Anthropic-style error envelope. In either case, wait for the returned Retry-After interval before retrying; do not assume a fixed interval. Contact support to request a higher per-key or team limit.

Serving overload#

A model can also be temporarily overloaded, independently of your key's concurrency limit. In that case, OpenGateway can return HTTP 529 with error type overloaded_error and a Retry-After header (the OpenAI-compatible error code is overloaded). Wait for the advertised interval, cap retries, and reduce parallel requests if overloads continue.

Python retry example#

This example disables SDK retries so the client can honor Retry-After itself. Set UF_MAX_PARALLEL to a local worker cap no higher than the limit assigned to your key.

Python
import os
import time
from concurrent.futures import ThreadPoolExecutor
from openai import APIStatusError, OpenAI
client = OpenAI(
api_key=os.environ["OPENGATEWAY_API_KEY"],
base_url="https://apis.opengateway.ai/v1",
max_retries=0,
)
MODEL = "deepseek/deepseek-v4.1-flash-ultrafast"
MAX_PARALLEL = int(os.environ["UF_MAX_PARALLEL"])
MAX_ATTEMPTS = 3
def ask(prompt):
for attempt in range(MAX_ATTEMPTS):
try:
return client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": prompt}],
)
except APIStatusError as exc:
body = exc.body if isinstance(exc.body, dict) else {}
error = body.get("error", {})
if exc.status_code not in (429, 529) or error.get("code") not in (
"concurrency_limit_exceeded",
"overloaded",
):
raise
if attempt == MAX_ATTEMPTS - 1:
raise
retry_after = exc.response.headers.get("Retry-After")
if retry_after is None:
raise
time.sleep(float(retry_after))
prompts = ["Summarize this report.", "Extract the key dates."]
with ThreadPoolExecutor(max_workers=MAX_PARALLEL) as pool:
responses = list(pool.map(ask, prompts))

See also#

UltraFast models — OpenGateway