Small open-weight models as coding sub-agents: reading the Mellum2.1 release
JetBrains released Mellum2.1, a 12B open-weight model built for coding sub-agents. What it claims, what to verify, and where small models fit.
JetBrains has released Mellum2.1, an open-weight model it describes as "built for coding agents and fast sub-agents that run on your own hardware." It is small enough to self-host on modest hardware and is licensed under Apache 2.0. For teams paying frontier-model prices for every step of every agent run, the release is a useful prompt to ask which of those steps actually need a frontier model.
What JetBrains released
Mellum2.1 is the next version of the Mellum2 model that JetBrains open-sourced in June. According to the announcement:
- It is a 12-billion-parameter mixture-of-experts model with 2.5 billion active parameters. The architecture is unchanged from Mellum2.
- It is released under the Apache 2.0 license, so it can be used commercially and run on your own infrastructure.
- Almost all the new work went into post-training, mainly reinforcement learning. JetBrains says it ran thousands of RL environments in-house and "launched millions of sandboxes over the course of training", with tasks in maths, competitive programming, science, tool use and software engineering.
- The goal was agentic work inside a repository: the model "explores a codebase, edits files, and checks its own changes."
The weights are published on Hugging Face as Mellum2.1-12B-A2.5B-Thinking. The announcement said that GGUF builds for llama.cpp, Ollama and LM Studio, and a multi-token prediction head for speculative decoding in vLLM, were coming soon; a GGUF repository from JetBrains has since appeared on Hugging Face.
What the numbers say
Speed
JetBrains reports that under heavy load Mellum2.1 serves "almost twice as many tokens" as Qwen3.5-9B, and that multi-token prediction makes a single request about 1.6 times faster. These are the vendor's own measurements. Throughput depends heavily on the serving stack, batch size and hardware, so treat them as a reason to test, not as a planning figure.
Quality
The blog post compares Mellum2.1 with Mellum2 and with two open models of a similar class, Qwen3.5-9B and Gemma 4 E4B, using the same evaluation setup for all of them. It says the largest gain over Mellum2 is in agentic coding.
The model card lists self-reported results, each marked as not verified. A few are relevant to coding agents:
| Benchmark | Reported result |
|---|---|
| SWE-bench Verified | 47.0% resolved |
| SWE-bench Pro | 28.0% resolved |
| Terminal-Bench 2.1 | 17.4% resolved |
| BFCL v4 (function calling) | 62.3% accuracy |
| LiveCodeBench v6 | 82.0 pass@1 |
Two things are worth noticing. First, the spread is wide: strong scores on self-contained coding problems, much lower ones on long, realistic repository and terminal tasks. That is typical of small models and it tells you where this one is likely to fit. Second, agent benchmark scores depend on the harness, the tools and the time limit as much as on the model. Numbers from a vendor's own setup are not directly comparable with a leaderboard that used a different one.
Analysis: where a small model fits in an agent
Most coding agents already split work into steps: search the codebase, read files, summarise a failing test, draft a change, run the tests, review the result. The steps are not equally hard. JetBrains positions Mellum2.1 for exactly this, as a worker that can handle "different parts of an agent's plan, from identifying the root cause of a failing test to drafting and checking a fix."
That suggests a practical division of labour:
- Good candidates for a small model: codebase search and summarisation, classifying or triaging failures, generating test scaffolding, first drafts of narrow changes, and checking a diff against a simple rule. These are frequent, short and easy to verify.
- Keep on a stronger model: planning across many files, unfamiliar or security-sensitive code, and anything where a subtle mistake is expensive and hard to spot.
The reported scores support that split. A model that resolves under a fifth of Terminal-Bench tasks is unlikely to be a good main agent for long, open-ended work, but it may be quite good at the many short steps that sit inside such a run.
Cost and control
The economics are the main reason to care. A sub-agent step often runs many times per task. Moving those calls from a metered frontier API to a self-hosted model turns a per-token cost into a fixed infrastructure cost, and it keeps code on hardware you control. JetBrains makes the privacy point directly: run it locally or on your own infrastructure "to keep code and data fully under your control."
The trade-offs are real, though:
- Operating cost. You now run inference: GPUs, serving software, scaling, upgrades and monitoring. For a small team the API may still be cheaper overall.
- Quality risk. A cheaper step that fails more often can cost more in retries, longer runs and reviewer time than it saves in tokens.
- License and provenance. Apache 2.0 is permissive, but your legal team will still want to know what the model was trained on and what the card says about intended use.
What it means for engineering and security leaders
Small open-weight models built for agent work are becoming credible for parts of the job. That changes the question from "which model do we use?" to "which model do we use for which step?". Answering it needs data most teams don't collect yet: which steps their agents run, how often, on which models, at what cost, and how often each step's output is accepted.
It also needs a way to change the answer without asking every developer to reconfigure their tools. If model choice is hard-coded in each person's setup, trying a self-hosted model for one kind of step means a rollout, not an experiment.
Practical takeaways for this week
- Pick one repetitive agent step, such as summarising failing tests, and run Mellum2.1 or a similar small model on a sample of your own real cases. Measure acceptance rate, not just benchmark scores.
- Compare the full cost of each option: tokens, retries and reviewer time on one side; hardware and operations on the other.
- Treat vendor speed and benchmark figures as self-reported until you reproduce them on your own serving stack.
- Keep planning and security-sensitive changes on your strongest model until your own evaluation says otherwise.
- Record which model answered each call and what it cost, so the comparison is based on your team's real usage.
Where SpanDock fits
With the SpanDock model proxy, in every plan, the server decides which model answers each call: with rules, such as sending Claude Code's Opus requests to Sonnet (Premium and up), or with SpanDock Mind, which chooses a cheaper model for a new conversation when it is good enough (Standard and up). Each call records the requested model, the model that answered, tokens and cost, and the Models page ranks the models your tools used by spend, speed, reliability or cost per million tokens.