Qwen3-Max

Qwen3-Max

Over a trillion parameters, 36 trillion training tokens, and no reasoning pass.

The Window Is Split, and the Split Is Fixed

The most practically consequential specification on this page.

Output is capped at 32,768 regardless of how much input you send. Roughly one eighth of the window, and it does not move.

Why that matters more than the total. Most models in this catalogue quote one context figure and let you allocate it — a short prompt leaves room for a long answer. Here the two are separate budgets. Sending 10,000 tokens of input does not buy you a longer response than sending 250,000 does.

Two consequences for how you design around it.

Long-form generation has a hard ceiling. A task that needs 60,000 tokens of output cannot be done in one request on this model, however small the prompt.

Long-input tasks are well served. A quarter of a million tokens of documents, code, or conversation history, answered in a response of ordinary length, is exactly the shape this allocation suits.

It Answers Directly

No thinking mode. No effort parameter. No reasoning_content field to read or replay.

Two things follow, and both are advantages in the right context.

max_tokens means what it says. The ceiling covers the answer alone — nothing shares it, nothing gets consumed by a trace you did not ask for. On a model where thinking is the default, a budget of 2,048 can produce nothing at all; here it produces two thousand tokens of answer.

Latency depends on input and output length, not on how hard the model judged the question. For an interactive endpoint, that predictability is frequently worth more than depth.

A reasoning variant exists separately in the same family. If your workload needs deliberation, that is the model rather than a parameter on this one.

What It Was Built For

An independent assessment puts the trade plainly: not the most conversational or creative model, and among the strongest for factual and technical prompts.

Read that as a design statement rather than a criticism. The model is described as purpose-built for enterprise work, emphasising speed, structured outputs, and reliable tool use over conversational flourish.

Where that suits you. Extraction into a schema. Classification at volume. Technical question answering. Tool orchestration. Code generation from a specification. Work where a correct, plainly stated answer beats an engaging one.

Where it does not. Creative writing, conversational products where personality is the feature, and anything judged on how it reads rather than on whether it is right.

Benchmark Results

Published for the preview release; the official version further improved coding and agent capabilities.

The preview ranked third on the Text Arena leaderboard — a human-preference ranking rather than an automated benchmark, which measures something the others do not.

Read AIME at 80.6 with the model's design in mind. That is a strong competition-mathematics result for a model with no reasoning pass at all. The reasoning variant in this family reaches considerably higher on the same benchmark, and it takes a reasoning pass to get there.

LiveBench at 45.8 is the one to weigh if you are comparing tiers. It is designed to resist contamination by using recently published questions, which makes it harder to score well on for reasons unrelated to capability.

Specifications

Internals are not disclosed. Parameter count and training scale are published; architecture details are not, and the model is proprietary with no downloadable weights.

Capabilities

Context Caching

A named efficiency feature, and it changes the economics of multi-turn work.

Cached context is not reprocessed on subsequent turns. A long document, a large system prompt, or an accumulated conversation stays available without being paid for repeatedly.

Where it pays off most: a long reference document queried many times, a substantial system prompt applied across many requests, and extended multi-turn sessions where history dominates the input.

Order your request to make the cacheable prefix as long as possible. Stable material first — system instructions, reference documents, schemas — with variable content after it. A prompt that interleaves fixed and changing material gets less from caching than one that separates them.

Using Qwen3-Max on DEVUP AI

Base URL: https://api.devupai.com/v1 · Model ID: Qwen/Qwen3-Max

Python

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEVUP_API_KEY"],
    base_url="https://api.devupai.com/v1",
)

response = client.chat.completions.create(
    model="Qwen/Qwen3-Max",
    messages=[
        {"role": "user", "content": "Hello world!"}
    ],
    max_tokens=1024,
)

print(response.choices[0].message.content)

Node.js

import DevupAI from "devupai";

const client = new DevupAI({
  apiKey: process.env.DEVUP_API_KEY,
});

async function main() {
  const response = await client.chat.completions.create({
    model: "Qwen/Qwen3-Max",
    messages: [{ role: "user", content: "Hello world!" }],
    max_tokens: 1024,
  });

  console.log(response.choices[0].message.content);
}

main();

cURL

curl -X POST "https://api.devupai.com/v1/chat/completions" \
  -H "Authorization: Bearer $DEVUP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-Max",
    "messages": [
      { "role": "user", "content": "Hello world!" }
    ],
    "max_tokens": 1024
  }'

Structured Extraction

Where the model's stated design lands — structured output over conversational output.

import json

SCHEMA = {
    "type": "json_schema",
    "json_schema": {
        "name": "contract_terms",
        "strict": True,
        "schema": {
            "type": "object",
            "properties": {
                "party_a": {"type": ["string", "null"]},
                "party_b": {"type": ["string", "null"]},
                "effective_date": {"type": ["string", "null"]},
                "termination_notice_days": {"type": ["integer", "null"]},
                "governing_law": {"type": ["string", "null"]},
                "auto_renews": {"type": ["boolean", "null"]},
            },
            "required": [
                "party_a", "party_b", "effective_date",
                "termination_notice_days", "governing_law", "auto_renews",
            ],
            "additionalProperties": False,
        },
    },
}


def extract_terms(contract: str) -> dict:
    """Pull typed fields from a contract, returning null for anything absent."""
    response = client.chat.completions.create(
        model="Qwen/Qwen3-Max",
        messages=[
            {
                "role": "system",
                "content": (
                    "Extract only what the document states. Use null for anything it does not "
                    "address — never infer a value from context or convention."
                ),
            },
            {"role": "user", "content": contract},
        ],
        response_format=SCHEMA,
        max_tokens=2048,
        temperature=0,
    )
    return json.loads(response.choices[0].message.content)

Every field nullable, and an explicit instruction against inference. A schema forbidding null invites the model to supply a plausible value where the document is silent — and on an extraction pipeline, that error is invisible until someone acts on it.

temperature=0 because extraction has one correct answer. Variance is noise you pay for and then have to reconcile.

Working Inside the Output Ceiling

The constraint that shapes long-form work on this model.

from pathlib import Path

SECTIONS = ["introduction", "architecture", "deployment", "operations", "appendix"]


def write_section(name: str, brief: str, context: str) -> str:
    """Generate one section, staying well inside the 32,768-token output ceiling."""
    response = client.chat.completions.create(
        model="Qwen/Qwen3-Max",
        messages=[
            {
                "role": "system",
                "content": (
                    "You are writing one section of a technical document. Write only the section "
                    "requested. Do not summarise other sections or add a conclusion."
                ),
            },
            {"role": "user", "content": f"Reference material:\n\n{context}\n\nWrite the '{name}' section.\n\n{brief}"},
        ],
        max_tokens=8192,
        temperature=0.3,
    )

    if response.choices[0].finish_reason == "length":
        raise ValueError(f"section '{name}' hit the output ceiling — narrow the brief")

    return response.choices[0].message.content


document = "\n\n".join(write_section(name, BRIEFS[name], REFERENCE) for name in SECTIONS)
Path("document.md").write_text(document, encoding="utf-8")

The reference material goes in every request — and with 258,048 tokens of input available, that is comfortable. The output ceiling is what forces the section-by-section approach, not the input one.

Checking finish_reason is not optional here. A response truncated at the ceiling is a section that stops mid-sentence, and it looks like a short section until someone reads it.

Tool Orchestration

Named as a design strength, and worth configuring accordingly.

import json

TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "query_database",
            "description": "Run a read-only SQL query and return rows as JSON.",
            "parameters": {
                "type": "object",
                "properties": {"sql": {"type": "string"}},
                "required": ["sql"],
            },
        },
    },
]


def query_database(sql: str) -> dict:
    """Replace with your real, read-only data layer."""
    raise NotImplementedError


HANDLERS = {"query_database": query_database}

thread = [{"role": "user", "content": "Which product categories lost margin last quarter, and is the cause price or volume?"}]

CEILING = 20

for step in range(CEILING):
    response = client.chat.completions.create(
        model="Qwen/Qwen3-Max",
        messages=thread,
        tools=TOOLS,
        max_tokens=8192,
    )

    message = response.choices[0].message
    thread.append(message)

    if not message.tool_calls:
        print(message.content)
        break

    for call in message.tool_calls:
        handler = HANDLERS.get(call.function.name)
        if handler is None:
            outcome = {"error": "unknown tool", "name": call.function.name}
        else:
            try:
                outcome = handler(**json.loads(call.function.arguments or "{}"))
            except Exception as exc:
                outcome = {"error": type(exc).__name__, "detail": str(exc)}

        thread.append({"role": "tool", "tool_call_id": call.id, "content": json.dumps(outcome)})
else:
    print(f"Stopped at the {CEILING}-step ceiling.")

With no reasoning pass, each turn is fast — which is what makes a twenty-step loop practical in wall-clock terms. The trade is that each step is a direct decision rather than a deliberated one, so keep tool descriptions precise. The model follows a clear specification well and infers less than a reasoning model would.

Where It Fits

Long-input, ordinary-output work — document analysis, code review, corpus questions. The 258K input ceiling is generous and the 32K output ceiling is rarely the constraint here.

Structured extraction at volume, where schema adherence and speed matter more than depth.

Technical and factual question answering, which independent assessment names as its strength.

Tool orchestration, with reliability named as a design priority.

Interactive endpoints, where no reasoning pass means predictable latency.

Multi-turn sessions, using context caching to avoid reprocessing history.

Not for long-form generation. 32,768 tokens of output is a hard ceiling; longer work needs chunking.

Not for deep reasoning. The reasoning variant in this family exists for that.

Not for creative or conversational products, by its own design.

Not for vision. Text only.

Practical Notes

Budget input and output separately — they are separate ceilings, not one pool.

Check finish_reason on generation tasks. 32,768 is reached sooner than you expect on long-form work.

Use temperature=0 for extraction and classification.

Order prompts so the cacheable prefix is as long as possible.

Make every extraction field nullable and forbid inference explicitly.

Route deliberation-heavy work to the reasoning variant rather than prompting harder here.

Write precise tool descriptions — a direct-answering model infers less than a reasoning one.

Limitations

32,768-token output ceiling, fixed and independent of input length. The binding constraint on long-form generation.

No reasoning capability. Multi-step logic and hard analysis belong on the reasoning variant in this family.

Text only. No image, audio, or video input, and no image generation.

Closed weights. API access only, with no self-hosted option and no published architecture.

Not built for creative or conversational work, which is a design choice rather than a shortfall.

Benchmark figures are from the preview release. The official version improved coding and agent capability; published numbers may understate it.

Answers arrive confidently with no visible reasoning. There is less signal about where the model was uncertain — ground factual work and require citations where correctness matters.