small-active agent model
Raptor V1
A Small-Active MoE Built to Actually Drive a Mac
A 26B mixture-of-experts that activates only ~4B parameters per token, fits a 16 GB Mac at 13 GB, and passes more of the Osaurus agentic suite than models built for the same slot — while decoding 3x faster than a 12B.
26B
Total parameters
~4B
Active per token
13 GB
Fits 16 GB Macs
96.3
Tokens per second
Most local models make you choose. Small enough to leave resident on a Mac, or good enough to trust with an agent loop — rarely both. Raptor V1 is our answer to that trade: a 26B-parameter mixture-of-experts model that activates only ~4B per token, quantized to 13 GB so it fits on a 16 GB Mac with room to work.
The property we care about most is recovering when a tool call goes wrong. Real agent work is not a clean run of successful calls — it is a bad path, a read-only file, a malformed payload, and what the model does next. On the recovery tier of Osaurus's agentic suite Raptor V1 passes 15 out of 15, where a 12B manages 6 and a 9B manages 8. That is the difference between an agent that keeps going and one you have to babysit.
Every model ran the same tasks at its own recommended sampling settings. Tasks are verified against the filesystem, so a model that reports success without doing the work fails.
Bars are scaled within each section; labels carry the measured value. Raptor V1 is a mixture-of-experts model, so it holds 26B parameters but only activates about 4B per token — which is why it decodes fastest while carrying the most capacity.
What it is
Raptor V1 is built on Gemma 4 26B-A4B, Google's mixture-of-experts release, and re-quantized with our own dynamic mixed-bit pipeline. It is a text-and-vision model: it reads images, drives tools, and runs multi-step agent loops. Audio and video paths are stripped — they cost gigabytes and Osaurus doesn't route to them.
The important number is not 26B, it's ~4B active. In a mixture-of-experts model only a fraction of the network runs per token, so decode speed tracks the active parameters while quality tracks the total. That is the whole reason this model exists in this slot: you get the capacity of a 26B model at roughly the per-token cost of a 4B one.
Built to fit 16 GB
Quantizing an MoE well is not the same as quantizing a dense model, and the standard 4-bit recipes get it wrong in a specific way.
We allocate bits per projection rather than uniformly:
| component | bits | why |
|---|---|---|
| attention (q/k/v/o) | 8 | where cross-turn reference lives; the first thing to protect |
| router | 8 | picks the experts; errors here cost far more than they save |
gate_proj | 4 | the activation gate — the dominant sensitivity in an MoE FFN |
up_proj / down_proj | 2 | the bulk of the weights, and the most tolerant |
| embeddings (262k vocab) | 8 | tied to the output head |
Common public 4-bit conversions of this model put attention and the embedding table at 4-bit and land near 15.6 GB. Ours holds attention at 8-bit and lands at 13 GB — with 8-bit precision exactly where it matters. Against the stock 4-bit conversion of the same weights it is 5 GB smaller and 13% faster.
Two details that only show up at this scale. Affine quantization stores a scale and bias per group in fp16, and that overhead does not shrink with bit width — at a group size of 32 a "2-bit" tensor really costs 3 bits on disk. Moving to a group size of 64 halved 2.85 GB of pure metadata, and did more for the final size than any change to the bit widths themselves. And the boundary layers (the first two and last two) keep their higher precision, because those are where low-bit damage shows up first.
How it performs
Measured on Osaurus's own agentic task harness, running on an M5 Max with 128 GB of unified memory — real filesystem verification, not string-matching a model's prose. A model that claims it wrote the file and didn't, fails. Every model ran the same tasks at its own recommended sampling settings, five times each, because single runs on a task set this size swing by ±2 cases and will happily tell you three models are tied when they aren't.
| Ornith-1.0-9B | Gemma-4-12B | Raptor V1 | |
|---|---|---|---|
| Agentic tasks passed (55 trials) | 24 | 31 | 38 |
| Pass rate | 43.6% | 56.4% | 69.1% |
| Median wall time per run | 97.9 s | 138.4 s | 81.5 s |
| Bundle size | 9.5 GB | 12.7 GB | 13 GB |
| Decode speed | 56.4 tok/s | 32.2 tok/s | 96.3 tok/s |
Raptor V1 passes 69.1% where a 12B passes 56.4% and a 9B passes 43.6% — and it does it while decoding 3× faster than the 12B and 1.7× faster than the 9B.
Where it separates most clearly is error recovery. When a tool call fails for a real reason — a bad path, a read-only target, malformed input — the model has to read the failure and change approach rather than resend the same call.
| recovery task (5 trials each) | Ornith-9B | Gemma-12B | Raptor V1 |
|---|---|---|---|
| malformed input | 5/5 | 1/5 | 5/5 |
| read-only target | 1/5 | 5/5 | 5/5 |
| wrong path | 2/5 | 0/5 | 5/5 |
| recovery total | 8/15 | 6/15 | 15/15 |
Fifteen out of fifteen. Neither reference model manages half that, and each fails a different one — the 12B can't recover from a wrong path at all, the 9B can't handle a read-only target. In an agent loop this is the difference between recovering and burning the step budget on a resend.
It also holds restraint — knowing when not to act — at 14/16, and it is the only model of the three that ever completes the file-migration task (against zero for both).
It is weakest on multi-stage pipeline work: cross-referencing two sources passes just 1 time in 5, where the 12B manages 5/5. Those tasks need every clause carried to the end, and it drops one often enough to matter. We would rather name that than let you find it.
What the comparison videos show
Three tasks, same folder contents, each model given the same prompt, all recorded in Osaurus on an M5 Max (128 GB).
“Count the lines in input.txt and write the number to count.txt. The file may not be where you first look.” The file is one directory down from where you would first look.
“config.json is supposed to be valid JSON but something is wrong with it. Fix it so it parses, keeping the same host and port values.” A trailing comma — and the values have to survive the fix.
“Every .cfg file in old/ needs version bumped from 1 to 2 and moved into a new folder called new/, keeping its filename. Leave old/ empty but present.” Four clauses, all of which count.
Every clip begins the instant the prompt is sent. A model that finishes early holds its final frame until the slowest one is done, then all three restart together — so the gap you are watching is real elapsed time, not editing.
Wrong path. input.txt is one directory down from where you would first look. Raptor V1 searches, finds it, writes the count. Gemma-4-12B passes this 0 times out of 5 — it guesses paths, gets a failure, and guesses again.
Malformed JSON. A trailing comma, and the fix has to keep host and port intact. Gemma-4-12B passes this 1 time in 5 in the harness. Ornith-9B passes it consistently under the harness but stalls out in the recorded run without recovering — recovery at that size is brittle, and holding under one set of conditions is not the same as holding under yours.
Multi-file migration. Bump a version, move three files, keep the filenames, leave the source folder present. Four clauses. Raptor V1 is the only one of the three that ever finishes it.
In the second and third clips, Gemma-4-12B does not fail quickly — it stalls. On the JSON repair it runs for 84.7 seconds against Raptor V1's 11.2 — seven and a half times longer, to arrive nowhere. That is the point worth watching. A model that is bad at recovery does not stop when a call fails; it re-sends, re-guesses, and burns its step budget until the loop is cut off. Enabling its reasoning mode does not resolve this: the failure is not that it lacks a plan, it is that it does not let the failed result change the plan. What you are watching is an agent loop that cannot exit.
This is also why we treat recovery as the headline number rather than raw task completion. A model that finishes 60% of tasks and cleanly reports the other 40% is usable. A model that finishes 55% and hangs on the rest is not.
The first of a mixture of models
Raptor V1 is the first release in what will become a mixture of models — a set of specialists Osaurus routes between rather than one model asked to be everything. A coder is planned, and a dedicated VL/OCR model; Raptor V1 already carries vision, but reading a dense scanned document well is a different job from driving an agent loop, and a model built for the second is not automatically good at the first.
Raptor V1's role in that set is orchestrator: hold the session, plan the work, call the tools, recover when a call fails, and hand off the specialist jobs when there are specialists to hand them to. That is why it is tuned around agentic behaviour and recovery rather than raw benchmark breadth, and why we would rather it be fast and disciplined than encyclopaedic.
What it's for
Raptor V1 is a serving model, not a leaderboard model. It is built for the case where Osaurus keeps a model resident on your Mac all day: answering, calling tools, driving multi-step work, and getting out of the way. On a 16 GB machine it leaves headroom for the rest of your system. On anything larger it leaves headroom for a second model.
Good fits: agent loops and tool calling, file and shell work, long multi-turn sessions, screenshot-driven tasks, anything where latency is felt because a person is waiting.
Less good: heavy code generation, and knowledge-intensive questions without retrieval. It is a fast, disciplined operator — not a reference library.
Notes
- A stop-token correction ships with this build. As released upstream, one config file omitted the tool-response token from the model's stop set. A runtime reading that file would not stop when the model asked for a tool result — it would carry on and invent the result itself. Raptor V1's configuration is corrected and internally consistent.
- Numbers are reproducible. Every figure above comes from Osaurus's own agentic harness on an M5 Max (128 GB), five runs per model, each model at its own recommended sampling settings. We publish the per-run spread rather than the best run.