Turbo (priority routing)

Turbo variants route your request through a priority lane: when a model is under load, turbo requests are served ahead of standard ones. Every turbo-capable model exposes a second id: the base id with a -turbo suffix.

glm-5.2          →  glm-5.2-turbo
deepseek-v4-pro  →  deepseek-v4-pro-turbo
kimi-k2.7        →  kimi-k2.7-turbo

Most models offer a turbo variant. A few do not: if a model card has no turbo price, there is no -turbo id for it, and requesting priority on it is ignored.

What to expect

Turbo buys priority, not a fixed speed. In practice you can see up to 5× faster responses than the same model's standard endpoint, but the actual gain depends on server load at that moment:

  • Quiet periods: standard is already fast, so turbo's edge is small.
  • Typical load: turbo is usually noticeably faster; this is where it earns its price.
  • Heavy load: turbo means faster than standard, but both lanes feel the weather. Priority shortens the queue; it doesn't remove it.

If your product needs a hard latency ceiling, design for it the way you would with any provider: timeouts, streaming-first UX, and graceful fallbacks. Turbo shifts the odds in your favor on every request; it is not an SLA.

Two ways to ask for turbo

1. Use the -turbo model id:

resp = client.chat.completions.create(
    model="deepseek-v4-pro-turbo",
    messages=[{"role": "user", "content": "Refactor this function..."}],
)

2. Use the OpenAI service_tier parameter:

resp = client.chat.completions.create(
    model="deepseek-v4-pro",
    service_tier="priority",
    messages=[...],
)

Both are equivalent. If you send service_tier: "priority" to a model that doesn't support turbo, the parameter is safely ignored and you're billed at the standard rate.

Pricing

Turbo carries a priority surcharge over the standard rate. Each model card shows both the standard and turbo $/1M prices side by side, so you can see the exact difference before you send.

Turbo affects routing priority and latency: it does not change the model, its context window, or its outputs.

When to use it

  • Interactive, user-facing requests where latency matters.
  • Bursty production traffic that must stay responsive under load.

For batch jobs and background work, the standard tier is usually the better value.