JetBrains Open Sources Mellum2.1: 12B MoE Coding Agent Model With Apache 2.0 Weights and Quantizations
According to an October 8, 2026 report by MarkTechPost, JetBrains released Mellum2.1 under the Apache 2.0 license, namely Mellum2.1-12B-A2.5B-Thinking: a 12B total-parameter, 2.5B-active-parameters-per-token MoE thinking model with the same architecture as the previous generation, where the improvements come mainly from reinforcement learning in real code repositories, with the report stating SWE-bench Verified rose from 2.0 to 47.0.
What changed
According to an October 8, 2026 report by MarkTechPost, JetBrains released Mellum2.1, with the checkpoint named Mellum2.1-12B-A2.5B-Thinking, publishing weights on Hugging Face under the Apache 2.0 license. It is a mixture-of-experts reasoning model with 12B total parameters and 2.5B parameters activated per token, with 28 layers, 64 experts, 8 experts activated per token, GQA (32 query heads, 4 KV heads), 3 of every 4 layers using a 1024-token sliding window, a context of 131072 tokens, a vocabulary of 98304, and bfloat16 weights. The report states that the architecture is unchanged from the Mellum2 Thinking open-sourced in June 2026, and that the upgrade comes almost entirely from post-training: RL became the main body of training, with added tasks in mathematics, competitive programming, science, tool calling, and software engineering, and training in real code repositories with shell and file-editing tools, rewarding test passes. The report states that under JetBrains' own testing, SWE-bench Verified rose from 2.0 to 47.0, SWE-bench Pro from 0.0 to 28.0, Terminal-Bench 2.1 from 0.6 to 17.4, with LiveCodeBench v6 at 82.0, BFCL v4 at 62.3, and HarmBench falling from 21.5 to 8.5; Qwen3.5-9B still leads on SWE-bench Verified (50.0), SWE-bench Pro (38.0), GPQA Diamond (77.8), and AIME 25/26 (86.7).
What it means for developers
The significance of this release for self-hosted coding agents centers on three points, all of which depend on the report's account rather than independent reproduction. First, the model releases weights under the Apache 2.0 license, making it a clearly licensed open-weights release rather than merely downloadable weights; however, all benchmark scores in the report are self-reported by JetBrains, and the Qwen official model card gives noticeably different LiveCodeBench v6 and GPQA Diamond figures for the same model than JetBrains' evaluation process, indicating that scores are sensitive to the evaluation framework and cannot be taken directly as cross-vendor comparable conclusions. Second, 2.5B activated parameters plus a 131072-token context and GGUF quantizations make local sub-agents feasible on consumer-grade or single-GPU setups: the report lists versions including BF16 24.3 GB, Q8_0 12.9 GB, Q4_K_M 8.1 GB (88.0% first-token match rate), and MXFP4_MOE 7.0 GB (85.6%). What developers need to watch is whether the capability degradation after quantization falls within their own task tolerance, not a single file size. Third, the report states that throughput under high load on a single H200 is close to twice that of Qwen3.5-9B, with MTP giving roughly a 1.6x speedup in single-request scenarios, but the MTP head for vLLM speculative decoding is marked as coming soon, meaning current deployments cannot directly use that acceleration. For teams using coding agents, this looks more like a candidate low-cost execution unit than a general-purpose reasoning main-workhorse replacement: the report shows it lagging on Terminal-Bench 2.1 and knowledge-oriented benchmarks.
Integration and evaluation
It is advisable to validate by task layer rather than replacing the whole stack. Decision one: if the workload is high-concurrency, short-step code completion or sub-agent execution units, prioritize evaluating a 12B/2.5B-active MoE deployment, provided there is more than one GPU's worth of VRAM and a vLLM or SGLang environment; the report gives the launch method as vLLM with --reasoning-parser qwen3, tool calling requires adding --enable-auto-tool-choice --tool-call-parser hermes, and sampling parameters are suggested as temperature 0.6, top_p 0.95, top_k 20; the metric should be per-token throughput and cost per task on equivalent hardware, not just benchmark scores. Decision two: if the workload is long-chain repository-level repair, first run a small-sample comparison on your own repositories, comparing task pass rates and failure modes against models like Qwen3.5-9B, because the report's self-reported SWE-bench Verified of 47.0 is lower than Qwen3.5-9B's 50.0, with an even clearer gap on Terminal-Bench 2.1; this presupposes the organization already has an automatically judgeable test set; the metric is end-to-end task pass rate and average number of steps. Decision three: for local or offline scenarios, try the Q4_K_M and MXFP4_MOE quantized versions first, provided the task is insensitive to first-token behavior deviations; the metric is the gap between the quantized version and the BF16 reference version in first-token match rate and actual correctness on your own prompt set. Also note that the availability described in the report refers to the vendor's released weights and inference framework support, and the integration method should follow each framework's documentation.
Limits and open questions
Key limitations should be clear: Mellum2.1 does not appear in KimiSeek's live model catalog, and this version is currently not listed on KimiSeek; the weights, GGUF, and vLLM/SGLang deployment methods mentioned in the report all refer to JetBrains' release and do not mean availability on this site. All performance numbers come from JetBrains' self-reporting or its unified evaluation process, including SWE-bench, Terminal-Bench, LiveCodeBench, and BFCL, and have not been independently reproduced; the report itself points out that the Qwen official model card and JetBrains' evaluation give different figures for the same model, so cross-comparison conclusions should be treated with caution. The first-token match rate of quantized versions is not equivalent to task correctness; the report's GGUF list and the statement that "GGUF is still in progress" differ in wording, and the actually available files and quality need to be checked independently. The MTP head is marked as coming soon, and vLLM speculative decoding acceleration is not currently available. In addition, specific calling prices and billing methods should be based on the vendor's pricing page; this article does not cite specific figures.