MK4-Research/LOREA-cyber-v5.8

LOREA-cyber v5.8

Qwen3.6-35B-A3B with a LoRA merged in, 4-bit MLX. Mixture of experts, so about 3B parameters are active per token and it runs faster than the size suggests. No adapter needed at inference.

It reviews code for security problems. The thing it does differently from the base model is know when to stay quiet.

What changed

The base model is a strong analyst but it over-reports. Shown code that is correctly written, it claims a vulnerability about a third of the time. That makes it tiring to use, because you spend your time dismissing findings instead of fixing them.

This version was trained mostly to fix that. Roughly a third of the training data is code that is correctly implemented, where the right answer is "this is fine, and here is the control that makes it fine."

	base 35B	v5.8
finds planted bugs	91%	84%
false alarms on correct code	32%	9%
correctly clears correct code	32%	48%

Seven points of recall for a bit under a quarter of the false alarms.

On a hypothetical 100 files with 10 real bugs in them:

	bugs found	false alarms	share of findings that are real
base 35B	9.1	28.8	24%
v5.8	8.4	5.4	61%

Benchmarks

	v5.8
SecQA (n=210)	99.1%
CyberMetric (n=120)	94.2%
security MCQ, held out (n=150)	99.3%
MMLU-Pro (n=120)	55.0%
HumanEval (n=60)	100%
refuses harmful requests (n=60)	80%
wrongly refuses legitimate work (n=60)	0%

Two things worth saying about these.

The HumanEval number should not be read as "this model is a perfect programmer." HumanEval is old and almost certainly in the training data of any 2026 model. Read it as evidence that fine-tuning did not damage coding ability, which is the only claim it supports.

The base model was not re-measured on these benchmarks, so the scores cannot be split between what the base already did and what the fine-tune added. Most of the general capability is the base. The change that is clearly attributable to training is the false-alarm rate, which was measured on both. The same caveat applies to the refusal rate: Qwen3.6 already refuses harmful requests to some degree, and that portion was not isolated.

Prompting matters more than you would expect

During evaluation the system prompt changed the false-alarm rate by about six times on the same model and the same code:

prompt	false alarms
"Identify the security flaw, the invariant it breaks..."	60%
"Report any issues you can substantiate. If the code is correct, say so."	10%

Asking a model to identify the flaw tells it a flaw exists. Give it permission to find nothing.

Suggested system prompt:

You are a security code reviewer. Review the code and report any security issues you can
substantiate. If the code is correctly implemented, say so plainly.

Answer style

Answers are shorter than the base model's. It names the bug and usually explains the mechanism, but it does not always spell out remediation. If you want a fix every time, ask for one.

Example output:

The path traversal check is insufficient. It only looks for .. in the original filename, but traversal can still occur after URL decoding. A filename like ..%2F.. passes the check since it contains %2F, not .., but after unquoting it becomes ../... The check must run on the decoded path.

Running it

python3 -m mlx_lm.chat --model MK4-Research/LOREA-cyber-v5.8

Needs roughly 20 GB of memory at 4-bit.

Training

LoRA, 1200 iterations, learning rate 2e-5, rank 16, on 5,278 rows.

LoRA was attached only to the attention projections (q_proj, k_proj, v_proj, o_proj). This matters on a mixture-of-experts model: including the 256 expert MLPs produces 256M trainable parameters and runs out of memory immediately on a 32 GB machine. Attention only gives 1.03M parameters and fits in about 24 GB.

Other settings: batch size 1, gradient accumulation 2, gradient checkpointing on, sequence length 256.

Training data is published at MK4-Research/LOREA-cyber-training-data. It is decontaminated by 8-gram overlap against the evaluation sets.

What did not work

Three earlier attempts fine-tuned a 9B model to be a better analyst. All three failed, and one made the model measurably worse than the model it started from. The training data for that attempt was generated by a small model and was heavily templated. 99 of 99 rows in one file began with the same words, so the model learned the format instead of the reasoning and produced that format filled in with wrong content.

What eventually worked was the opposite approach. Rather than trying to teach analysis to a model that lacked it, take a model that already analyses well and teach it restraint. Restraint appears to be much easier to train than capability.

GGUF for llama.cpp

LOREA-cyber-v5.8-Q4_K_M.gguf in this repo is a llama.cpp build, 21.7 GB, 4.89 bits per weight. Needs about 24 GB of RAM.

llama-cli -m LOREA-cyber-v5.8-Q4_K_M.gguf -cnv --temp 0.5 --top-p 0.95 -c 8192

You need a recent llama.cpp. The architecture is Qwen3_5MoeForConditionalGeneration and converter support for it is fairly new, so older builds reject the file with an unknown-architecture error. Update rather than assuming the file is broken.

It is not a conversion of the 4-bit MLX weights above. That would mean unpacking 4-bit up to 16-bit and squashing it back down, stacking two rounds of quantization loss. The LoRA was merged into the original bf16 Qwen3.6-35B-A3B weights and quantized once instead. The merge arithmetic was checked against mlx_lm's own fuse() and matches exactly, and only the intended tensors changed.

The numbers in this card were measured on the MLX build, not on the GGUF, so I can't claim they transfer exactly. What was checked on the GGUF, in a fresh context: on a correct function using a parameterized query it answered "The code is correctly implemented... No security issues to report", and on a path traversal bug it found the bug and gave a working exploit path. So the restraint behaviour survived quantization on the cases tried. That is a spot check, not a benchmark.

Limits

It is a 4-bit quantized model and it will still be wrong sometimes. It misses about one bug in six on the internal benchmark. It has not been tested on large real codebases, only on snippets and small multi-file examples. Treat its output as a starting point for review, not a verdict.

Intended for authorized security work: reviewing code you own or have permission to assess, CTF practice, and teaching.

Related

• Benchmarks: MK4-Research/VAB-vulnerability-analysis-benchmark
• Training data: MK4-Research/LOREA-cyber-training-data
• Evaluation sets: MK4-Research/LOREA-cyber-eval
• Previous release: MK4-Research/LOREA-cyber-v5.5 (9B, different base)