Mellum2.1 Coding Agent Guide: Local Setup and Repository Evaluation

Mellum2.1 is JetBrains' open model for coding agents and related language tasks. Its release focuses on post-training for repository work: exploring files, making changes and checking results. For a team evaluating it alongside Qwen or other Chinese coding models, a controlled repository task provides more useful evidence than a broad model ranking.

The JetBrains announcement and reviewed model card describe the architecture and serving path. This guide has not run an independent repository benchmark.

Mellum2.1 architecture and serving requirements

The model has 12B total parameters and 2.5B active parameters. It is a mixture-of-experts architecture with a native context length of 131,072 tokens, according to the card. Active size describes the subset used during token processing; the total weight set still matters for memory planning.

At two bytes per parameter, 12B implies roughly 24GB of raw weight storage before context and runtime overhead. That is a capacity calculation, not a measured minimum GPU specification. Start with the precision and artifact supported by your serving environment.

Deployment choice	What it changes	What remains to be tested
Native weights with vLLM	Uses the documented serving pattern	Device fit, parsers and full agent loop
A GGUF artifact	Changes file format and possibly precision	Exact file, runtime support and answer quality
A smaller configured context	Reduces the initial context budget	Behavior on the actual repository task
Speculative decoding	Adds another acceleration component	Compatible artifact and verified runtime support

The main card describes GGUF builds and an MTP head as upcoming. A separate official GGUF repository was visible when checked, so inspect the specific artifact rather than relying on an older release sentence. The existence of that repository does not verify every desktop client's support or an MTP configuration.

Start the documented coding server

Use a compatible vLLM environment and confirm the hardware before loading the model. The card specifies a Qwen3 reasoning parser and a Hermes tool parser for tool-enabled serving. This example retains those settings while starting with a shorter context budget:

vllm serve JetBrains/Mellum2.1-12B-A2.5B-Thinking \
  --revision 92ddae9fc7665e9f801d141d2e5a6b2caf2460c4 \
  --host 127.0.0.1 --port 8000 \
  --max-model-len 8192 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser hermes

The general options are documented in vLLM's serving reference. This is a local baseline configuration, not a production access-control setup. Keep the revision and runtime version in the evaluation record.

Send a short request through the local compatible endpoint before connecting repository tools. Confirm that reasoning and final answer content are handled as expected by the client. If the response is truncated, inspect the output limit and finish reason before changing the model or prompt.

Then test a single tool call. The server's tool parser and the agent's executor have different jobs: one interprets model output, while the other reads or changes resources. Both need to agree on tool names and argument fields.

Connect repository tools with limited scope

Use a copy of a repository at a recorded commit. Begin with file reading and a task that has an independently checkable answer, such as identifying the function behind a failing assertion. This reveals tool-loop problems without granting broad editing scope immediately.

Next, allow a bounded patch. State the intended behavior, relevant tests and files that should remain outside scope. Require the agent to report which commands ran and what they returned. A final claim that “tests pass” is meaningful only when the corresponding execution result exists.

Do not let a model-generated command expand the permission boundary. The application should decide which tools and paths are available. Local model serving also does not make external tools local; a search plugin or remote service remains another data destination.

For a practical pilot, keep dependency installation and deployment outside the agent's ordinary task tools. That makes it easier to judge whether the model solves the coding problem rather than changing the environment until a test appears green.

Evaluate edits and verification behavior

Use a small set of tasks covering the repository's real work: a logic fix, a missing validation case, a narrow refactor and a question requiring multiple files. Each task should have an acceptance rule prepared before the run.

Record patch scope, test outcomes, retries and completion time. Also inspect whether the agent uses evidence from the files it reads. A change that passes one test but breaks the requested behavior should remain a failure in the evaluation ledger.

Keep task prompts and tool access consistent across model comparisons. JetBrains reports benchmark and speed results under its own evaluation conditions. Those are useful context for the release, but they do not establish results for another repository, tool harness or GPU.

Separate response quality from execution behavior. The model may propose the right fix while the client fails to apply it, or the tool loop may work while the patch is incorrect. Recording both helps identify what actually needs changing.

Compare total task time with Qwen alternatives

Tokens per second only describe part of a coding session. Time spent reading context, deciding on a tool, running tests and correcting mistakes can dominate the total. Compare complete accepted tasks instead of only the speed of a short generated explanation.

If your current route is Qwen, our local Qwen coding guide provides a separate deployment reference. Use the same repository tasks and acceptance criteria while respecting each runtime's template and configuration.

Measure memory at the intended context and concurrency. A personal agent handling one request is a different workload from several parallel workers sharing a server. Test queueing before treating a responsive individual session as a team-serving result.

Conclusion: evaluate Mellum2.1 through repository evidence

Mellum2.1 is a candidate for local coding work when its artifact and serving path fit your environment. Establish a short response, verify tool parsing and then measure bounded repository tasks. The reviewed model is Apache-2.0; retain the notices and check additional software used by the deployment.

Adopt the route based on accepted patches, verification behavior and total task cost. Those results provide a clearer decision than either active parameter count or a developer's benchmark headline.

Frequently asked questions

Is Mellum2.1 a 2.5B model for memory planning?

It has 12B total parameters and 2.5B active. Storage and residency planning need the total weight set plus other memory.

Does the tool parser execute commands?

No. It interprets model output. Your agent executor controls command execution and its permissions.

Are published speed gains guaranteed on my computer?

No. Measure your runtime, hardware, context and complete task loop. Published test conditions can differ materially.