IronStratum Get an API key

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:

FactValueWhere the number comes from
Parameters35B total, about 3B active per tokenmodel card
Architecturesparse MoE, 256 experts, 8 routed + 1 sharedmodel card
Attentionhybrid: Gated DeltaNet linear attention, full attention every fourth layermodel card
Visiontext and image input (video in the card's quickstart)model card
LicenseApache 2.0model card
Native context window262,144 tokens, extensible to about 1,010,000 with YaRNmodel card
Served window on this route131,072 tokensplatform serving registry
Thinking controlreasoning_effort: minimal, low, medium, highplatform contract
First-party API nameqwen3.6-flash on Alibaba Cloud Model Studiorelease 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:

  1. reasoning_effort is the thinking control. Accepted values are minimal, low, medium, and high. minimal turns thinking off; the other three run it. The model's upstream hosts carry this switch under their own enable_thinking spelling, and the platform performs that mapping on the way out, so you never write it yourself. Send reasoning_effort and nothing else for thinking control: the parser rejects unknown parameters with a 400, including a hand-rolled enable_thinking or a nested template-kwargs object, so a wrong knob fails loudly at the door instead of silently upstream.
  2. Unknown parameters are rejected. The accepted set includes the OpenAI-compatible core: messages, stream, max_tokens and max_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.
  3. 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.
  4. 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:

BenchmarkQwen3.6-35B-A3BQwen3.6-27B (dense)Qwen3.5-35B-A3BQwen3.5-27B
SWE-bench Verified73.477.270.075.0
SWE-bench Pro49.553.544.651.2
Terminal-Bench 2.051.559.340.541.6
Claw-Eval (avg)68.772.465.464.3
QwenWebBench139714879781068
GPQA86.087.884.285.5
AIME2692.794.191.092.6
LiveCodeBench v680.483.974.680.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:

ProbeResult
130,048-token promptfits, served
139,264-token promptrejected at the window
Window set in the registry131,072 tokens
Second provider leg spot-checkserved 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

  1. 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.
  2. 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.
  3. 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.
  4. Make the first call. Take the curl tab, export KEY, and run it as written. Thinking shows up as a reasoning_content field 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.

What the platform serves

Chat and reasoning models — context window, price per million tokens in and out and cached, capabilities
ModelContext$/1M in$/1M out$/1M cached inCapabilities
qwen3.6-35b131,0720.110.800.044thinking · streaming

Rendered from the model registry — the same data GET /v1/models serves. A dash means the value isn't set.

Questions

What is Qwen3.6-35B-A3B?
A sparse mixture-of-experts language model from Alibaba's Qwen team, released as open weights in April 2026 under Apache 2.0. It has 35 billion parameters in total but activates about 3 billion per token, across 256 experts with 8 routed plus 1 shared active per step. It is built for agentic coding, accepts text and image input, and runs in thinking and non-thinking modes. On this platform it serves under the alias qwen3.6-35b.
How much does the Qwen3.6-35B-A3B API cost?
The route meters per token: input tokens, output tokens, and cached input tokens each bill at their own registry rate, and the pricing page renders the current rates. You pay from a prepaid wallet, and a request that arrives after the balance is gone is refused with a named error rather than quietly going into debt. Thinking tokens bill as output tokens, which matters on a reasoning model: long thinking traces are the main way an unwatched bill grows.
Qwen3.6-35B-A3B or the 27B dense model: which should I use?
The publisher's same-generation table gives the dense Qwen3.6-27B the quality rows: 77.2 to 73.4 on SWE-bench Verified, 59.3 to 51.5 on Terminal-Bench 2.0, and the lead on the front-end and agent benchmarks. The MoE's case is different. About 3 billion active parameters per token make decode much faster, one documented 16 GB setup measured 98 tokens per second against 31 for the dense model, and fewer full-attention layers (10 here against 16 in the dense model) hold long contexts in less memory. The practical split: the dense model when peak coding quality decides, the MoE when throughput or long-context reading decides. This platform's dense-27B lane is the newer Qwen3.8 27B.
How does Qwen3.6-35B-A3B compare with Qwen3.8-27B?
Same family, different builds. Qwen3.8-27B is the dense successor that shipped about four months later, post-trained for multi-step agentic reliability: carrying long tool-driven tasks to completion. Qwen3.6-35B-A3B is the sparse route: fewer active parameters per token, fast decode, and a long window for repo-scale context. Both are hosted here, so the practical split is simple: the MoE for throughput and long-context reading, the dense 3.8 for deep step-by-step agent work.
How much VRAM do I need to run Qwen3.6-35B-A3B locally?
Count on the 24 GB card class. The weights are about 21 GB at the common Q4_K_M quantization, and the official Ollama package downloads as a 23 GB build. The 8-bit class needs roughly 37 GB. Tricks exist to squeeze it onto 16 GB, quantized key-value caches and offloading experts into system RAM, at real speed costs. If you would rather not own the hardware question, that is the hosted route's job.
Can I use Qwen3.6-35B-A3B with the OpenAI SDK or Claude Code?
Any client that speaks the OpenAI chat-completions shape works: change the base URL and the model id, and an existing OpenAI SDK integration moves over. Claude Code is a different case: it speaks the Anthropic Messages protocol, which this endpoint does not carry. The publisher's first-party API does offer that protocol, and the release post documents the Claude Code setup against it.
How do I turn Qwen3.6-35B-A3B thinking on or off?
Send reasoning_effort in the request: minimal disables thinking, and low, medium, or high enable it. When thinking runs, the reasoning arrives in a separate reasoning_content field next to the answer, so logs stay clean. Thinking tokens meter as output tokens. Other API hosts use different switches for the same model, enable_thinking inside an extra body object, or a chat-template flag in llama.cpp; at this endpoint reasoning_effort is the one accepted control, and other spellings return a parameter error.