nimbus-1-1-prime-ee

<p align="center"> <img src="https://huggingface.co/AhoosAI/nimbus-1-1-prime-ee/resolve/main/banner.png" alt="AhoosAI — Nimbus 1.1 Prime-EE" width="820"> </p> <p align="center"> <b>The first model of AhoosAI's own.</b><br> Better for everyone, not only for code.<br> <a href="https://ahoos-ai.site/news/int-pages/nimbus-1-1-prime.html">benchmarks</a> · <a href="https://ahoos-ai.site/models/">models</a> · <a href="https://ahoos-ai.site">ahoos-ai.site</a> </p>

---

Nimbus 1.1 Prime-EE

A QLoRA adapter for Qwen/Qwen2.5-Coder-7B-Instruct, trained on behaviour rather than on code the base model had already seen.

It is not trying to make the model a better programmer. The base is already a good one. It is trying to fix the things a good programmer gets wrong by habit: hardcoding dir="ltr", reaching for margin-left where margin-inline-start belongs, shipping a form control with no <label>, writing a Dockerfile that runs as root.

It answers in the language you wrote in, and it is at home in Persian — a right-to-left page that needs no fixing afterwards, and an answer that does not slip back into English halfway through.

Public benchmarks

Run with lm-evaluation-harness. Beside each model is the figure its own maker published.

These were not measured under the same conditions — every maker uses its own harness and its own settings — so read the tables below as context rather than as a ranking.

Our base publishes 88.4 on HumanEval and the same weights with this adapter scored 61.6 here. The two were taken differently: the published one asks the model as you would in a chat and reads the code out of its answer, ours asks it to continue a half-written function. A model tuned for conversation does worse at the second, adapter or no adapter. One run settles it — the same harness and the same settings with the adapter switched off — and until that exists, 61.6 is a number from this setup rather than a verdict.

IFEval reproduces exactly: 0.5231 and 0.6163 on two machines days apart, which makes it a property of the model rather than of the afternoon.

What it changes

105 tasks, each with a machine-checkable rule, run against the same base with the adapter switched on and off. Greedy, 400 new tokens, the production system prompt for each task. This one is a comparison — both sides, same tools, same day.

The gain is concentrated where the base was weakest — frontend went from 45% to 75% — and nothing moved at the ceiling, where a fine-tune that learned the wrong thing shows up first.

Ten tasks changed from fail to pass:

fe-rtl-logical-properties, fe-rtl-direction, fe-logical-inset, fe-accessibility, fe-image-alt, fe-form-label, fe-dialog-escape, be-docker-hardening, be-docker-nonroot, lang-spanish-docker

They are three behaviours, not ten: RTL and logical CSS, accessibility, and container hardening.

Known regression, stated plainly

Six tasks went the other way, and three of them are image-spec tasks — the one area with no training data behind it. The image behaviour set was deferred and the score shows the cost. Until image data is in the mix, expect this adapter to trade image-spec ground for frontend ground.

If image prompt/spec work is your use case, measure before adopting.

Also worth knowing

Both arms were capped at 400 new tokens and a good share of answers stop mid-sentence. The cap is shared, so the comparison holds, but the absolute pass rates are a floor rather than a measure of what either model can do.

The 105 tasks are this project's own suite, not a public benchmark. The full run — every prompt, every answer, every check, both arms — is published alongside the code so the numbers can be disagreed with.

Training

One epoch is measured, not assumed. Held-out loss over the run: 0.7029 at step 50, 0.6621 at 100, 0.6433 at 150, 0.6389 at 200, 0.6391 at 210. Each interval bought less than half of the one before it and the last ten steps bought nothing.

The public half is a regulariser, not a teacher — it keeps general coding ability from drifting while the behaviour rows do the work. It comes from bigcode/self-oss-instruct-sc2-exec-filter-50k (ODC-BY) and microsoft/orca-agentinstruct-1M-v1 (CDLA-Permissive-2.0), language-balanced across Python, C++, JavaScript, Java and TypeScript.

Use

from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
import torch

base = "Qwen/Qwen2.5-Coder-7B-Instruct"
tok = AutoTokenizer.from_pretrained(base)
model = AutoModelForCausalLM.from_pretrained(
    base,
    quantization_config=BitsAndBytesConfig(
        load_in_4bit=True, bnb_4bit_quant_type="nf4",
        bnb_4bit_compute_dtype=torch.bfloat16, bnb_4bit_use_double_quant=True),
    device_map="auto",
)
model = PeftModel.from_pretrained(model, "AhoosAI/nimbus-1-1-prime-ee")
model.eval()

It was trained under this system prompt and expects it:

You are Nimbus, built by Ahoos Model Studio. You write correct, complete, runnable code and explain only what the reader needs. State plainly when something will not work.

The adapter arm generates roughly 1.9x slower than the base at batch 1, which is the cost of the LoRA matmuls at every layer and not a defect.

Trademarks

Model names and figures above belong to their respective owners and appear for comparison only. Nothing here is endorsed by or affiliated with any of them.

---

Built by AhoosAI.