Diplodocus v0.1

Should you download it?

In short: Use it for paperwork, spreadsheets and money questions on your Mac, with reasoning turned on. Check anything important before it leaves your hands.

Diplodocus is for office and finance work: reading statements and contracts, fixing a total in a workbook, adding a line to an invoice, proofreading, filling in forms. You need Osaurus 0.25.21 or newer, and the model is a 6.94 GB download.

It has two modes:

• Reasoning on (the high setting). The model thinks before it answers. Use this for anything involving money.
• Reasoning off (the low setting). It answers straight away. Faster, but it gets money wrong far more often.

Do not use the medium setting. The reasons are explained below.

Three things to know before you rely on it:

• Check citations. It has invented legal citations. Verify every law, ruling or authority it names.
• Let it use the calculator. Without the calculator, its arithmetic is unreliable.
• Long documents are a stretch. Anything over about 7,000 tokens (roughly 5,000 words) is longer than anything it was trained on.

For general agent work on a smaller Mac, Raptor 0.6 runs on 8 GB, and Which model fits your Mac? shows what runs well on yours.

What it is

In short: A 9-billion-parameter model where every part of the model works on every word. It reads text only, and can in principle hold a very long conversation.

"Dense" means the whole model runs for every token, unlike a mixture-of-experts model that only wakes up part of itself. The base is named 7B, but counting the embedding table and the separate output layer it has 9.0 billion parameters.

Why K2-Horizon, and the plan we did not run

In short: We first wanted to shrink a much larger 36B model from the same family. The maths said we would have to cut away more than half of it, which risked its memory. Then we saw that its small 7B sibling scored almost as well on the test we cared about, so we started there instead.

The first plan was much more ambitious. K2-Horizon-MoVA-36B-A4B had the best business-agentic score we could find at its size, with a τ³-Banking of 26.8 against 9.3 for Qwen3.6-35B, and we wanted it in about 8 GB.

The arithmetic killed the casual version of that idea. A measured census put the model at 37.7B parameters, or 19.4 GB at about 4 bits per weight. Reaching 8 GB means cutting 58% of the whole model. Almost none of that can come from attention, embeddings or the output head, so the cut lands on the routed structures: keep about 32 of 100 routed experts and 16 of 64 MoVA value experts per layer.

Pruning at that depth has little precedent. Value experts are also what attention reads back from earlier positions, so a deep cut there goes straight at in-chat memory, the thing an office model needs most.

Then we read the sibling's model card. These are IFM's numbers, not ours:

The dense 7B was within a point of the 36B on banking before any pruning, with no surgery risk and room for more than 4 bits per weight. We wrote a rule to compare the two after an untrained prune sweep, then parked the prune and went to the 7B first. That sweep never ran, so we have no result on value-expert pruning either way.

We did not train against the card's benchmarks and did not re-run them. They are why we looked at this base, nothing more.

Measuring the base first

In short: Before training anything, we tested the untouched base model. Its memory for facts in a conversation was already good, so we set out to protect it rather than teach it. We also found that two of its three reasoning settings were broken in a way that swallowed the answer, so Diplodocus has only two modes: reasoning on and reasoning off.

Before writing a single training example we ran the raw K2-Horizon-7B through our test suites. Two findings shaped everything after.

Recall was already strong. Looking up exact lines in a statement scored 24/24 at both 4K and 16K tokens. Recall of facts stated earlier in the chat was 0.97, and keeping a correction the user had made was 0.92. So we treated memory as something to protect, not to teach.

The reasoning efforts were not what they looked like. The model's chat template offers high, medium and low. IFM's card says plainly that only high is recommended, and now we know why. When the model reasons, it ends the reasoning section with a special marker, a "close token". At the point where it should stop, the matching medium close token had a probability of around 1 in 10,000, while the high close token had 0.90 to 0.998. Software that only accepts the matching close token never sees the reasoning end. On the official SGLang chat route, medium and low returned an empty answer, because the answer had been swallowed into the reasoning.

Low turned out to be adaptive: an empty reasoning section on lookups and tool prompts, and short reasoning closed with the wrong marker on anything that needed computing.

So Diplodocus has two modes, not three. On is high. Off is low with an empty, already-closed reasoning section. We tried to teach Off through training for several rounds and it kept breaking. The fix that held was structural: our chat template writes the closed, empty reasoning section into the prompt itself, so the model starts directly in the answer and cannot break the markers. With reasoning off, the markers were intact in 488 of 488 tool tests and 90 of 90 arithmetic tests.

The tune

In short: We taught the model with a small, light layer of extra training rather than retraining it from scratch. Each round, we only added training examples to fix a failure we had actually measured. The final set is 11,177 example conversations. Three rounds went wrong, and they taught us the most.

The recipe stayed nearly fixed. It is a LoRA, a small add-on layer that adjusts the model without retraining all of it, at rank 16 and alpha 32. It covers all seven projections in every layer (query, key, value, output, gate, up and down), 252 places in all, at a learning rate of 6e-5. It makes one pass over the training set, starts from the raw base each round, and is merged into the model's weights at the end. What changed between rounds was the training data, and each addition answered a measured failure.

The final training set is 11,177 conversations and 1,429,578 trained tokens. R11 took about ten hours across two DGX Sparks. The reasoning in the examples was generated by the model itself rather than written by hand, because earlier work on other bases taught us not to train on reasoning shorter than the model's natural style. The actions are mostly written by hand, tool definitions come from the Osaurus source code, and workbook and document results come from a simulator that reproduces exactly what Osaurus's tools send back.

Where the training lands in the model matters. At R3's size, compressing to a test layout with 4-bit MLP layers changed 1.7 to 2.1% of the 8-bit attention bytes, but only 0.2 to 0.3% of the 4-bit MLP bytes. In other words, coarse rounding erases most of a small fine-tune. That is a large part of why this model keeps attention at 8 bits.

Three rounds that went wrong taught us the most.

R5 broke its own Off mode. We taught Off answers to start with a visible equation, so arithmetic would show some working. The first words of those answers looked exactly like the base model's natural reasoning, so it slipped back into reasoning. Tool scores were the best so far, but the markers broke. We removed that data in R6.

Most of our early gain was formatting. The base model sometimes writes the <ifm|tool_calls> opening marker twice when reasoning is off, in 31% of its tool calls in that mode. That is a habit of raw K2, not something we taught it. Once we taught the parser to treat a repeated opener as one and re-graded every build, preview 2's improvement fell from +0.120 to an insignificant +0.028, and preview 3's from +0.132 to +0.058. We had been measuring a model learning not to stutter. With reasoning on, gains on this test suite were small for every build, about +0.02. The parser fix now ships in Osaurus, and the numbers we report should be read with this in mind.

R10 taught something false. Reading transcripts of failures led us to audit our own workbook data. It claimed that a row inserted at the Total line was included in the totals, and that is wrong. We stopped the run at about update 62, dropped 35 conversations and rewrote them.

Money

In short: Doing sums in its head, the model was not good enough for money, and our early training made it worse. So Osaurus got a built-in calculator, and we taught the model when and how to use it. On long documents that took exact answers from 31 to 43 out of 60. That is real progress, and it still misses more than a quarter.

We set a hard goal here: on long documents, money should not be wrong. The measurements said mental arithmetic could not get there.

With reasoning on and no limit on output length, preview 3 got 103 of 150 finance answers exact, or 84% of the ones it finished. Percentages were 25/25 and depreciation 23/25. Loan amortisation was 1/25, with 22 of those running out of the 8,192-token budget. These were not loops. The model was expanding (1+r)^n by hand, digit by digit.

Training had made this worse, not better. On questions needing an answer exact to the cent, over documents of 6K to 16K tokens, raw K2 scored 0.633 and preview 3 scored 0.533, and preview 3 tended to avoid tools. With reasoning off and no tool, it was 0 for 20.

So Osaurus gained a built-in calculate tool, and we trained the model on it: when to call it, how to chain calls, how to recover from an error, and when not to call it at all. Every calculator result in those 1,429 training examples comes from the real calculator, byte for byte. Building those examples also turned up bugs in the pre-release calculator. round(1.005, 2) returned 1. 12 500.75 + 1 silently became 6010, because a space meant multiplication. 8 % 1200 returned 8, because % meant remainder rather than percent.

On deciding when to use the calculator, the score went from 0.72 / 0.62 (reasoning on / off) to 0.84 / 0.82. With the calculator actually running on long documents, answers exact to the cent went from 31 to 43 of 60 with reasoning on. Reasoning off stays at 17 of 60, so for money, use reasoning on.

The model rounds the way the document says and carries the rounded figure into the next calculation, so several calculate calls in a row are expected and not a loop. In the real Osaurus app, a long invoice took six model turns and five calculator calls and landed on the correct $283.71.

We also added training for asking. If a rate, year or jurisdiction is missing, the model should ask one focused question rather than state a year-dependent figure from memory. That behaviour is trained, not guaranteed. See the limits below.

Workbooks

In short: Testers said the model ruined spreadsheets. Much of that turned out to be Osaurus's tools, not the model: one tool rebuilt the whole file and lost its formatting, and some of our own error messages told the model to do exactly that. We trained what we could and fixed the rest in Osaurus.

Testers told us the model was bad with workbooks. A large sheet made it re-read the file until it was unusable, and a one-cell update lost the styles, column widths and filters.

Reading the Osaurus source explained a lot of this:

• file_edit already edited .xlsx files in place and kept everything. file_write rebuilt the file from scratch and lost it.
• Our training data used long tool descriptions, while the app always sends a shorter version. Every example carried the wrong text, plus 1.3K to 2K wasted tokens.
• Several of our own error messages told the model to regenerate the document with file_write, and the model did as it was told. In one test it turned a signed three-page lease into one page.
• With the osaurus.xlsx plugin installed, 16 of 20 single-cell updates went through a plugin save that writes out a stripped-down file. This reproduced the testers' report with their setup.

So some of this was never a training problem. We trained what we could: reading large files in bounded pieces, mode:"structure", set_cells, inserting rows, repairing formulas, and refusing to regenerate. We then stopped training on the plugin case (a planned R12) and fixed Osaurus instead. file_write now refuses to replace a workbook it cannot rebuild faithfully, cells starting with = become real formulas, and documents in /workspace are edited in place. Formulas that depend on an edited cell also drop their old cached value, so the model no longer reports the old total.

Results

In short: On 100 realistic workbook and document tasks, the model went from 59 to 70 completed with reasoning on, and from 51 to 70 with it off. It improved on nearly every measure we track. It still missed several of the pass marks we had set ourselves in advance, and we shipped it anyway because it was clearly better than the previous build.

These tests use examples the model never trained on, run at the settings Osaurus uses: temperature 1.0, top-p 0.95, and the pre-filled Off mode. They were run on the full-precision BF16 model, not on the compressed downloads. E1 runs real tool loops against our simulator, and the differences between the simulator and the app are a known limit.

How to read the table: each cell shows reasoning on / reasoning off. Higher is better, except for the rows about repeated calls, file damage and non-existent tools, where lower is better. Preview 3 is the build before this one.

Read the last row with the formatting finding above in mind: preview 3's +0.132 falls to +0.058 once the repeated-opener rule is applied to both sides.

By task, E1 with reasoning on / off: PDF questions 12/12 both, proofreading 10/10 and 9/10, fixing a wrong total 6/8 and 8/8, PDF forms 4/8 and 8/8, inserting a line 7/8 and 2/8.

v0.1 failed some of our own gates. Before each round we write down the pass marks in advance. R11 missed several of the strict ones: small general test suites, how often it skips the calculator when it should use it, the minimum for tool decisions with reasoning on, and the E1 margins. We shipped it anyway because it beat preview 3 on every measure that reflects the real app, with no broad regression. That was a judgement call, and we would rather say so than leave it out.

Quantization

In short: To make the model small enough to download and run, we store its numbers with fewer bits, which loses a little detail. We spent the bits where measurements said they mattered most, not where convention puts them. At the same 6.94 GB, that cut the difference from the full-precision model by more than half.

The download uses JANG affine mixed precision: different parts of the model get different numbers of bits. It was calibrated with AWQ and GPTQ on 3.3 million tokens:

About 40% of the calibration tokens are the model's own work, generated across 60 kinds of task with Osaurus's current tool definitions. About 30% are general text, and the rest are examples from the training data.

Two findings are worth passing on.

One tensor can sink a model. Our first build used 4-bit weights with a Hadamard rotation. Compared with the full-precision model on Osaurus conversations, it scored a KL of 0.140 and 69.9% top-1 agreement (both explained below). Every per-layer measurement said it should be fine. Only swapping in one layer at a time and re-measuring found the cause: model.layers.1.mlp.down_proj, a single matrix with a few very large values the format could not hold, accounted for essentially all of it. Keeping that one matrix at 8 bits, with more bits in the MLP layers around it, took the build to 0.007 and 92.1%.

We had been spending bits out of habit. Convention keeps the embeddings and the output head at 8 bits, and with a 250K-word vocabulary those two tables are expensive. For v0.1 we measured each part of the model at each bit width with the same metric. Moving the head from 8 to 6 bits cost 0.0006, and moving the embeddings cost 0.002, because embedding error here mostly reflects how sensitive the model is to any small change in its input. That freed 514 MB. We then spent that budget one step at a time on whichever MLP part gave the most improvement per added byte.

To compare builds we ran each one and the full-precision model on the same 646,927 positions of held-out text and compared their predictions:

• Top-1 is how often both pick the same most likely next token. Higher is better.
• KL measures how much the whole spread of next-token probabilities changed. Lower is better.
• Call/answer flips count how often, out of 430 decisions, the compressed build called a tool where the original answered, or the other way round.

The first row is a floor: the full-precision model with the smallest possible change to its embeddings. Even that moves a few predictions, so no build can reach zero.

The same size, with the bytes in different places, cut median KL by more than half. These are diagnostics of the compression on data like the training data, not a task benchmark. In the real Osaurus app, 14 of 14 test requests finished cleanly, with prompts tokenized exactly as the reference tokenizer does.

For llama.cpp, the GGUF files were laid out the same way, with attention raised to Q8_0 in the smaller files:

Speed

In short: On an M5 Max it writes about 64 to 78 tokens per second (a token is roughly three-quarters of a word), slower during long sustained work. We tried two ways to speed it up further and neither helped on the Mac.

Plain decoding on an M5 Max ran at 64 to 78 tokens per second in single-request tests of this build (one sample each, not a benchmark). In a live app session on preview 3 we saw 50 to 75, with the GPU clock falling from around 1.4 GHz to about 1 GHz on long runs. Expect the lower end during sustained work. A dense 7B model reads every weight for every token, and at full clock this one sits close to the limit of the Mac's memory bandwidth.

Speculative decoding did not earn a place. In speculative decoding, a fast helper guesses several tokens ahead and the full model checks them all at once. We evaluated IFM's Uno, an elegant lossless diffusion adapter that needs no separate model, and a DFlash 2 drafter we trained ourselves. Our fine-tune and compression did not hurt Uno's acceptance (2.52 tokens per cycle, against 2.50 on raw K2), and it reached 1.73x greedy speed on a DGX Spark in PyTorch. Our own DFlash drafter managed only 1.90 tokens per cycle. But on the Mac, with exact checking, one paired run on preview 3 measured Uno at 69.6 tokens per second against 83.6 for plain decoding. So this download ships without a drafter.

Limits

In short: Check its legal and tax citations, let it use the calculator, and be careful with very long documents. It also talks more than it needs to, and it needs the full conversation history to work well.

Most of these come from our own testing. The last few came from real use after release.

• Do not rely on it for legal or tax citations. In a tester's session it invented legal citations, and a delegated writer put them into a letter to the IRS. Check every authority it names, and anything consequential, before it leaves your hands.
• Unaided arithmetic is unreliable. One invoice test without the calculator landed on $283.70, not $283.71. Money with reasoning off is 17 of 60 even with the calculator. Use reasoning on, and let it use the calculator.
• Documents over about 7K tokens are longer than anything it trained on. The 512K context comes from the base model and is not a tested promise. Expect it to pick wrong figures from documents of 10K to 16K tokens.
• New workbooks with live formulas were 2/8 with reasoning on and 3/8 off when measured. Osaurus has since changed how file_write stores formulas; we have not re-measured.
• Change requests on signed PDFs with reasoning on were 3/10. Off was 6/10.
• It narrates. It wrote a sentence before 55% of tool steps in fresh conversations, and before 89% when the prompt asked it not to narrate each step. That gets tiresome on a voice call. Sample sizes were small (4 per arm).
• It guesses when history is missing. If an app drops tool messages from the conversation history, it invents file paths: 8 of 8 samples with text-only history, 0 of 10 with full history. Keep tool history intact.
• It may call itself K2, and it may try a tool it remembers from earlier in the conversation that is no longer offered.
• It has no vision. Scanned pages with no text layer need another model.
• The training and calibration data have flaws. 1.7% of training examples carry unfilled template text in tool descriptions, and some calibration examples do too.

Downloads and usage

In short: Download it from the model list in Osaurus 0.25.21 or newer. Use high for reasoning on and low for reasoning off, never medium, and allow long answers.

The model runs in Osaurus 0.25.21 or newer. Download it from the model list. High is reasoning on and low is reasoning off. Do not send medium. Default sampling is temperature 1.0, top-p 0.95. Allow long outputs, because reasoning that gets cut off is a failed answer.

• Diplodocus v0.1 JANG_6M, 6.94 GB: Hugging Face
• Diplodocus v0.1 GGUF, 6.33 to 9.57 GB, needs llama.cpp with K2 Horizon support: Hugging Face

If you already downloaded Diplodocus preview 4, you have these weights. v0.1 is the release name for that build.

The base model, IFM/K2-Horizon-7B, is Apache 2.0, and Diplodocus inherits that license.

Notes on measuring

In short: Several of our early numbers were wrong because of how we measured, not because of the model. These are the checks that caught it.

• Check the scorer before you trust the score. An audit partway through found 11 bugs in our grading code. Later, the code that pulled the correct answer from each question took the first number in a headline, so 24 of 88 calculator answers were being graded against years and invoice numbers. We kept the old files and re-scored from the saved answers.
• Check your limits. A 1,024-token cap on test answers cut off 18 to 30% of raw K2's reasoning-on answers, which made its low effort look as good as high. An answer that was cut off is not a wrong answer.
• Test at the settings people use. Always picking the single most likely token showed repetition loops on preview 3 (4 on, 2 off) that nearly vanished at the real sampling settings (0 on, 2 off).
• Separate the model from the app around it. Replaying a bad voice session on the same weights showed that re-checking files and invented paths came from history the phone app had dropped, and that a missing hand-off to another agent came from a tool that surface never offered. The chattiness and the invented citations were the model.
• Numbers trace back to their source. Benchmark tables from the K2 card are IFM's and labelled as such. KL figures use held-out data that was not used for calibration. Single-sample figures are called single samples.

Citation

@misc{osaurus2026diplodocus,
  title  = {Diplodocus v0.1: an office model for your Mac, built on K2-Horizon-7B},
  author = {Osaurus},
  year   = {2026},
  url    = {https://osaurus.ai/models/diplodocus}
}

Glossary

• Token: the unit a model reads and writes, roughly three-quarters of an English word on average. Speeds are given in tokens per second.
• Parameter (weight): one of the numbers a model learned during training. Diplodocus has 9.0 billion of them.
• Dense model: a model where every parameter is used for every token, unlike a mixture-of-experts model that only runs part of itself.
• Base model: the model we started from, here IFM's K2-Horizon-7B. "Raw K2" means the base before our training.
• Fine-tune: extra training that adapts an existing model to a job. LoRA is a light form of it that trains a small add-on instead of the whole model, then merges it in.
• Training data (corpus): the example conversations the model learned from.
• Reasoning on / off: whether the model thinks before answering. On is the high setting; off is low with an empty reasoning section.
• Close token: the special marker that ends the model's reasoning section.
• Tool call: the model asking Osaurus to run a tool, such as reading a file or using the calculator, and getting the result back.
• Chat template: the exact format a conversation is written in before the model reads it.
• Simulator: a program that imitates Osaurus's file tools so we can test many tasks quickly without the app.
• Held-out: test data the model never saw in training or calibration.
• Quantization: storing each weight with fewer bits so the model is smaller. Like saving a photo at a lower quality setting: a much smaller file, with some detail lost.
• Bits per weight: how much storage each weight gets. The full-precision model uses 16; most of Diplodocus uses 4 to 8.
• BF16: the full-precision, uncompressed version of the model. Every quality comparison on this page is against it.
• JANG_6M: our mixed-precision format for MLX on Apple Silicon, where each part of the model gets its own bit width.
• GGUF: the file format used by llama.cpp. Q4_K_M, Q6_K and Q8_0 are GGUF compression levels, from smallest to largest.
• Calibration: showing the compressor example inputs so it knows which weights matter most.
• AWQ and GPTQ: two calibration methods. AWQ protects the most important input channels; GPTQ rounds weights one column at a time and adjusts the rest to make up for the error.
• Hadamard rotation: a simple, fixed transform that mixes a block of numbers evenly, spreading out any unusually large value.
• KL divergence (KL, KLD): how much the full set of next-token probabilities changed between two models. Zero means identical; lower is better.
• Top-1 agreement: how often two models pick the same most likely next token.
• Speculative decoding: a fast helper (a drafter) guesses several tokens ahead, and the full model checks them all in one pass. The output is the same; it only changes speed.
• τ³-Banking, SWE-bench, Terminal-Bench: public benchmarks for banking agent tasks, fixing real code, and working in a terminal.
• GB: model and download sizes on this page are in gigabytes.