Priority tier

service_tier: "priority" moves a request to the front of both queues it passes through: the scheduler's grant queue (the durable backlog waiting for capacity on your model) and the engine's waiting queue (granted work waiting for a slot in the running batch). It is a per-request scheduling lane on the same fleet — same endpoints, same models, same pinned versions.

Time to first token is queue wait plus prefill. Priority removes the queue-wait term at contention. It does not change the compute: generation is no faster, and running requests are never preempted — priority is first into the next free slot, not into an occupied one. When there is no queue, priority changes nothing.

Using it

One field on either realtime surface:

curl https://api.sference.com/v1/chat/completions \
  -H "Authorization: Bearer $SFERENCE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-ai/DeepSeek-V4-Flash-0731",
    "service_tier": "priority",
    "messages": [{"role": "user", "content": "Summarize this thread."}]
  }'

from openai import OpenAI

client = OpenAI(base_url="https://api.sference.com/v1", api_key=SFERENCE_KEY)

resp = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V4-Flash-0731",
    service_tier="priority",
    messages=[{"role": "user", "content": "Summarize this thread."}],
)

On /v1/responses, the response object echoes the tier the request was served at. The values auto, default, and scale remain accepted and serve as the default tier, so OpenAI-shaped code that already sets them keeps working unchanged. The Anthropic messages surface (/v1/messages) takes no service_tier.

What it costs

Priority bills at 1.3 × list price on the tokens the request uses, resolved per request — no subscription, no commitment. A request either carries the tier or it does not, so you can send interactive turns at priority and leave everything else at default. Usage summaries and the console analytics break spend down by tier, so the premium is visible per model per day.

Priority does not combine with the batch window: batch bodies reject service_tier: "priority". (Flex and batch stack the other way — a flex batch bills at 0.35 ×.)

When to use it

The pattern to look for is a p99 TTFT that is fine at 3am and degrades at peak. That gap is queue wait, and queue wait is what priority removes.

• Interactive agent turns. An agent doing eight sequential model calls pays queue wait eight times; the compounding makes even moderate congestion user-visible.
• User-facing chat at peak. A human staring at a spinner is the canonical latency-critical workload.
• Tool-call loops behind a user action. The user waits on the last call, which waits on all the ones before it.

When not to bother:

• Your model is idle. No queue, nothing to skip — you pay 1.3 × for the same TTFT.
• Prefill-bound prompts. If TTFT is dominated by a long uncached prompt, the wait is inside the engine's compute, not in a queue. Priority gets you to the front and then you pay the same prefill as everyone else; prompt caching is the lever there.
• Background work. Evals, backfills, and overnight jobs should go the other direction: flex at 0.7 × or batch at 0.5 ×, which trade latency for price just as deliberately.

Combining with a queue bound

Priority and max_queue_wait_s answer different questions and compose well. Priority reduces how long your request waits; max_queue_wait_s bounds how long it may wait before the scheduler rejects it with max_queue_wait_exceeded. The bound applies to priority requests the same as any other, so setting both gives you the front of the queue with a hard failover tripwire if the fleet is saturated anyway.

Under the hood

• Entitlement is derived at auth time from the organization's category — no flag, no per-key state.
• The scheduler's backlog orders realtime rows priority-first, then by deadline. The window term still dominates, so background work can never jump interactive traffic regardless of tier.
• Engine urgency is engine-neutral: SGLang orders higher values first, vLLM lower values first, and the adapters normalize. The delta between priority and default is deliberately small — below the engine's preemption threshold — so the queue can be reordered but a running request can never be interrupted.
• Priority bypasses the API's per-model queue-cap shed, because rejecting priority on the grounds that default traffic filled the queue would defeat the tier. The scheduler's TTFT ceiling still applies under sustained overload — the bypass is bounded, not absolute.