The premise behind this comparison needs to be stated plainly before anything else: as of 2026-07-28, no source in the verified record confirms that a model called Mellum2 exists, let alone that it is a 12B mixture-of-experts release from JetBrains. What the record does confirm is a well-documented open MoE coding precedent in DeepSeek-Coder-V2 and a JetBrains AI stack with a clear integration surface. The practical consequence for local-deployment teams: treat every Mellum2 specification currently circulating as unverified, and demand active-parameter disclosure before changing any serving decision.
What is Mellum2 supposed to be, and what can we actually confirm?
Nothing in the available source set confirms Mellum2’s architecture, parameter count, context length, license, or release timing. The same gap applies to the claimed predecessor, Mellum: the fetched sources do not mention it at all.
That is not a pedantic caveat. It is the load-bearing fact of this article. The version of the story being passed around describes a 12B mixture-of-experts successor to Mellum with an active-parameter count low enough to serve at the cost of a much smaller dense model, wired into JetBrains IDEs as the default completion engine. Every one of those specifics is absent from the sources that could be checked. The JetBrains Wikipedia entry records no Mellum successor, no MoE architecture, and no parameter count for any JetBrains coding model; the cached page does not mention Mellum at all.
The claimed 12B total figure, the active-parameter count, the routing design, the context window, the license terms: all of it sits in the same evidentiary bucket, which is empty. An article that filled in those cells anyway would be doing vendor fan fiction, not analysis. The Mellum2-specific claims get marked as unverified. The mechanism that would make those claims matter if true, the economics of MoE serving, is real and documented. The comparison against Qwen Coder, DeepSeek Coder, and StarCoder2 gets run only on the cells where evidence exists.
This kind of gap is worth naming rather than smoothing over, because coding-model releases have a recent history of specs that travel ahead of their documentation. A parameter count appears in a social post, gets repeated in a roundup, and by the third repetition it reads as established fact. The fix is boring and effective: no primary source, no cell in the comparison table.
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.
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 though the Mellum2 specifics did not survive verification. 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. That applies to JetBrains if Mellum2 is real, and it applies equally to every other MoE coding model on the market.
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.”
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. When Mellum2’s documentation eventually exists, its language coverage is 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.
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.
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 counterweight to that distribution story is the local-deployment question. Nothing in the record confirms that a JetBrains coding model would ship under an open license with downloadable weights. The title of this article frames Mellum2 as an “open coding model.” That word “open” is doing unsourced work. If a Mellum successor exists and is served only through JetBrains’ infrastructure inside AI Assistant, then it does not compete with Qwen Coder or DeepSeek Coder on local deployment at all; it competes with the Copilot-style hosted completion tier, and the entire active-params-per-token analysis becomes JetBrains’ cost problem rather than yours.
Which cells in a Mellum2 vs Qwen Coder vs DeepSeek Coder comparison are actually verifiable?
Almost none on the Mellum2 side: the evidence set contains no Mellum2 figures of any kind and no Qwen Coder or StarCoder2 figures either, so the only populated column in any honest comparison today belongs to DeepSeek-Coder-V2.
This is where the article refuses the decorative table. A comparison table would not be defensible with this evidence. Run down the decision axes and look at what survives contact with the sources.
On active-parameter footprint: unverified for Mellum2, since neither the total nor the active count has a primary source. 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.
On context length: DeepSeek-Coder-V2’s 128K is documented. Mellum2’s context length is unverified. Qwen Coder and StarCoder2: not in the record.
On license: no license claim for any JetBrains coding model appears in the record. The “open” framing attached to Mellum2 is unsourced.
On IDE integration: this is the one axis where the record is solid. The JetBrains IDE platform ships a built-in AI Assistant across its lineup, 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 does not depend on any Mellum2 spec being true.
On benchmark scores: nothing verifiable for Mellum2, and the DeepSeek-Coder-V2 figures are self-reported June 2024 results against models that are no longer current. Comparing those against anything newer would be apples to archaeology.
The pattern across all five axes is the same, and it is the actual finding of this piece. The comparison the title promises cannot be run yet, because one of the named competitors may not exist as described and the others are outside the verified record. What can be run is a checklist: for any claimed MoE coding model, get the total parameters, the active parameters, the context length, the license, and a dated benchmark suite, each from a primary source. Mellum2 currently scores zero out of five on that checklist.
Should a local-deployment team plan around Mellum2?
No. The correct posture is to hold current deployments on Qwen Coder or DeepSeek Coder, treat the Mellum2 specifications as unconfirmed, and use the episode to tighten the evaluation criteria you apply when JetBrains does publish a model card.
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.
Second, do not migrate anything on the strength of the Mellum2 claims in circulation. The strongest limitation of the current record is total: every Mellum2-specific fact, including the 12B total parameter count, the active-parameter count, the MoE routing design, the context length, the license, and the IDE integration timing, is absent from checkable sources. A deployment decision made on that basis would be a bet on a press cycle, not on a model.
Third, when primary documentation does appear, the disclosure that matters most is the active-parameter count. A vendor that announces “12B” without the active count is giving you the number that sounds impressive rather than the number that determines your serving bill. DeepSeek’s published lineage, from the 33B model to a MoE successor with 128K context and 338-language coverage2, is the reference card for what full disclosure looks like in this category. Hold Mellum2, if it exists, to that standard. Hold every other coding model vendor to it too.
If the model card never comes, that is also an answer. JetBrains’ own product direction, with Air orchestrating Codex, Claude Agent, and Gemini CLI alongside Junie, suggests a company hedging toward model pluralism rather than betting the IDE estate on a first-party model. The durable takeaway survives either outcome: total parameter size no longer predicts serving cost, the burden of proof sits with whoever publishes the spec sheet, and an empty spec sheet is itself a spec.
Frequently Asked Questions
How does Mellum2’s claimed 12B active parameter count compare to DeepSeek-Coder-V2’s serving cost?
The research brief confirms no active parameter count for Mellum2 exists in any verified source, making direct cost comparison impossible. DeepSeek-Coder-V2’s MoE architecture allows it to rival GPT-4-Turbo while maintaining lower serving costs than dense models of similar quality, but without Mellum2’s specific active parameter disclosure, any cost projection remains speculative.
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.
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 languages demonstrates that broad coverage prevents degradation in production environments where narrow benchmark performance does not translate to practical utility across varied codebases.
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.
How does the lack of primary sources for Mellum2 affect vendor evaluation processes?
The absence of verified specifications for Mellum2’s architecture, licensing, and performance metrics means any evaluation based on circulating claims risks deploying unvalidated technology. Teams should establish a strict policy requiring primary source documentation for all model specifications before committing to deployment, using DeepSeek-Coder-V2’s transparent documentation as a benchmark for vendor disclosure standards.
