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.Three thinking tiers, measured
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,360cached_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 iscaching: {"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).
Code Examples
Chat Completions
Responses (native multi-turn + explicit caching)
Best Practices
- Thinking off as the baseline, on by exception: make
thinking: {"type": "disabled"}your default config and switch toreasoning_efforttiers only for genuinely complex tasks — do not pay thinking costs on simple questions. - Give
max_output_tokensheadroom: 3000+ with thinking on, 4000+ on the high tier, so reasoning never squeezes out the actual answer. - 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.
- Use Responses chaining for multi-turn:
previous_response_idavoids resending history, and stacked with explicit caching it cuts both cost and latency on long-context conversations. - 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
Why are simple questions slow and token-hungry?
Why are simple questions slow and token-hungry?
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.Responses returns incomplete with empty text - what happened?
Responses returns incomplete with empty text - what happened?
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.Chat Completions or Responses - which one?
Chat Completions or Responses - which one?
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 is enabled but cached_tokens stays 0 - why?
Explicit caching is enabled but cached_tokens stays 0 - why?
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.Is MCP supported?
Is MCP supported?
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.
I got a 503 - is the service down?
I got a 503 - is the service down?
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.Related Resources
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