This article ran on 2026-07-28 under a plain premise: no source in the verified record confirmed that Mellum2 existed, so every circulating spec, the 12B total included, sat in the unverified bucket. That premise expired on 2026-08-13, when JetBrains published its launch post: Mellum2 is a 12B mixture-of-experts model with 2.5B parameters active per token, trained from scratch on natural language and code, released under Apache 2.0 with weights on Hugging Face. The architecture disclosure this piece demanded is now vendor-published. The performance numbers are not verified: the claims of benchmark parity with similar-sized open models and more than 2x faster inference are JetBrains’ own, and the record contains no independent fill-in-the-middle or commit-level results. For local-deployment teams the read is now concrete: the 12B total sets the memory floor, the 2.5B active count sets per-token cost and latency, and both numbers finally have a primary source.
What is Mellum2 supposed to be, and what can we actually confirm?
At the July fact-check, nothing confirmed Mellum2’s architecture, parameter count, context length, license, or release timing, and the claimed predecessor Mellum was equally absent from the record; the JetBrains Wikipedia entry1 still records none of it. As of 2026-08-19, the launch post on the HuggingFace blog and JetBrains’ own open-source announcement confirm the load-bearing specs: 12B total parameters, 2.5B active per token through MoE routing, Apache 2.0, trained from scratch, and text-and-code only, with the launch post stating the model is deliberately not multimodal. The Mellum product page closes the lineage gap too: the family is now listed as Mellum1, the open-source code completion model, and Mellum2, the MoE successor. The predecessor the July record could not confirm now has its own row on a vendor page.
The version of the story circulating in July described exactly this model: a 12B MoE successor to Mellum with an active count low enough to serve cheap, wired into JetBrains tooling. The rumor mill had the shape right. That it was right this time is not an argument for the rumor mill; on 2026-07-28 the identical claim had zero primary sources behind it, and the next circulating spec will not always be so lucky.
The July discipline stands anyway: no primary source, no cell in the comparison table. It produced the right posture then, which was to treat every Mellum2 spec as unverified, and it produces the right posture now, which is to treat every Mellum2 performance claim as vendor-reported until independent benchmarks land. A parameter count in a social post is still not a spec sheet, and a spec sheet is still not a benchmark. Coding-model releases have a recent history of specs traveling ahead of their documentation; this one resolved cleanly, and the process that flagged it did not become wrong in the process.
Why does mixture-of-experts change the serving math for local code completion?
In a mixture-of-experts model, each token activates only a subset of the total parameters, so the per-token compute and memory-bandwidth cost tracks the active-parameter count rather than the full model footprint. Mellum2’s published split makes the abstraction concrete: 12B of weights to hold in memory, 2.5B of them consulted per token.
That distinction is the entire economic argument for MoE in local inference, and it is worth stating precisely because it inverts the heuristic most teams use. With a dense model, total parameters are a decent proxy for serving cost: every token passes through every weight, so a 12B dense model costs roughly what a 12B model costs, full stop. With MoE, the router selects a small number of experts per token. The model’s total parameter count mostly determines how much memory you need to hold the weights; the active count determines how much compute and bandwidth each generated token consumes. A model can therefore be large on disk and cheap per token at the same time.
For code completion specifically, per-token cost is the metric that matters. Completion is latency-sensitive in a way chat is not. A suggestion that arrives after the developer has already typed the next three characters is worth nothing, and IDE integrations discard stale completions aggressively. The economics work out as follows: interactive completion wants the per-token speed of a small dense model, but it also wants the quality headroom that tends to come with larger training runs and bigger total capacity. MoE is the architecture that claims to offer both, which is why it has become the default shape for serious open coding models.
There is a second-order consequence here that the angle on this story got right even before the specifics were confirmed. Once MoE is the default, “how big is the model” stops being a well-formed question for capacity planning. Teams have to reason in two numbers instead of one: total parameters for the memory footprint, active parameters for the per-token cost. Any vendor that publishes only the first number is withholding the one you actually need to size a deployment. JetBrains now publishes both, at a ratio just under five to one, which is exactly the disclosure pattern this argument demands. Every other MoE coding model vendor should be held to the same two-number standard, including the ones that currently publish only a total.
A caveat that should travel with the principle: holding weights for a large-total MoE still costs memory, and expert routing adds implementation complexity that dense models do not have. The serving win is real but it is not free, and it depends on the inference stack handling sparse activation efficiently. The claim “MoE is cheap to serve” is shorthand for “cheap per token relative to its total size,” not “cheap in absolute terms.” At 12B total, Mellum2 sits in a size class where MoE had been rare; the product page bills it as “bringing MoE capabilities to a much smaller model class,” which is the vendor’s framing but also a fair description of the placement.
What does DeepSeek-Coder-V2 actually prove about open MoE coding models?
DeepSeek-Coder-V2 is the documented precedent: an open-source MoE code model that reaches performance comparable to GPT-4-Turbo on code-specific tasks, with 128K context and support for 338 programming languages2.
The DeepSeek-Coder-V2 paper is the strongest evidence in the record that the MoE approach to coding models delivers at the frontier rather than just in theory. The model was further pre-trained from an intermediate DeepSeek-V2 checkpoint with an additional 6 trillion tokens. That continued pre-training expanded programming-language coverage from 86 to 338 languages2 and extended context length from 16K to 128K tokens. On coding and math benchmarks, the paper reports performance that outperforms the earlier DeepSeek-Coder-33B and rivals GPT-4-Turbo, Claude 3 Opus, and Gemini 1.5 Pro.
Three things in that result matter for anyone evaluating the next claimed MoE coding model, Mellum2 included.
First, the comparison to the earlier DeepSeek-Coder-33B is explicit in the paper’s own lineage. DeepSeek-Coder-V2 surpasses the 33B model while being built on a mixture-of-experts architecture. If that 33B predecessor was a dense model, this is concrete evidence that the active-parameter trick is not an accounting fiction: the quality went up while the architecture shifted cost from total parameters to active parameters.
Second, the jump from 86 to 338 languages2 is the part most coverage skipped, and it is arguably the most practically significant number in the paper. Code completion in a real IDE session is not a Python-and-TypeScript affair. It hits build files, config languages, shell, SQL, templating, and whatever long-tail language the legacy service is written in. A completion model with narrow language coverage degrades gracefully on benchmarks and badly in production. Mellum2’s documentation now exists, and it does not state a language count. That cell is still open, and it is still a more useful cell in the comparison than another decimal point on HumanEval.
Third, 128K context sets the bar for what a competitive coding model now needs to ingest. Repository-level completion, the kind that actually helps, wants to see imports, sibling files, and recent edits, not just the current buffer. The move from 16K to 128K between DeepSeek generations is the market telling you what table stakes look like. Mellum2’s launch post is silent on context length, which is the single most conspicuous omission in it.
One honest limitation on all of the above: the DeepSeek-Coder-V2 numbers are the authors’ own reported results from a June 2024 paper. They are well-cited and the model has been broadly adopted, which gives them more weight than a typical vendor claim, but they are still self-reported benchmarks from a pre-release evaluation suite, and the frontier models they were compared against are two generations old as of mid-2026. The same caveat now applies word for word to JetBrains’ launch-post figures: vendor-reported, produced by the vendor, awaiting replication.
Where would a Mellum successor sit in JetBrains’ AI stack?
JetBrains has three distinct AI surfaces, and any first-party coding model would land on a specific one: AI Assistant handles completion, Junie is the autonomous agent, and JetBrains Air orchestrates multiple agents including third parties.
The integration question matters more than it might appear, because a model’s value is partly determined by the surface it serves. AI Assistant ships in most JetBrains IDEs as the completion-and-assistance layer. Junie is a separate product, designed to function as an autonomous coding agent rather than an autocomplete engine.
The third surface is newer and changes the strategic picture. JetBrains Air is positioned as an “Agentic Development Environment” that runs Codex, Claude Agent, Gemini CLI, and Junie as independent task loops, isolated via Docker, Git worktrees, or cloud environments. Read that agent list again. Three of the four are competitors’ agents. JetBrains is building a control plane that assumes model pluralism, which tells you something about how the company expects the model layer to shake out: not winner-take-all, and not first-party-only.
The IDE estate these surfaces sit on is unusually uniform. JetBrains’ IDE lineup spans IntelliJ IDEA, PyCharm, WebStorm, CLion, GoLand, Rider, RubyMine, RustRover, and PhpStorm, all sharing a single platform with a built-in AI Assistant. That shared platform is the distribution advantage a first-party model would have: one integration ships to every JetBrains IDE at once, with access to the PSI tree, project indexes, and refactoring infrastructure that a generic completion API does not see. Meanwhile, the company unified IntelliJ IDEA into a single distribution in December 2025, merging the previously separate Community and Ultimate editions under a subscription model, which consolidates the user base any bundled model would reach.
The local-deployment counterweight resolved itself in Mellum2’s favor: Apache 2.0, weights on Hugging Face, so the “open” in this article’s original framing finally has a source. What replaced the license question is a positioning question. The launch post’s use-case list is routing and orchestration, low-latency RAG pipelines, sub-agents, high-throughput coding features, and private deployment. That is a broader job description than autocomplete, and it maps onto the control plane Air already runs: pipelines of context gathering, planning, and validation steps that execute constantly and never need a frontier model. A 2.5B-active first-party model priced for those steps is a component of an orchestration product as much as it is a competitor to Qwen Coder. The launch post never mentions Air by name, but the two releases read as parts of one architecture.
Which cells in a Mellum2 vs Qwen Coder vs DeepSeek Coder comparison are actually verifiable?
As of 2026-08-19, the honest table has a populated Mellum2 column, an unchanged DeepSeek-Coder-V2 column, and empty Qwen Coder and StarCoder2 columns, because the fetched record still contains no figures for those two. This is where the July article refused the decorative table, on the grounds that no primary source existed to fill it. One exists now, so the table gets drawn, with the status column carrying the epistemics that the empty cells used to:
| Disclosure | Mellum2 | Status |
|---|---|---|
| Total parameters | 12B | vendor-published spec |
| Active parameters per token | 2.5B | vendor-published spec |
| License | Apache 2.0, weights on Hugging Face | vendor-published spec |
| Modality | text and code, not multimodal | vendor-published spec |
| Context length | not stated | missing |
| Language coverage | not stated | missing |
| Quality benchmarks | ”competitive with similar-sized open models” | vendor-reported, no independent replication |
| Inference speed | ”more than 2x faster” than similar-sized models | vendor-reported, no independent replication |
Run down the decision axes and look at what survives contact with the sources.
On active-parameter footprint: Mellum2’s 2.5B per token is vendor-published. For DeepSeek-Coder-V2, the MoE architecture itself is documented in the paper, though the specific expert configuration is beyond what the fetched record quotes. For Qwen Coder and StarCoder2, no figures are present in the source set at all, so nothing can be claimed here without going off-brief. A direct active-to-active comparison between Mellum2 and DeepSeek-Coder-V2 therefore still cannot be run from these sources, which matters because that is the comparison that determines relative serving cost.
On context length: Mellum2’s is undisclosed, DeepSeek-Coder-V2’s 128K is documented, and Qwen Coder and StarCoder2 are not in the record. An open cell that a June 2024 competitor had already filled is a strange thing for a 2026 launch post to leave blank.
On license: Apache 2.0, confirmed. The July version of this section called the “open” framing unsourced; it is sourced now.
On IDE integration: this remains the axis where the record is most solid. The JetBrains IDE platform ships a built-in AI Assistant across its lineup, the Mellum product page positions the family across JetBrains tooling, and JetBrains Air shows the company orchestrating third-party agents as first-class citizens. Any JetBrains first-party model has a native integration surface that third-party models reach only through plugins like Continue or through external editors like Cursor. That advantage is architectural and never depended on any Mellum2 spec being true.
On benchmark scores: Mellum2’s are vendor-reported summary claims, with the tables sitting in a technical report (arXiv:2605.31268, linked from the launch post) that is not in the fetched record. The DeepSeek-Coder-V2 figures are self-reported June 2024 results against models that are no longer current. Comparing either against anything current, without independent numbers, would be apples to archaeology.
The pattern across the five axes changed shape but not the finding. In July, Mellum2 scored zero out of five on this article’s checklist: total parameters, active parameters, context length, license, and a dated benchmark suite, each from a primary source. Today it scores three, with a fourth referenced but not verifiable from the record and the fifth blank. The remaining two cells, context and benchmarks, are precisely the ones that decide production quality.
Should a local-deployment team plan around Mellum2?
Not migrate, no. Trial, cheaply, maybe. The verdict moved from “nothing to evaluate” to “an evaluation object with two missing cells.”
The practical verdict has three parts. First, the MoE serving principle is sound and should already be shaping your capacity planning: cost per token tracks active parameters, not total footprint, and DeepSeek-Coder-V2 demonstrates that an open MoE coding model can reach frontier-adjacent quality on that basis. If your team is still sizing coding-model deployments by total parameter count, fix that now regardless of what JetBrains does. Mellum2’s 12B/2.5B pair is a working example of the two-number disclosure that principle requires, published rather than leaked, which is itself a small improvement on how these specs usually surface.
Second, do not move production traffic on vendor-reported numbers. The launch post’s quality and speed claims have no independent replication in the record, the benchmark tables live in a technical report that has not been checked here, and the model’s context length is undisclosed. For repository-level completion, undisclosed context is disqualifying on its own, whatever the per-token cost. The July article’s warning against betting a migration on a press cycle converts cleanly into a warning against betting one on a launch post.
Third, the evaluation math finally works. Apache 2.0 weights, a 12B memory footprint, per-token compute in the 2.5B class, and a vendor-stated design point of routing, summarization, and sub-agent steps. For teams already running Qwen Coder or DeepSeek Coder for heavy generation, the plausible first role for Mellum2 is the fast lane: classification, routing, context compression, the high-frequency calls where a 2.5B-active model either holds quality or visibly does not. That is a cheap experiment and a reversible one, which is more than could be said of anything involving Mellum2 three weeks ago.
The July close said an empty spec sheet is itself a spec. The sheet filled in within three weeks, and the two numbers that determine serving math are now published and citable. The cells that determine quality are still vendor ink. Both facts are worth holding at once, and the second is the one that should gate anything. JetBrains’ product direction, with Air orchestrating Codex, Claude Agent, and Gemini CLI alongside Junie, still suggests a company hedging toward model pluralism rather than betting the IDE estate on a first-party model; Mellum2 as published, a small fast generalist for orchestration steps rather than a frontier completion engine, fits that hedge exactly.
Frequently Asked Questions
How does Mellum2’s 2.5B active parameter count compare to DeepSeek-Coder-V2’s serving cost?
Per-token cost tracks active parameters, so Mellum2’s serving bill behaves like a 2.5B model while its memory footprint behaves like a 12B model. DeepSeek-Coder-V2’s MoE architecture is documented in its paper, but the fetched record does not quote its expert configuration or active count, so a direct active-to-active comparison cannot be run from these sources. What can be said: JetBrains’s near-5:1 total-to-active ratio is the disclosure pattern DeepSeek’s lineage established, and matched independent benchmarks are still required before any cost-per-quality claim.
What is the practical impact of JetBrains Air on local model deployment strategies?
JetBrains Air orchestrates multiple agents including Codex, Claude Agent, and Gemini CLI as independent task loops, suggesting a shift toward model pluralism rather than exclusive reliance on first-party models. This architecture implies that local deployment teams should prioritize models with robust API compatibility and open licensing, as JetBrains’ own infrastructure is designed to integrate third-party solutions alongside its own Junie agent. Mellum2’s Apache 2.0, self-hostable profile now gives that plural stack a first-party option for the fast routing and sub-agent steps, which fits the same assumption rather than competing with it.
Why is language coverage a more critical metric than benchmark scores for code completion models?
Real-world IDE sessions involve diverse languages including build files, config formats, shell scripts, and legacy codebases, not just primary languages like Python or TypeScript. DeepSeek-Coder-V2’s expansion from 86 to 338 languages2 demonstrates that broad coverage prevents degradation in production environments where narrow benchmark performance does not translate to practical utility across varied codebases. The Mellum2 launch post does not state a language count, so its coverage remains an open cell even after launch.
What are the risks of relying on total parameter counts for MoE model capacity planning?
Total parameter counts determine memory footprint but not per-token compute cost in MoE architectures, where only a subset of experts activates per token. Relying solely on total parameters can lead to over-provisioning memory while underestimating compute requirements, or vice versa. Teams must demand active parameter disclosures to accurately size inference infrastructure and predict serving costs. Mellum2’s published 12B/2.5B split is the live example: the 12B sets the VRAM floor, the 2.5B sets the per-token bill.
What does the Mellum2 launch post leave unverified?
Architecture, license, and both parameter counts now have a primary source in the 2026-08-13 launch post. Performance does not: the benchmark-competitiveness and >2x inference-speed claims are vendor-reported, context length and language coverage are unstated, and the technical report’s tables are not in the fetched record. The evaluation policy stands: primary-source specs, independently replicated fill-in-the-middle and commit-level benchmarks, and dated comparisons before production traffic moves, with DeepSeek-Coder-V2’s documentation remaining the reference for what full disclosure looks like in this category.
