Cluster Models.

Community models. All are accessed via the same OpenAI-compatible API with the same base URL.

glm5.3 - 753B MoE

deepseek-v4-flash - 305B MoE

glm5.3-flash - 320B-18B

qwen3.8-flash - 125B-6B

mimo-v2.6-flash - omnimodal

gemma4 - 26B-A4B

qwen3.6 - 35B-A3B

qwen3-embedding - 8B

rerank - Qwen3-Reranker-8B

kokoro - v1.0

whisper - large-v3

flux-2-klein

qwen-image-2.1

Controlling reasoning.

Every chat model above reasons before it answers. The reasoning arrives separately from the answer: in message.reasoning_content on Chat Completions, as a reasoning output item on Responses. One parameter controls it, the same on every model:

The values, from no reasoning to the deepest: none, minimal, low, medium, high, xhigh, max.

To turn reasoning off, send none. That is the whole switch. It works on every model except GLM, which cannot stop reasoning (see the table).

Code written for another provider keeps working: we also accept thinking: {"type": "disabled"}, reasoning: {"enabled": false}, enable_thinking: false and chat_template_kwargs: {"enable_thinking": false}, at the top level of the body or inside extra_body. Each one means exactly none. If a request carries both a value and one of these, the value wins.

With no parameter every model reasons (qwen3.6 and gemma4 with a 16,384-token budget). Reasoning costs latency. Use only the values listed here. Any other value is passed through unchanged and is not part of this contract: depending on the model it is rejected with a 400 or ignored.

Your output budget (max_tokens or max_completion_tokens on Chat Completions, max_output_tokens on Responses) is used exactly as you send it on every model, except above the model’s maximum on two models, where it is lowered to that maximum: 131072 on glm5.3-flash, 393216 on deepseek-v4-flash. Reasoning tokens are spent from that same budget.

Empty answer with finish_reason: "length"? With reasoning on, a small budget can run out before the answer starts. On Chat Completions you get an empty content with finish_reason: "length", the reasoning in message.reasoning_content, and usage.completion_tokens_details.reasoning_tokens equal to completion_tokens; only the three together mean the budget ran out while reasoning, and a non-streamed call also carries the response header x-nan-truncated-in-reasoning: true. On Responses the response has status: "incomplete" with incomplete_details.reason: "max_output_tokens", only a reasoning output item and no message text, and usage.output_tokens_details.reasoning_tokens equals output_tokens. On deepseek-v4-flash a dense prompt can reason past 16k tokens. If you only need the answer, the reliable fix is to turn reasoning off: reasoning_effort: "none" on Chat Completions, reasoning: {"effort": "none"} on Responses (GLM cannot turn it off; minimal is its shortest). With reasoning off the answer can still stop at the budget, with text, so the budget must fit the answer. A lower effort usually reasons less, but on deepseek-v4-flash and qwen3.8-flash it is a hint, not a cap; only qwen3.6 and gemma4 cap it, on Chat Completions. For a hard cap on qwen3.6, gemma4 and qwen3.8-flash, see Capping reasoning with a token budget. If you want the reasoning, give a generous budget and stream the answer.

curl https://api.nan.builders/v1/chat/completions \
  -H "Authorization: Bearer $NAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "reasoning_effort": "none",
    "messages": [{"role": "user", "content": "Write a one-line summary of the CAP theorem."}]
  }'

On Helmcode, use https://api.helmcode.com/v1 as the base URL; everything else is identical.

With the OpenAI SDK, on Chat Completions and on Responses:

# pip install openai
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["NAN_API_KEY"],
    base_url="https://api.nan.builders/v1",  # Helmcode: https://api.helmcode.com/v1
)

chat = client.chat.completions.create(
    model="deepseek-v4-flash",
    reasoning_effort="none",
    messages=[{"role": "user", "content": "Write a one-line summary of the CAP theorem."}],
)
print(chat.choices[0].message.content)

resp = client.responses.create(
    model="deepseek-v4-flash",
    reasoning={"effort": "none"},
    input="Write a one-line summary of the CAP theorem.",
)
print(resp.output_text)

If your version of the Python SDK does not know the parameter yet (it raises TypeError: ... unexpected keyword argument), send it through extra_body; it reaches the API exactly the same:

chat = client.chat.completions.create(
    model="deepseek-v4-flash",
    extra_body={"reasoning_effort": "none"},
    messages=[{"role": "user", "content": "Write a one-line summary of the CAP theorem."}],
)

In Node, with the same names as the HTTP API:

// npm install openai
import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.NAN_API_KEY,
  baseURL: 'https://api.nan.builders/v1', // Helmcode: https://api.helmcode.com/v1
});

const chat = await client.chat.completions.create({
  model: 'deepseek-v4-flash',
  reasoning_effort: 'none',
  messages: [{ role: 'user', content: 'Write a one-line summary of the CAP theorem.' }],
});
console.log(chat.choices[0].message.content);

const resp = await client.responses.create({
  model: 'deepseek-v4-flash',
  reasoning: { effort: 'none' },
  input: 'Write a one-line summary of the CAP theorem.',
});
console.log(resp.output_text);

TypeScript: if your SDK version types the parameter as a union that lacks a value you send (for example max), add // @ts-expect-error on the line above it, or cast the params object. The API accepts every value in the table.

const chat = await client.chat.completions.create({
  model: 'deepseek-v4-flash',
  reasoning_effort: 'max' as any, // older SDK types do not list 'max'
  messages: [{ role: 'user', content: 'Write a one-line summary of the CAP theorem.' }],
});

Capping reasoning with a token budget.

On qwen3.6, gemma4 and qwen3.8-flash you can also cap the reasoning phase at a number of tokens, on Chat Completions. Send thinking_token_budget or thinking_budget: they are two names for the same parameter, so use whichever your code already sends. Each model receives the name it reads. Put it at the top level of the body or inside extra_body.

• An integer from 1 to 32768 caps reasoning at that many tokens. It is a hard cap: the model stops reasoning there and writes its answer.
• 0 turns reasoning off, like reasoning_effort: "none".
• On NaN, a larger value (or one that is not an integer) is lowered to 32768.

Send either a budget or reasoning_effort, not both: combined, the result differs by model. On the other models a budget is not part of this contract (depending on the model it is rejected with a 400 or ignored); use reasoning_effort there. On Responses the budget is not guaranteed to apply; use reasoning: {"effort": ...} there.

curl https://api.nan.builders/v1/chat/completions \
  -H "Authorization: Bearer $NAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-flash",
    "thinking_budget": 2048,
    "messages": [{"role": "user", "content": "How many primes are there below 200?"}]
  }'

With the OpenAI SDK it goes through extra_body:

chat = client.chat.completions.create(
    model="qwen3.8-flash",
    extra_body={"thinking_budget": 2048},
    messages=[{"role": "user", "content": "How many primes are there below 200?"}],
)

Long outputs: stream them.

A request without stream: true returns nothing until the whole answer is ready, and it has to be ready within 120 seconds. Past that, the connection is closed with a 524 (or an error a few seconds earlier), whatever the model. At deepseek-v4-flash speeds that is roughly 10,000 to 15,000 output tokens; slower models, and reasoning models that think before they answer, fit less.

If you ask for long outputs (a large max_tokens, long code files, agents that write whole documents), use stream: true. A stream has no total time limit while it keeps producing: tokens reach you as they are generated, however long the answer runs. The one exception is a turn that produces only reasoning for a long time, see the reasoning-only stream limit below. Every chat model supports streaming on both endpoints (/v1/chat/completions and /v1/responses).

Reasoning-only stream limit.

Reasoning-heavy prompts can keep a model thinking for a long time before it writes anything. When a streaming turn has produced only reasoning — no content, no tool calls — for 420 seconds, the platform closes the turn instead of letting it run into a dead end. A turn that is demonstrably thinking — it has already produced more than 45,000 reasoning characters — gets until 600 seconds. The reasoning-character budget also scales with the size of your prompt: roughly 150,000 characters of headroom plus half the prompt’s size in characters, capped at 300,000. When the platform closes the turn you receive finish_reason: "length" on an empty delta, followed by a usage chunk.

That usage chunk is an estimate of what the attempt consumed up to the cut (prompt and reasoning tokens), marked "estimated": true, "billed": false — turns closed this way are not charged against your quota — and carries a nan_truncation marker so clients can tell this closure apart from a real context-length cut. Request it with stream_options: {"include_usage": true}.

Two things worth knowing:

• The limit does not cap your output. The first visible token of content or any tool call disarms it for the rest of the turn: answers that write as they go are never cut, however long they run.
• If a turn closes this way, the model was still planning when it hit the ceiling. Lower reasoning_effort where the model supports it (table above), or restructure the prompt so the model starts writing early.

The limit exists to bound a known failure mode of thinking models: they occasionally plan without converging for 10–25 minutes and burn their whole output budget with zero visible output. The bounds sit above the reasoning traces of healthy converging turns in our production traffic, and only tighten when a stream is stuck.

Rate limits