What is Qwen3-Coder-REAP-246B-A35B?
Qwen3-Coder-REAP-246B-A35B is an open-weight, text-generation model from Cerebras that specializes in software development tasks. It is derived from Qwen3-Coder-480B-A35B-Instruct and applies Router-weighted Expert Activation Pruning, abbreviated as REAP. The pruning process removes approximately half of the original model's experts, producing a smaller checkpoint while retaining the original routing structure.
The model is a sparse Mixture-of-Experts, or MoE, language model. Although the checkpoint contains approximately 246 billion total parameters, only about 35 billion are activated for each token. In practical terms, this reduces the computation and memory requirements compared with using all parameters at once, but it does not make the model small: deployment still requires substantial GPU memory and multi-GPU infrastructure.
Cerebras lists the model in its current Hugging Face catalog as an open-weight checkpoint rather than as a conventional hosted API product. It is intended for local, self-hosted, and research deployments using software such as Transformers, vLLM, or SGLang.
How REAP compression changes the model
In an MoE model, different input tokens are routed to different expert networks. Qwen3-Coder-REAP-246B-A35B has 80 experts, compared with 160 in the source Qwen3-Coder-480B-A35B-Instruct model, and activates eight experts per token. The model has 62 layers and uses grouped-query attention with 96 query heads and eight key-value heads.
REAP uses router-gating behavior and expert activation norms to decide which experts to remove. This is different from simply reducing the size of every layer: the method preserves the sparse routing design while reducing the number of available experts. Cerebras describes the result as a 50% compressed version of the original model.
The compression is most useful for organizations that want to run a very large coding model but cannot accommodate the full source checkpoint. It should not be interpreted as making the model suitable for ordinary laptops or low-memory single-GPU systems. The documented deployment approach uses tensor parallelism and expert parallelism across multiple devices.
Context window and supported input and output
The verified native context length is 262,144 tokens. This is large enough for substantial source trees, long technical specifications, extensive logs, or multi-file software-engineering tasks, although the amount of usable content will depend on the prompt, tool traces, and generated response.
The model card states that the context can be extended to approximately one million tokens with YaRN. That extended-context figure is a provider-documented option rather than the model's native context limit, and deployments using it may require additional testing and tuning.
Qwen3-Coder-REAP-246B-A35B accepts text prompts and produces text. Its supported uses include code generation, code explanation, repository-scale code understanding, agentic coding, and function calling. The supplied documentation does not identify native image, audio, or video input, and the model does not directly generate images, audio, or video. A maximum output-token limit was not specified in the reviewed documentation.
Coding, reasoning, and tool use
The model is primarily intended for programming rather than general-purpose multimodal work. It can be used to generate code, inspect and modify codebases, reason across repository files, and support software-engineering agents. Its long context is particularly relevant when a task requires keeping many files or a large amount of project documentation in view at the same time.
Function calling is supported, allowing an application or agent framework to expose tools such as file operations, test runners, search utilities, or deployment commands. The recommended vLLM setup includes automatic tool choice and the Qwen3 Coder tool-call parser. Tool use does not mean the checkpoint independently performs external actions: the surrounding application must provide the tools and execute approved calls.
The research rates the model's reasoning capability at 8 out of 10 and coding capability at 9 out of 10. These are editorial evaluation scores supplied for this page, not benchmark results published by Cerebras. The model card's published evidence is more directly focused on coding and software-engineering performance than on a separate general reasoning score.
Reported evaluation results
The separately listed FP8 variant provides the published evaluation table associated with this model family. Reported results include 93.9 on HumanEval, 91.0 on MBPP, 52.2 on SWE-Bench-Verified using mini-swe-agent, and 67.4 on the reported overall BFCL-v3 measure.
These figures should be treated as checkpoint-specific results rather than universal guarantees for every deployment. They apply to the reported FP8 variant and depend on quantization, prompt formatting, inference framework, and evaluation procedure. The BF16 model page states that its own evaluation results were still to be provided, so the FP8 scores should not automatically be presented as BF16 results.
Deployment, speed, and cost trade-offs
Although REAP reduces the model from the original 480-billion-parameter design to 246 billion total parameters, this remains a very large checkpoint. Practical use generally requires multiple GPUs and parallel inference. Cerebras's documented vLLM configuration uses eight-way tensor parallelism, expert parallelism, automatic tool choice, and the Qwen3 Coder tool-call parser.
The research gives the model an editorial speed score of 3 out of 10 and a cost score of 7 out of 10. These scores are subjective assessments rather than provider-published throughput or pricing measurements. The low speed assessment reflects the model's scale and multi-GPU deployment requirements; actual performance will depend on hardware, quantization, batch size, context length, and inference software.
No verified Cerebras-hosted per-token input or output price was identified for this exact open-weight checkpoint. It should therefore not be evaluated like a standard managed API model with a published recurring token rate. The financial trade-off is instead dominated by the cost of acquiring or renting suitable GPU infrastructure, operating it, and managing the deployment.
Main strengths and limitations
Key strengths
- Large coding capacity: The model retains 246 billion total parameters and approximately 35 billion active parameters per token.
- Long native context: Its 262,144-token context window supports large repositories and extended software-engineering sessions.
- Reduced size relative to its source model: REAP removes approximately half of the original experts while retaining the sparse routing structure.
- Agent compatibility: It supports function calling and documented tool-use configurations for vLLM.
- Self-hosting rights: The checkpoint is distributed under the Apache 2.0 license, subject to the license terms.
- Multiple deployment paths: The model is documented for Transformers, vLLM, and SGLang.
Important limitations
- Very high hardware requirements: Compression does not make the checkpoint suitable for low-memory deployment, and multi-GPU parallelism is expected for practical use.
- No identified hosted price: Cerebras publishes the weights, but the supplied research does not verify a managed Cerebras API endpoint or per-token price for this model.
- Text-only operation: The model is not a native image, audio, or video generation system, and multimodal input support was not identified.
- Incomplete BF16 evaluation evidence: Published benchmark results are associated with the FP8 variant, while BF16 results were not yet provided in the reviewed documentation.
- Unspecified maximum output: The reviewed sources specify the context window but do not provide a separate maximum output-token limit.
- Operational complexity: Running the model requires suitable hardware, parallelism configuration, inference software, and careful handling of tool calls.
When to choose this model
Choose Qwen3-Coder-REAP-246B-A35B when you need an open-weight coding model for self-hosted use and have access to substantial multi-GPU infrastructure. It is a strong fit for repository-scale code analysis, automated code changes, software-engineering agents, function-calling workflows, and research into compressed large MoE models.
The model is also a logical option when data must remain within infrastructure controlled by the deploying organization, or when a team wants to customize inference rather than depend on a hosted endpoint. Its long context is useful for tasks that involve many related files, lengthy build logs, or large technical documents.
Another option may be more appropriate when fast interactive responses, low infrastructure cost, or turnkey API access matters more than maximum coding-model scale. A smaller coding model is likely easier to deploy and may provide better latency on limited hardware. A managed coding API may also be preferable for teams that do not want to operate multi-GPU inference. For image, audio, or video tasks, a model designed for those modalities is required because this checkpoint is text-only.
Pricing, license, and model identity
Qwen3-Coder-REAP-246B-A35B has no verified provider-managed input or output price in the supplied research. The practical cost of using it comes from the hardware and infrastructure needed to host the open weights. The checkpoint is distributed under the Apache 2.0 license.
Users should distinguish the BF16 checkpoint discussed here from the separately named Qwen3-Coder-REAP-246B-A35B-FP8 checkpoint. The FP8 variant is the one associated with the cited evaluation results, while both variants should be treated as separate model identifiers when configuring downloads or inference systems.