Cluster Models.

Community models. All are accessed via the same OpenAI-compatible API with the same base URL. The chat models are paid from one pool of credits: see Choose your model.

glm5.3 - 753B MoE

text generation & chat · agentic coding

~753B parameter MoE model, focused on coding and long-horizon agentic tasks. 1M token context. Text only: text in, text out, with no image, audio, video or file input; a request carrying one answers 400, earlier turns of the conversation included, so start a new session or switch to a model that takes images. Tool calling and reasoning (emits a reasoning trace). Paid from your credits, and one of the larger models: it costs more per token than the flash models, so it uses credits faster. Also capped at 400M tokens per rolling 4h window, which is the limit a heavy coding-agent run reaches first.

Type: MoE (~753B total)
Quantization: NVFP4
Attention: Sparse attention
Context: 1M tokens
Input modalities: text
Output modalities: text
Billing: credits · larger model
Rolling 4h window: 400M tokens

capabilities

Tool calling (function calling)
Reasoning control (reasoning_effort: minimal to max; always reasons, none is applied as minimal) · details
Coding and long-horizon agentic tasks
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

deepseek-v4-flash - 305B MoE

text generation, chat & vision

305B parameter MoE model, served as the Vision-Exp variant: it takes images as input. 1M token context. Tool calling and reasoning. Paid from your credits. Structured output: response_format json_object is supported (on api.nan.builders, on deepseek-v4-flash, the prompt must contain the word JSON, otherwise it is rejected with a 400 (the GLM models accept json_object without it)). json_schema is accepted on /chat/completions requests without tools, streamed or not: the answer is checked against your schema and, when it does not match, usually re-served by a provider that enforces it; an answer that could not be checked, or a miss the re-serve could not replace in time, is returned as is (validate it if your code depends on it). Every other json_schema request is rejected with a 400 before the model is called, on BOTH api.nan.builders and api.helmcode.com: with tools, on /responses, with a schema over 16 KB, not a valid JSON Schema, or one the gateway will not validate (a $ref outside the schema, $dynamicRef or $anchor, a nested $id, or too large once its $refs are inlined). (`api.nan.builders` reduces `n` to 1 and answers a single response; `api.helmcode.com` rejects `n` above 1 with a 400.) Streamed requests are served too, on both hosts: the stream is buffered, the complete answer is checked against your schema and then re-emitted as SSE. We refuse instead of deriving to another provider: a request the gateway cannot honour is a client bug, and a paid fallback would hide it from you. json_object guarantees syntactically valid JSON only, not its shape: describe the schema in the prompt. For schema-constrained output in those other requests, use qwen3.6 or gemma4, where json_schema with strict constrains fields, types and required keys; or, on this model, force one function tool whose parameters is your schema (see Examples). Your output budget is used exactly as sent (above 393216, its maximum, it is lowered to 393216), with reasoning on or off (max_tokens and max_completion_tokens on /chat/completions, max_output_tokens on /responses). Reasoning tokens count inside that budget: with reasoning on, a small budget can be spent entirely on reasoning. On /chat/completions the answer then comes back with an empty content and finish_reason "length" (the reasoning is in reasoning_content, and usage.completion_tokens_details.reasoning_tokens equals completion_tokens; non-streamed calls also carry the response header x-nan-truncated-in-reasoning: true); on /responses the status is incomplete, with only a reasoning output item. Dense prompts can reason past 16k tokens. The reliable fix is reasoning off (reasoning_effort "none" on /chat/completions, reasoning.effort "none" on /responses); a lower effort is a hint on this model, not a cap. Or give a generous budget and stream the answer.

Type: MoE (305B total)
Quantization: FP8
Context: 1M tokens
Input modalities: text · image
Output modalities: text
Billing: credits

capabilities

Tool calling
Reasoning control (reasoning_effort: none turns it off · minimal to max) · details
Vision (image input)
JSON mode (json_object; on api.nan.builders the prompt must mention JSON) · json_schema on chat without tools (on api.nan.builders the other cases, e.g. with tools or on /responses: 400)
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

glm5.3-flash - 320B-18B

multimodal text generation & chat

320B parameter MoE model (18B active), natively multimodal, with tool calling and reasoning. 1M token context. Paid from your credits, at a fraction of the credits per token of glm5.3. MIT license.

Type: MoE (320B total · 18B active)
Quantization: FP8
Context: 1M tokens
Input modalities: text · image
Output modalities: text
Billing: credits
License: MIT

capabilities

Tool calling (function calling)
Reasoning control (reasoning_effort: minimal to max; always reasons, none is applied as minimal) · details
Vision (image input)
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

qwen3.8-flash - 125B-6B

text generation, chat & vision

125B parameter MoE model (6B active), multimodal with vision, tool calling and reasoning on by default. 1M token context (1,048,576 tokens). Paid from your credits.

Type: MoE (125B total · 6B active)
Context: 1M tokens
Max answer: 131K tokens
Input modalities: text · image
Output modalities: text
Billing: credits
License: qwen-community-1.0

capabilities

Tool calling (XML format)
Reasoning on by default (reasoning_effort: none turns it off · minimal to max) · details
Vision (image input)
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

mimo-v2.6-flash - omnimodal

omnimodal — text, vision & audio

The newest Xiaomi MiMo, natively omnimodal with vision and audio input. 1M token context. Tool calling and reasoning. Paid from your credits.

Context: 1M tokens
Input modalities: text · image · audio
Output modalities: text
Billing: credits

capabilities

Tool calling (function calling)
Reasoning control (reasoning_effort: none turns it off · low to max; reasoning counts inside max_tokens) · details
Vision (image input)
Audio (audio input)
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

kimi-k3.1-pro - larger model

text generation, chat & vision · reasoning

Kimi K3.1 Pro: Moonshot AI's frontier reasoning model, for agents and coding. Vision (image input). 1M token context. Paid from your credits like every other chat model, and one of the larger models: it costs more per token than the flash models, so it uses credits faster.

Context: 1M tokens
Max answer: 1M tokens
Input modalities: text · image
Output modalities: text
Billing: credits · larger model

capabilities

Tool calling (function calling)
Reasoning model
Vision (image input)
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

qwen3.8-max - larger model

text generation, chat & vision · reasoning

Qwen3.8 Max: the largest Qwen 3.8 model, for hard reasoning and agents. Vision (image input). 1M token context. Paid from your credits like every other chat model, and one of the larger models: it costs more per token than the flash models, so it uses credits faster.

Context: 1M tokens
Max answer: 131K tokens
Input modalities: text · image
Output modalities: text
Billing: credits · larger model

capabilities

Tool calling (function calling)
Reasoning model (reasoning_effort: none turns it off; max_tokens bounds only the answer, max_completion_tokens caps the total) · details
Vision (image input)
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

deepseek-v4-pro - larger model

text generation & chat · reasoning

DeepSeek V4-Pro (0813 version): DeepSeek's large reasoning and coding model, served as its 0813 release. 1M token context. Paid from your credits like every other chat model, and one of the larger models: it costs more per token than the flash models, so it uses credits faster.

Context: 1M tokens
Max answer: 393K tokens
Input modalities: text
Output modalities: text
Billing: credits · larger model

capabilities

Tool calling (function calling)
Reasoning model
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

hy4 - larger model

text generation, chat & vision · reasoning

Hy4: Tencent's Hunyuan 4 model, for agents and long documents, and the lowest-priced of the larger models. Vision (image input). 1M token context. Paid from your credits like every other chat model, and one of the larger models: it costs more per token than the flash models, so it uses credits faster.

Context: 1M tokens
Max answer: 64K tokens
Input modalities: text · image
Output modalities: text
Billing: credits · larger model

capabilities

Tool calling (function calling)
Reasons by default; if you send no reasoning_effort (nor an alias) we apply low, and your own value always wins. A small max_tokens (around 2K) can still return empty content on code tasks: use at least 4K, or set reasoning_effort yourself
Vision (image input)
1M token context
Streaming generation (SSE)
Price per 1M tokens at cloud.nan.builders/tokens

gemma4 - 26B-A4B

text generation & chat

26B parameter MoE model (4B active), multimodal with vision. Tool calling and reasoning.

Type: MoE (26B total · 4B active)
Quantization: FP8
Context: 262K tokens
Sampling: temp=0.6, top_p=0.95
Reasoning: reasoning_config={}

capabilities

Tool calling (XML format)
Reasoning control (reasoning_effort: none or minimal turns it off · low to max) · details
Multimodal (vision / images)
Streaming generation (SSE)

qwen3.6 - 35B-A3B

text generation & chat

The previous generation. 35B parameter MoE, multimodal, with tool calling and reasoning. It still answers so that configurations naming it keep working, but deepseek-v4-flash is what to start from today.

Type: MoE (35B total)
Active per token: 3B
Quantization: FP8
Context: 262K tokens
Speculative decoding: MTP → ~2x throughput
Sampling: temp=0.6, top_p=0.95
Reasoning: reasoning_config={}

capabilities

Tool calling (XML format)
Reasoning control (reasoning_effort: none or minimal turns it off · low to max) · details
Multimodal (vision / images)
Streaming generation (SSE)

qwen3-embedding - 8B

vector embeddings

Vector embedding model. MMTEB score 70.58 — top-tier open models. Supports 100+ languages including Spanish and code.

Dimension: 4096
Precision: BF16 (GPU)
Max input: 32K tokens

use cases

Cross-lingual similarity (ES↔EN: 0.915)
Semantic search
Text classification
RAG / retrieval augmentation

rerank - Qwen3-Reranker-8B

semantic reranking

8B parameter reranking model (BF16). Reorders a list of documents by relevance to a query. Completes the RAG stack alongside qwen3-embedding: first retrieve top-K via embeddings, then rerank for precision. Supports 100+ languages including Spanish, code retrieval, and cross-lingual. Top-tier on MTEB reranking benchmarks.

Parameters: 8B
Precision: BF16
Endpoints: /v1/rerank · /v2/rerank
Languages: 100+

use cases

Reranking in RAG pipelines (embedding → rerank → LLM)
Cross-lingual search (ES↔EN, etc.)
Code retrieval
Query-document relevance scoring

kokoro - v1.0

text-to-speech

82M parameter TTS with 67 voice packs. Sub-second latency on GPU.

Latency: < 1s
Parameters: 82M

available voices

af_heart — English (female)
ef_dora — Spanish (female)
em_alex — Spanish (male)
67 voice packs total (see full list)

whisper - large-v3

speech-to-text

GPU STT with faster-whisper-large-v3 (Speaches, fp16 on CUDA). 99+ languages.

Size: ~4.3 GB (GPU VRAM, fp16)
WER ES: ~3.2%
Timeout: 180 s

capabilities

Audio-to-text transcription
99+ languages
Automatic language detection
OpenAI-compatible API

known limitations

File size limit — 25 MB: Maximum size per request. Compressed formats (OGG/Opus, MP3) make better use of this limit than uncompressed WAV.
Request timeout — 180 s: Transcription runs on GPU, much faster than realtime. Even so, very long audios can exceed the 180 s proxy limit — split long files into segments to avoid it.
Recommended formats: OGG/Opus and MP3 — smaller files, same transcription quality. A 60-minute audio in OGG/Opus at 48 kbps takes ~20 MB vs ~550 MB in WAV.

flux-2-klein

image generation

FLUX diffusion model for text-to-image and image-to-image. Compatible with OpenAI's Images API (/v1/images/generations and /v1/images/edits). Requires inference-tier membership.

Type: Diffusion (FLUX)
Modalities: text→image · image→image
Resolution: 256–1536 px (multiples of 16)
Images / request: 1–4 (n)
Monthly quota: 100 requests / member

capabilities

Text-to-image (/v1/images/generations)
Image-to-image with up to 4 references (/v1/images/edits)
Output as temporary URL (R2, ~60 min) or base64
Reproducibility via seed and guidance control

qwen-image-2.1

image generation

Qwen image model for text-to-image with strong prompt adherence and clean text rendering inside the image. Compatible with OpenAI's Images API (/v1/images/generations). Requires inference-tier membership.

Type: Diffusion (Qwen-Image)
Modalities: text→image
Resolution: 512–1280 px (multiples of 16)
Images / request: 1–4 (n)
Monthly quota: 100 requests / member (shared with flux-2-klein)

capabilities

Text-to-image (/v1/images/generations)
Output as temporary URL (R2, ~60 min) or base64
Reproducibility via seed (0–2147483647)

Controlling reasoning.

Every chat model above reasons before it answers. The four larger models added in November (kimi-k3.1-pro, qwen3.8-max, deepseek-v4-pro, hy4) are not in the table below yet: they take reasoning_effort like any other model, but how each level behaves on them is not part of this contract. 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:

API	Parameter
Chat Completions (`/v1/chat/completions`)	`reasoning_effort`
Responses (`/v1/responses`)	`reasoning: {"effort": ...}`

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

qwen3.8-max reasons before answering, and max_tokens only bounds the visible answer: the reasoning comes on top of it. To cap the total (reasoning plus answer, and so the cost) use max_completion_tokens; a small value can be spent entirely on reasoning, leaving an empty answer. To turn reasoning off, send reasoning_effort: "none". A reasoning budget (thinking_budget or thinking_token_budget) is not honoured on this model.

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. These aliases are not mapped on kimi-k3.1-pro and deepseek-v4-pro: on those two, use reasoning_effort. On hy4 they are mapped, and a request that names no level at all gets low.

Model	Off switch (`none`)	The other values
`deepseek-v4-flash`	Off. No reasoning tokens.	`minimal` to `max` steer how much it reasons. They are hints the model follows, not hard caps.
`qwen3.8-flash`	Off. No reasoning tokens.	Reasoning is on by default; `minimal` to `max` steer its depth (hints, not caps).
`mimo-v2.6-flash`	Off. No reasoning tokens.	`low`, `medium`, `high`, `max`. `minimal` is applied as `low` and `xhigh` as `max`.
`qwen3.6` · `gemma4`	Off. `minimal` turns it off too.	On Chat Completions they cap the reasoning phase: `low` 2,048, `medium` 8,192, `high` 16,384, `xhigh` and `max` 32,768 tokens. On Responses only on and off apply: any value but `none` or `minimal` reasons with the default 16,384-token budget.
`glm5.3` · `glm5.3-flash`	Not possible: GLM always reasons. `none` is applied as `minimal`, its shortest reasoning (a few tokens).	`minimal` to `max`; higher values reason longer before answering.

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. One exception: on qwen3.8-flash, max_tokens only bounds the visible answer, and the reasoning comes on top of it. To cap the total (reasoning plus answer, and so the cost) use max_completion_tokens; a small value can be spent entirely on reasoning, leaving an empty answer. To cap the reasoning exactly, use thinking_budget (see Capping reasoning with a token budget). The same holds for max_output_tokens on Responses.

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).

A stream carries no token counts unless you ask for them: add stream_options: {"include_usage": true} to a /v1/chat/completions request and the last chunk before [DONE] carries usage for the whole turn (prompt, completion and reasoning tokens). Without it the frames carry the answer only, and a client that needs to budget its credits has to count tokens itself. /v1/responses reports usage in its terminal event, no flag needed.

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 to your credits), 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

rate limits per API key

Requests / min: 60 rpm
Concurrent requests: per model — see the per-model limits below
Across all models: 7 (base plan) · 10 (premium plan) simultaneous requests per key

concurrent requests per model

Concurrency is enforced per model, not per API key.

glm5.3: 7 (base plan) · 10 (premium plan)
glm5.3-flash: 7 (base plan) · 10 (premium plan)
deepseek-v4-flash: 7 (base plan) · 10 (premium plan)
qwen3.8-flash: 7 (base plan) · 10 (premium plan)
mimo-v2.6-flash: 5
qwen3.6: 5
gemma4: 5

Audio, embedding and rerank endpoints have no concurrency limit.

glm5.3 · rolling window limits

Rolling 4h window: 400M tokens
Context window: 1M tokens
Concurrent requests: 7 (base plan) · 10 (premium plan)

400M tokens per rolling 4 hours is the limit a heavy coding-agent run reaches first. Once you hit it, glm5.3 requests are rejected until the window slides forward: it is a rolling window, not a daily reset. It is separate from your credits: credits pay for the tokens, the window bounds how fast you can spend them on glm5.3.

tokens / min per model

deepseek-v4-flash: 1.5M tpm
mimo-v2.6-flash: 1.5M tpm
qwen3.6: 1.5M tpm
gemma4: 1.5M tpm

requests / min per model

rerank: 1000 rpm