Skip to main content
Seed 2.1 Turbo (dola-seed-2-1-turbo-260628) is a production-grade text model released by ByteDance’s Seed team on June 23, 2026 (BytePlus product name: Dola-Seed-2.1-turbo). It targets low-cost, low-latency enterprise workloads at high request volume, with a family-rated 256K context window. APIYI has fully verified both endpoints (15/15 test cases passed) — Chat Completions and Responses are both ready to call.
Seed 2.1 Turbo is live on APIYI: model name dola-seed-2-1-turbo-260628, available on the default / svip groups. One thing sets it apart from most models — deep thinking is ON by default. For latency- or cost-sensitive calls, explicitly pass thinking: {"type": "disabled"} (see “Controlling Deep Thinking” below).

Key Strengths

Production-grade pricing

$0.50 input / $2.50 output per 1M tokens — half the price of the same-generation Seed 2.1 Pro, built for high-frequency calls.

Two native endpoints

Both Chat Completions and Responses are natively supported: event streams, reasoning items, and multi-turn previous_response_id all work on the Responses side.

Controllable deep thinking

A thinking switch plus reasoning_effort tiers (low vs high differs 4x in measured reasoning tokens) let you budget thinking per task.

Two-layer caching

Implicit caching hits automatically from the 2nd request; explicit caching on Responses with chained calls hits the full previous context and roughly halves latency.

Model Information

Verified Capability Matrix

APIYI’s measured results as of July 21, 2026 (official claims vs actual behavior):

Pricing

Billing note: reasoning content is billed as regular output tokens — which is exactly why you should budget thinking depth per task. Top-up bonuses lower the effective cost further, see Recharge Promotions.

Controlling Deep Thinking

This is the single most important thing about this model: deep thinking is on by default, so even a one-line question first produces hundreds of tokens of reasoning. In our tests, a one-sentence self-introduction consumed 444 output tokens (409 of them reasoning) and took 7–19 seconds non-streaming.
For latency- or cost-sensitive workloads (support bots, high-frequency short Q&A, batch jobs), explicitly pass "thinking": {"type": "disabled"}. Measured result: reasoning tokens drop to zero and responses get dramatically faster.

Three thinking tiers, measured

Give max_output_tokens headroom: reasoning counts against the output budget. On Responses, a small budget gets fully consumed by thinking and the call returns status: "incomplete" (reason: length) with empty text — it looks like no output, but it is a budget problem. Start at 1500, and use 4000+ with the high tier.

Cutting Costs with Caching

The model supports two caching layers with different mechanics — do not mix them up:

Implicit caching (automatic, both endpoints)

No parameters needed: a repeated long prefix (e.g. a fixed system prompt) hits automatically from the 2nd request. Measured: with a ~2,600-token system prompt, requests 2 and 3 reported 2,360 cached_tokens. Check hits in usage.prompt_tokens_details.cached_tokens (Chat) or usage.input_tokens_details.cached_tokens (Responses).

Explicit caching (Responses only, requires chaining)

The correct way to use explicit caching is caching: {"type": "enabled"} combined with previous_response_id chaining: when turn 2 carries the previous response id, the entire previous context hits the cache (measured: 7,873 tokens fully cached, latency down from 8s to 4s).
Enabling without chaining loses on both fronts: with caching.enabled set but no previous_response_id, merely repeating the same prefix yields cached_tokens of 0 every time — and the implicit prefix cache stops applying too. Either omit the caching parameter and rely on implicit caching, or enable it and chain strictly.

Code Examples

Chat Completions

Responses (native multi-turn + explicit caching)

Best Practices

  1. Thinking off as the baseline, on by exception: make thinking: {"type": "disabled"} your default config and switch to reasoning_effort tiers only for genuinely complex tasks — do not pay thinking costs on simple questions.
  2. Give max_output_tokens headroom: 3000+ with thinking on, 4000+ on the high tier, so reasoning never squeezes out the actual answer.
  3. Put fixed system prompts first: implicit caching matches by prefix — keep the unchanging part at the front and save money automatically from the 2nd request.
  4. Use Responses chaining for multi-turn: previous_response_id avoids resending history, and stacked with explicit caching it cuts both cost and latency on long-context conversations.
  5. Handle 503 in error logic: a misspelled model name or missing group permission returns 503 (no available channel), not the OpenAI-conventional 404 — do not key retry logic on 404.

FAQ

Because deep thinking is on by default. Even a one-line question first generates hundreds of reasoning tokens (~400 measured) — slow and costly. Add "thinking": {"type": "disabled"} to the request body; measured reasoning tokens drop to zero.
max_output_tokens is too small and thinking consumed the whole budget (incomplete_details.reason is length). Raise the budget to 1500+, or disable/lower the thinking tier.
Use Chat Completions for single-turn or self-managed history (broadest ecosystem compatibility). Use Responses for multi-turn conversations, explicit caching, or MCP tools — explicit caching and MCP are Responses-only.
Explicit caching requires chaining: from turn 2 onward you must pass the previous turn’s previous_response_id. Independently repeated requests with caching.enabled never hit — and the implicit prefix cache stops applying too. If chaining does not fit your app, simply drop the caching parameter and rely on implicit caching.
The official capability sheet lists MCP support on the Responses API. APIYI’s test round did not cover MCP (it needs an external MCP server) — validate with low traffic before production use.
Check the model name spelling first. This model returns 503 (“no available channels”) instead of 404 for unknown model names. If the name is correct and 503 persists, check your group permission (this model needs default or svip) or contact support.

Chat Playground

Debug the Chat Completions endpoint interactively

Responses Playground

Debug the Responses endpoint interactively

Model Info

Browse all available models and groups

API Manual

The complete API usage guide