Overview: Qwen2.5-based reasoning
QwQ-Plus is the enhanced QwQ reasoning model built on Qwen2.5. Qwen describes reinforcement learning as the method used to strengthen its reasoning, particularly in mathematics and programming, together with general instruction-following tasks. It receives text and returns text. Select it when the work calls for an explained solution, comparison or code proposal that can be checked against the supplied conditions.
This is the QwQ-Plus model line. Its name does not establish the parameter count or weight identity of an open QwQ checkpoint, and a supplier name containing latest should not silently become a fixed dated revision. Use the exact requested model identity when comparing outputs or keeping a reproducible record of a task.
Preparing mathematical and logical work
Give the complete problem statement, definitions, units and allowed assumptions. Ask for the final answer in a clearly delimited form, then request the equations or logical steps needed to support it. For a constrained planning problem, specify the feasible choices and evaluation criteria separately, and request a table showing which conditions each choice satisfies. For an educational review, include the learner’s attempted solution and ask the model to identify the first unsupported step rather than rewrite the entire exercise without explanation.
These are practical applications of the model’s documented reasoning focus. The useful artifact is a checkable result: a value with units, a conclusion with premises, or a comparison tied to the stated criteria. More explanatory text does not by itself establish a correct conclusion, so keep assumptions visible and compare the final result with the original question.
Preparing programming work
Provide the relevant code, the input that exposes the problem, the observed output and the desired behavior. Ask for a proposed change, an explanation of why it addresses that input, and edge cases that still need checking. For an algorithm question, specify the input constraints and required output before asking for an approach. Distinguish generated code from code that has actually been executed in the application’s environment.
A useful response can separate the diagnosis, patch and expected behavior. When a small change is required, request a compact patch rather than a rewritten project. These examples are authored ways to apply QwQ-Plus’s mathematical and coding specialization; they are not an extra tool or execution capability.
Context and answer limits
The exact model specification gives a 131,072-token context window, a maximum input of 98,304 tokens and a maximum output of 8,192 tokens. These are separate producer limits. Do not turn the arithmetic difference between them into an undocumented guaranteed reasoning allowance. Source text, conversation history and the response must remain within the applicable configured bounds.
For a long specification or code excerpt, retain relevant section and function identifiers and ask the model to reference them in its explanation. Remove unrelated material before submission and reserve enough output space for the required conclusion. A large context window is useful for supplying more conditions together; it does not promise that every fact will be recalled or every dependency understood.
Tools, formatting and model-specific boundaries
The manufacturer’s deployment matrix lists function calling and web search in some configurations and marks them unsupported in another. They are therefore conditional capabilities, not features that can be promised from the model name alone. The same matrix supports batch inference in some manufacturer configurations. A tool-assisted workflow must provide the actual tools and feed their results back into the text task. This description does not establish an application’s tool availability.
Enforced structured outputs are marked unsupported. A prompt can still request a table or a JSON-shaped answer, but the application must inspect the result rather than treat that request as schema enforcement. The exact model page describes a reasoning specialization without supplying a per-model hybrid thinking-switch contract; controls documented for newer Qwen generations should not be imported into this edition.
Keep the final answer easy to review, check calculations against the stated units and inspect code proposals before execution. QwQ-Plus’s practical role is to work through a difficult text problem and return a useful explanation or artifact within its own documented limits.
", "aboutText": "Overview: Qwen2.5-based reasoning\n\nQwQ-Plus is the enhanced QwQ reasoning model built on Qwen2.5. Qwen describes reinforcement learning as the method used to strengthen its reasoning, particularly in mathematics and programming, together with general instruction-following tasks. It receives text and returns text. Select it when the work calls for an explained solution, comparison or code proposal that can be checked against the supplied conditions.\n\nThis is the QwQ-Plus model line. Its name does not establish the parameter count or weight identity of an open QwQ checkpoint, and a supplier name containing latest should not silently become a fixed dated revision. Use the exact requested model identity when comparing outputs or keeping a reproducible record of a task.\n\nPreparing mathematical and logical work\n\nGive the complete problem statement, definitions, units and allowed assumptions. Ask for the final answer in a clearly delimited form, then request the equations or logical steps needed to support it. For a constrained planning problem, specify the feasible choices and evaluation criteria separately, and request a table showing which conditions each choice satisfies. For an educational review, include the learner’s attempted solution and ask the model to identify the first unsupported step rather than rewrite the entire exercise without explanation.\n\nThese are practical applications of the model’s documented reasoning focus. The useful artifact is a checkable result: a value with units, a conclusion with premises, or a comparison tied to the stated criteria. More explanatory text does not by itself establish a correct conclusion, so keep assumptions visible and compare the final result with the original question.\n\nPreparing programming work\n\nProvide the relevant code, the input that exposes the problem, the observed output and the desired behavior. Ask for a proposed change, an explanation of why it addresses that input, and edge cases that still need checking. For an algorithm question, specify the input constraints and required output before asking for an approach. Distinguish generated code from code that has actually been executed in the application’s environment.\n\nA useful response can separate the diagnosis, patch and expected behavior. When a small change is required, request a compact patch rather than a rewritten project. These examples are authored ways to apply QwQ-Plus’s mathematical and coding specialization; they are not an extra tool or execution capability.\n\nContext and answer limits\n\nThe exact model specification gives a 131,072-token context window, a maximum input of 98,304 tokens and a maximum output of 8,192 tokens. These are separate producer limits. Do not turn the arithmetic difference between them into an undocumented guaranteed reasoning allowance. Source text, conversation history and the response must remain within the applicable configured bounds.\n\nFor a long specification or code excerpt, retain relevant section and function identifiers and ask the model to reference them in its explanation. Remove unrelated material before submission and reserve enough output space for the required conclusion. A large context window is useful for supplying more conditions together; it does not promise that every fact will be recalled or every dependency understood.\n\nTools, formatting and model-specific boundaries\n\nThe manufacturer’s deployment matrix lists function calling and web search in some configurations and marks them unsupported in another. They are therefore conditional capabilities, not features that can be promised from the model name alone. The same matrix supports batch inference in some manufacturer configurations. A tool-assisted workflow must provide the actual tools and feed their results back into the text task. This description does not establish an application’s tool availability.\n\nEnforced structured outputs are marked unsupported. A prompt can still request a table or a JSON-shaped answer, but the application must inspect the result rather than treat that request as schema enforcement. The exact model page describes a reasoning specialization without supplying a per-model hybrid thinking-switch contract; controls documented for newer Qwen generations should not be imported into this edition.\n\nKeep the final answer easy to review, check calculations against the stated units and inspect code proposals before execution. QwQ-Plus’s practical role is to work through a difficult text problem and return a useful explanation or artifact within its own documented limits.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
Review a learner calculation\n\nReview this learner solution: "A 30 percent discount on 80 gives 80 - 30 = 50." Identify the first incorrect step, explain the correct percentage operation and calculate the final price. Give a short check by adding the discount back to the sale price. Use only these numbers and no tax assumption.A concise correction identifying the unsupported subtraction, the calculation and a labelled final price.Verify the discount is 30 percent of 80 and the price plus discount returns 80.qwq-plusQwQ-Plus is Qwen’s Qwen2.5-based reasoning model, strengthened through reinforcement learning for mathematical, coding and logical text tasks. Its dedicated specification lists a 131,072-token context, 98,304-token maximum input and 8,192-token maximum output.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Overview: Qwen2.5-based reasoning
QwQ-Plus is the enhanced QwQ reasoning model built on Qwen2.5. Qwen describes reinforcement learning as the method used to strengthen its reasoning, particularly in mathematics and programming, together with general instruction-following tasks. It receives text and returns text. Select it when the work calls for an explained solution, comparison or code proposal that can be checked against the supplied conditions.
This is the QwQ-Plus model line. Its name does not establish the parameter count or weight identity of an open QwQ checkpoint, and a supplier name containing latest should not silently become a fixed dated revision. Use the exact requested model identity when comparing outputs or keeping a reproducible record of a task.
Preparing mathematical and logical work
Give the complete problem statement, definitions, units and allowed assumptions. Ask for the final answer in a clearly delimited form, then request the equations or logical steps needed to support it. For a constrained planning problem, specify the feasible choices and evaluation criteria separately, and request a table showing which conditions each choice satisfies. For an educational review, include the learner’s attempted solution and ask the model to identify the first unsupported step rather than rewrite the entire exercise without explanation.
These are practical applications of the model’s documented reasoning focus. The useful artifact is a checkable result: a value with units, a conclusion with premises, or a comparison tied to the stated criteria. More explanatory text does not by itself establish a correct conclusion, so keep assumptions visible and compare the final result with the original question.
Preparing programming work
Provide the relevant code, the input that exposes the problem, the observed output and the desired behavior. Ask for a proposed change, an explanation of why it addresses that input, and edge cases that still need checking. For an algorithm question, specify the input constraints and required output before asking for an approach. Distinguish generated code from code that has actually been executed in the application’s environment.
A useful response can separate the diagnosis, patch and expected behavior. When a small change is required, request a compact patch rather than a rewritten project. These examples are authored ways to apply QwQ-Plus’s mathematical and coding specialization; they are not an extra tool or execution capability.
Context and answer limits
The exact model specification gives a 131,072-token context window, a maximum input of 98,304 tokens and a maximum output of 8,192 tokens. These are separate producer limits. Do not turn the arithmetic difference between them into an undocumented guaranteed reasoning allowance. Source text, conversation history and the response must remain within the applicable configured bounds.
For a long specification or code excerpt, retain relevant section and function identifiers and ask the model to reference them in its explanation. Remove unrelated material before submission and reserve enough output space for the required conclusion. A large context window is useful for supplying more conditions together; it does not promise that every fact will be recalled or every dependency understood.
Tools, formatting and model-specific boundaries
The manufacturer’s deployment matrix lists function calling and web search in some configurations and marks them unsupported in another. They are therefore conditional capabilities, not features that can be promised from the model name alone. The same matrix supports batch inference in some manufacturer configurations. A tool-assisted workflow must provide the actual tools and feed their results back into the text task. This description does not establish an application’s tool availability.
Enforced structured outputs are marked unsupported. A prompt can still request a table or a JSON-shaped answer, but the application must inspect the result rather than treat that request as schema enforcement. The exact model page describes a reasoning specialization without supplying a per-model hybrid thinking-switch contract; controls documented for newer Qwen generations should not be imported into this edition.
Keep the final answer easy to review, check calculations against the stated units and inspect code proposals before execution. QwQ-Plus’s practical role is to work through a difficult text problem and return a useful explanation or artifact within its own documented limits.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits qwq-plus | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits Minimum items: 1 | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits Examples: system, user, assistant, tool, function Conditions: These roles are explicitly represented by Source compatibility types; the exact model role set remains model-specific. Model-specific | Default— |
Fieldmessages[].content | Typestring|content_part[]|null | RequirementOptional | Values & limits | Default— |
Fieldmessages[].tool_calls | Typetool_call[] | RequirementOptional | Values & limits | Default— |
Fieldmessages[].tool_call_id | Typestring | RequirementOptional | Values & limits Applies when: role=tool; use actual returned ID | Default— |
Fieldmessages[].name | Typestring | RequirementOptional | Values & limits | Default— |
Fieldmessages[].reasoning_content | Typestring | RequirementOptional | Values & limits Applies when: Round-trip actual returned reasoning where this model uses it | Default— |
Fieldmessages[].reasoning_details | Typeobject|array | RequirementOptional | Values & limits Model-specific | Default— |
Fieldmax_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Model-specific | Default— |
Fieldmax_completion_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Model-specific | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
Fieldstream_options.include_usage | Typeboolean | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtemperature | Typenumber | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtop_p | Typenumber | RequirementOptional | Values & limits Model-specific | Default— |
Fieldstop | Typestring|string[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtools | Typefunction_tool[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtools[].type | Typestring | RequirementOptional | Values & limits function Model-specific | Default— |
Fieldtools[].function.name | Typestring | RequirementRequired | Values & limits Applies when: function tool supplied | Default— |
Fieldtools[].function.description | Typestring | RequirementOptional | Values & limits | Default— |
Fieldtools[].function.parameters | TypeJSON_schema | RequirementOptional | Values & limits | Default— |
Fieldtool_choice | Typestring|object | RequirementOptional | Values & limits Model-specific | Default— |
Fieldparallel_tool_calls | Typeboolean | RequirementOptional | Values & limits Model-specific | Default— |
Fieldresponse_format | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldreasoning_effort | Typestring | RequirementOptional | Values & limits Model-specific | Default— |
Fieldreasoning | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldservice_tier | Typestring | RequirementOptional | Values & limits Model-specific | Default— |
Fieldinstructions | Typestring | RequirementOptional | Values & limits Compatibility field | Default— |
Fieldfunctions | Typefunction[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldfunction_call | Typestring|object | RequirementOptional | Values & limits Model-specific | Default— |
Fieldprompt_cache_options | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldmodalities | Typestring[] | RequirementOptional | Values & limits text | Default— |
Fieldprovider | Typeobject | RequirementOptional | Values & limits Conditions: provider.options is rejected on this Ultra text route | Default— |
Fieldcache_control.ttl | Typestring | RequirementOptional | Values & limits Conditions: 1h is rejected in actual prompt-cache locations | Default— |
Text · UTF8 text
messages[].content
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages |
Parametermaterial_types | Contracttext |
Parametermessages | Contractmessage array with role/content shape |
Parameterfile_material | Contractactual UTF-8 document inserted as literal text; no file ID inferred |
Parameteroptional_controls | Contractstream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parametercontrol_scope | Contractmodel-specific; user function tools differ from hosted tools |
Parameteroutput_modalities | Contracttext |
Parameterhosted_operations | Contractfalse |
Parametermultimodal_input_binding | Contractnull |
Lifecycle: synchronous_or_streamed
Send exact model ID with messages.
Context length is not an output cap.
A text file may supply literal text; image/audio/file-object inputs need exact binding.
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0.00046 / 1K tokens Output · Output tokens $0.00116 / 1K tokens Input · Cache read $0 / 1K tokens Input · Cache write $0 / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "qwq-plus", "messages": [{"role": "user", "content": "Explain the difference between an observation and a hypothesis in three sentences."}]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model='qwq-plus',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}])\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\nfrom openai import OpenAI\nimport os\nfrom pathlib import Path\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nwith client.chat.completions.stream(model='qwq-plus',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}]) as stream:\n with Path("stream-events.jsonl").open("w",encoding="utf-8") as log:\n for event in stream:\n payload=event.to_dict(mode="json")\n log.write(json.dumps(payload,ensure_ascii=False)+"\\n"); log.flush()\n print(json.dumps(payload,ensure_ascii=False))\n final=stream.get_final_completion()\n save_result(final.to_dict(mode="json"),"stream-result")\njson or SSE
Keep every complete returned response, file and content part.
Keep every choice and its content/tool calls/reasoning. In SSE assemble deltas by choice/tool index, retain the final finish reason and usage.
Keep request/response IDs and headers. No generic text job retrieval URL is supplied.
| Field | Type |
|---|---|
Fieldchoices[].index | Typeinteger |
Fieldchoices[].message.content | Typestring|null |
Fieldchoices[].message.tool_calls | Typetool_call[] |
Fieldchoices[].message.reasoning_content | Typestring |
Fieldchoices[].message.reasoning_details | Typeobject|array |
Fieldchoices[].finish_reason | Typestring|null |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra qwq-plus
Use the method paths shown above.
qwq-plusQwQ-Plus is Qwen’s Qwen2.5-based reasoning model, strengthened through reinforcement learning for mathematical, coding and logical text tasks. Its dedicated specification lists a 131,072-token context, 98,304-token maximum input and 8,192-token maximum output.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Overview: Qwen2.5-based reasoning
QwQ-Plus is the enhanced QwQ reasoning model built on Qwen2.5. Qwen describes reinforcement learning as the method used to strengthen its reasoning, particularly in mathematics and programming, together with general instruction-following tasks. It receives text and returns text. Select it when the work calls for an explained solution, comparison or code proposal that can be checked against the supplied conditions.
This is the QwQ-Plus model line. Its name does not establish the parameter count or weight identity of an open QwQ checkpoint, and a supplier name containing latest should not silently become a fixed dated revision. Use the exact requested model identity when comparing outputs or keeping a reproducible record of a task.
Preparing mathematical and logical work
Give the complete problem statement, definitions, units and allowed assumptions. Ask for the final answer in a clearly delimited form, then request the equations or logical steps needed to support it. For a constrained planning problem, specify the feasible choices and evaluation criteria separately, and request a table showing which conditions each choice satisfies. For an educational review, include the learner’s attempted solution and ask the model to identify the first unsupported step rather than rewrite the entire exercise without explanation.
These are practical applications of the model’s documented reasoning focus. The useful artifact is a checkable result: a value with units, a conclusion with premises, or a comparison tied to the stated criteria. More explanatory text does not by itself establish a correct conclusion, so keep assumptions visible and compare the final result with the original question.
Preparing programming work
Provide the relevant code, the input that exposes the problem, the observed output and the desired behavior. Ask for a proposed change, an explanation of why it addresses that input, and edge cases that still need checking. For an algorithm question, specify the input constraints and required output before asking for an approach. Distinguish generated code from code that has actually been executed in the application’s environment.
A useful response can separate the diagnosis, patch and expected behavior. When a small change is required, request a compact patch rather than a rewritten project. These examples are authored ways to apply QwQ-Plus’s mathematical and coding specialization; they are not an extra tool or execution capability.
Context and answer limits
The exact model specification gives a 131,072-token context window, a maximum input of 98,304 tokens and a maximum output of 8,192 tokens. These are separate producer limits. Do not turn the arithmetic difference between them into an undocumented guaranteed reasoning allowance. Source text, conversation history and the response must remain within the applicable configured bounds.
For a long specification or code excerpt, retain relevant section and function identifiers and ask the model to reference them in its explanation. Remove unrelated material before submission and reserve enough output space for the required conclusion. A large context window is useful for supplying more conditions together; it does not promise that every fact will be recalled or every dependency understood.
Tools, formatting and model-specific boundaries
The manufacturer’s deployment matrix lists function calling and web search in some configurations and marks them unsupported in another. They are therefore conditional capabilities, not features that can be promised from the model name alone. The same matrix supports batch inference in some manufacturer configurations. A tool-assisted workflow must provide the actual tools and feed their results back into the text task. This description does not establish an application’s tool availability.
Enforced structured outputs are marked unsupported. A prompt can still request a table or a JSON-shaped answer, but the application must inspect the result rather than treat that request as schema enforcement. The exact model page describes a reasoning specialization without supplying a per-model hybrid thinking-switch contract; controls documented for newer Qwen generations should not be imported into this edition.
Keep the final answer easy to review, check calculations against the stated units and inspect code proposals before execution. QwQ-Plus’s practical role is to work through a difficult text problem and return a useful explanation or artifact within its own documented limits.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits qwq-plus | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits user, assistant | Default— |
Fieldmessages[].content | Typestring | RequirementRequired | Values & limits | Default— |
Fieldmax_tokens | Typeinteger | RequirementRequired | Values & limits | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
Text · UTF-8 text
messages[].content string
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages, max_tokens |
Parameteroptional_controls | Contractstream |
Parametermaterial_types | Contracttext |
Parametertext_file_material | ContractRead the actual UTF-8 document and put its text in the indicated input or message content string. |
Lifecycle: synchronous_or_streamed
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0.00046 / 1K tokens Output · Output tokens $0.00116 / 1K tokens Input · Cache read $0 / 1K tokens Input · Cache write $0 / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
{\n "model": "qwq-plus",\n "max_tokens": 128,\n "messages": [\n {\n "role": "user",\n "content": "Summarize the incident report."\n }\n ],\n "stream": false\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 document}"\nexport AILOOT_TEXT_FILE\npython3 - <<'PY_REQUEST'\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'qwq-plus', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nPath('request.json').write_text(json.dumps(payload, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "x-api-key: $AILOOT_API_KEY" -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nPY_RESULT\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'qwq-plus', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nfrom urllib.request import Request, urlopen\nfrom urllib.error import HTTPError\n\napi_key = os.environ['AILOOT_API_KEY']\nif not api_key.strip():\n raise SystemExit('Set AILOOT_API_KEY before making a request')\nheaders = {'x-api-key': 'PLACEHOLDER_KEY', 'anthropic-version': '2023-06-01', 'Content-Type': 'application/json'}\nheaders['x-api-key'] = api_key\nrequest = Request('https://api.ailoot.ai/v1/messages', data=json.dumps(payload, ensure_ascii=False).encode('utf-8'), headers=headers, method='POST')\ntry:\n with urlopen(request, timeout=120) as response:\n raw = response.read()\n Path('response-headers.txt').write_text(str(response.headers), encoding='utf-8')\nexcept HTTPError as error:\n Path('result.json').write_bytes(error.read())\n Path('response-headers.txt').write_text(str(error.headers), encoding='utf-8')\n raise\nPath('result.json').write_bytes(raw)\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nJSON or SSE
Keep every complete returned response, file and content part.
Keep all content blocks, thinking signatures and actual tool-use IDs. Assemble all SSE block deltas; a first text block is not the complete output.
Keep request/response IDs and headers. No generic text job retrieval URL is supplied.
| Field | Type |
|---|---|
Fieldid | Typestring |
Fieldmodel | Typestring |
Fieldcontent[] | Typetext|thinking|tool_use|other content block |
Fieldstop_reason | Typestring|null |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra qwq-plus
Use the method paths shown above.
Technical example in English
Review a learner calculation\n\nReview this learner solution: "A 30 percent discount on 80 gives 80 - 30 = 50." Identify the first incorrect step, explain the correct percentage operation and calculate the final price. Give a short check by adding the discount back to the sale price. Use only these numbers and no tax assumption.A concise correction identifying the unsupported subtraction, the calculation and a labelled final price.Verify the discount is 30 percent of 80 and the price plus discount returns 80.