Qwen3.6-35B-A3B: the open agentic-coding MoE as an API
Qwen3.6-35B-A3B is a sparse mixture-of-experts model from Alibaba's Qwen team: 35 billion parameters in total, about 3 billion active per token, built for agentic coding and released as open weights in April 2026 under Apache 2.0. This platform serves it over an OpenAI-compatible chat endpoint under the alias qwen3.6-35b, metered per token from a prepaid wallet.
Last verified: 2026-09-11
What it is
The official model card describes the first open-weight release of the Qwen3.6 generation, following the Qwen3.5 series. Two upgrades name the release: agentic coding (frontend workflows and repository-level reasoning) and thinking preservation, an option to keep reasoning context from earlier turns so iterative work does not restart cold each request. The release post positions it against much larger dense models, and the benchmark tables below show what that means in numbers.
The identity facts that matter for planning:
| Fact | Value | Where the number comes from |
|---|---|---|
| Parameters | 35B total, about 3B active per token | model card |
| Architecture | sparse MoE, 256 experts, 8 routed + 1 shared | model card |
| Attention | hybrid: Gated DeltaNet linear attention, full attention every fourth layer | model card |
| Vision | text and image input (video in the card's quickstart) | model card |
| License | Apache 2.0 | model card |
| Native context window | 262,144 tokens, extensible to about 1,010,000 with YaRN | model card |
| Served window on this route | 131,072 tokens | platform serving registry |
| Thinking control | reasoning_effort: minimal, low, medium, high | platform contract |
| First-party API name | qwen3.6-flash on Alibaba Cloud Model Studio | release post |
Three behaviors decide how you build against this model.
It computes like a 3B model and occupies memory like a 35B one. The sparse design activates 8 of 256 experts per step, so the compute cost of a token looks like a 3B model while the quality looks like a much larger one. The memory cost is different: all 35B parameters sit in memory whether active or not, which is why self-hosting this model is a 24 GB-class decision even though using it is 3B-class work. That asymmetry is the whole product story of this model class, and it is why a hosted per-token route and a local install both make sense for different readers.
It is a thinking model with a dial. Requests can run in thinking mode (the model works through the problem before answering) or not, and the effort level is a per-request choice at this endpoint. When thinking runs, the reasoning arrives in a separate reasoning_content field next to the answer content, so your application can log it, show it, or discard it. The card's own best-practices section recommends different sampling settings per mode: temperature 0.6 with top_p 0.95 for precise coding in thinking mode, 1.0 for general thinking-mode work, 0.7 with top_p 0.80 in non-thinking mode. All of those can be sent explicitly; the endpoint accepts the standard sampling controls.
The context numbers deserve their own paragraph because pages conflict on them. The model's native window is 262,144 tokens per the card, and the card documents YaRN scaling to roughly one million for self-hosters who need it, with its own caveat that static scaling can slightly reduce quality on ordinary-length inputs. On this platform the served window is 131,072 tokens. That number is not marketing rounding: the serving registry sets it from a dated probe (2026-08-20) in which 130,048-token prompts fit and 139,264-token prompts were rejected, with the failover leg spot-checked at 130,044. It is the honest number for capacity planning here. Notably, the publisher's own first-party API config example in the release post also runs a 131,072 window.
One naming note so nothing surprises you at the keyboard. The public name is Qwen3.6-35B-A3B (the A3B marks the active-parameter count). The id you send this endpoint is the machine alias qwen3.6-35b, without the suffix. The publisher's own hosted API sells the same weights under a third name, qwen3.6-flash. Three names, one model; the code tabs below use the alias.
Use cases
The model's profile, a fast-decoding long-context MoE with vision input and a thinking dial, points at specific jobs.
- Agentic coding backends. This is what the release is named for. The model handles frontend workflows and repository-level reasoning, emits OpenAI-style tool calls, and preserves thinking context across turns for iterative work. Agent loops that read a repo, plan, and edit files are the center of the target.
- Long-context reading over big inputs. With a served window of 131,072 tokens, whole repositories, long logs, and document sets fit in one request. Both this model and its dense 27B sibling use the same hybrid attention and give full attention the same one-layer-in-four share, but the counts differ: 10 full-attention layers here against 16 in the dense model, so the cache portion that grows with context is larger there. Local runners report this model holding long contexts on hardware where the dense sibling needs a smaller quant to fit.
- Vision-input workflows. Screenshots, diagrams, UI captures, scanned figures: the model reads images alongside text, and image content arrays forward through this endpoint to the same vision encoder the card documents.
- High-volume generation where 3B-active quality is enough. Drafting, classification, extraction, chat backends: jobs where the quality bar is met by this class and the winning properties are decode speed and a per-token meter.
- Local-to-hosted portability. The request shape is the same OpenAI-compatible chat format you would send to a local vLLM or llama.cpp server. Teams prototype locally, then point the client at the metered route: a new base URL and model id and nothing else.
Run it locally or call the API
Apache 2.0 means the local road is fully open, and for some teams it is the right one. The official local routes: the Ollama library build (a 23 GB package at Q4_K_M, one command to run, with MTP speculative decoding enabled by default), the GGUF ecosystem behind llama.cpp, and the vLLM recipe for full-precision or FP8 serving (a single H100 or H200 at FP8; BF16 wants an H200 or two H100s).
The decision rule, stated plainly:
Run it locally when a machine is already there, when traffic is steady enough to keep the GPU warm, when you need the weights inside a boundary you control, or when you want to fine-tune. The 24 GB card class is the practical entry point; the 8-bit class needs about 37 GB.
Call the API when you want the model without the operations: no quantization menu, no runtime pins, no idle hardware, and a metered bill instead. The hosted route adds what a local server does not ship: metered per-token billing tied to the prepaid wallet, independent key revocation, and a served window backed by a dated measurement rather than a spec sheet.
API usage
The route is POST /v1/chat/completions with a Bearer key from the console, in the OpenAI-compatible shape your client already speaks. The model id is qwen3.6-35b.
POST /v1/chat/completions
Authorization: Bearer <your key>
Content-Type: application/json
Four rules of this endpoint that save debugging time:
reasoning_effortis the thinking control. Accepted values areminimal,low,medium, andhigh.minimalturns thinking off; the other three run it. The model's upstream hosts carry this switch under their ownenable_thinkingspelling, and the platform performs that mapping on the way out, so you never write it yourself. Sendreasoning_effortand nothing else for thinking control: the parser rejects unknown parameters with a 400, including a hand-rolledenable_thinkingor a nested template-kwargs object, so a wrong knob fails loudly at the door instead of silently upstream.- Unknown parameters are rejected. The accepted set includes the OpenAI-compatible core:
messages,stream,max_tokensandmax_completion_tokens, the sampling controls (temperature,top_p,top_k,min_p, penalties),stop,seed,n,tools,tool_choice,response_format,reasoning_effort,stream_options, along with the logprob, metadata, and parallel-tool-call options. Keys outside the accepted set return a parameter error rather than being ignored. - Metering counts what the model actually moves. The three metered legs each carry their own registry rate, and the pricing page renders all three. Thinking tokens bill as output, so a reasoning-heavy request costs accordingly.
- The wallet is the spend limit. Calls draw down a prepaid balance, and a request arriving once that balance is gone is refused with a named error rather than quietly going into debt. Keys revoke individually, so one exposed key never halts the others.
Streaming follows the standard shape: "stream": true yields server-sent events, and leaving it out yields one aggregated JSON body. The bill is the same either way.
curl
curl -X POST "https://api.ironstratum.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "qwen3.6-35b",
"messages": [
{"role": "user", "content": "Find the bug in this retry loop and explain the fix: it retries immediately on every failure."}
],
"reasoning_effort": "minimal"
}'
python
import os
import requests
resp = requests.post(
"https://api.ironstratum.com/v1/chat/completions",
headers={"Authorization": "Bearer " + os.environ["KEY"]},
json={
"model": "qwen3.6-35b",
"messages": [
{
"role": "user",
"content": "Refactor this module so retries use exponential backoff with jitter.",
}
],
"reasoning_effort": "high",
},
timeout=120,
)
resp.raise_for_status()
message = resp.json()["choices"][0]["message"]
print(message.get("reasoning_content", "")[:200])
print(message["content"])
openai-sdk
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.ironstratum.com/v1",
api_key=os.environ["KEY"],
)
completion = client.chat.completions.create(
model="qwen3.6-35b",
messages=[
{
"role": "user",
"content": "Review this repository layout and list the three riskiest files to change.",
}
],
reasoning_effort="high",
)
message = completion.choices[0].message
print(message.content)
An existing OpenAI SDK integration moves over by exactly two lines: the base_url and the model id.
Benchmarks
Two evidence layers, both dated, plus one honesty note.
The model's own scores. From the official model card and release post, publisher-run under the harness configurations named in the card's footnotes (an internal agent scaffold with bash and file-edit tools for the SWE-bench series, the Harbor/Terminus-2 harness for Terminal-Bench). The dense sibling's column comes from its own release post, one week later, under the same harness footnotes:
| Benchmark | Qwen3.6-35B-A3B | Qwen3.6-27B (dense) | Qwen3.5-35B-A3B | Qwen3.5-27B |
|---|---|---|---|---|
| SWE-bench Verified | 73.4 | 77.2 | 70.0 | 75.0 |
| SWE-bench Pro | 49.5 | 53.5 | 44.6 | 51.2 |
| Terminal-Bench 2.0 | 51.5 | 59.3 | 40.5 | 41.6 |
| Claw-Eval (avg) | 68.7 | 72.4 | 65.4 | 64.3 |
| QwenWebBench | 1397 | 1487 | 978 | 1068 |
| GPQA | 86.0 | 87.8 | 84.2 | 85.5 |
| AIME26 | 92.7 | 94.1 | 91.0 | 92.6 |
| LiveCodeBench v6 | 80.4 | 83.9 | 74.6 | 80.7 |
Read the table for what it is. Against its direct predecessor the MoE wins nearly every row. Against the dense models, the generation matters: the previous Qwen3.5-27B traded blows with it, but the same-generation dense Qwen3.6-27B leads the published rows, 77.2 to 73.4 on SWE-bench Verified and 59.3 to 51.5 on Terminal-Bench 2.0. Peak scores belong to the dense build; what the sparse build buys is about 3B active parameters per token for fast, low-compute decode and fewer full-attention layers for long-context memory. On vision, the release post benchmarks the model against Claude Sonnet 4.5 across most vision-language tasks and ahead on several, with spatial-intelligence rows (RefCOCO 92.0, ODInW13 50.8) called out.
Provenance. Every number above is provider-run. The card is explicit about its harnesses, which is to its credit, and the independent trackers that re-measure this class report mixed, methodology-dependent results. None of those tracker numbers appear here as facts. What we publish on our side is different in kind: a serving measurement, below, from our own registry work.
This platform's measurement. The served context window, probed live on 2026-08-20:
| Probe | Result |
|---|---|
| 130,048-token prompt | fits, served |
| 139,264-token prompt | rejected at the window |
| Window set in the registry | 131,072 tokens |
| Second provider leg spot-check | served at 130,044 tokens |
These are capacity numbers from a dated measurement window, not a standing SLA. The registry row carries the probe notes; if the window ever moves, the registry moves first and this page follows.
Getting started
- Create an account through the console's invite flow. The beta is invite-only for now, and the console is the home of the wallet and every key you issue.
- Create an API key. Scope one key to a project: keys revoke one at a time, so a disabled key leaves the rest of your work untouched.
- Check the rate. Per-token metering means the pricing page holds the live rate card; set the wallet to what you are willing to spend, and a request that arrives after the balance is gone is refused with a named error.
- Make the first call. Take the curl tab, export
KEY, and run it as written. Thinking shows up as areasoning_contentfield beside the answer;"reasoning_effort": "minimal"removes it on later calls.
The chat category page covers the rest of the chat fleet, including the dense Qwen3.8 27B lane this page's FAQ compares against, and the models index lists every model on the platform.