tablinum/cowork-companion

T

Tablinum

Cowork Companion

the office coworker that fits in RAM — 354M, one JSON envelope

Decks, sheets, documents, grounded refusal · llama.cpp · measured at every quant rung

Cowork Companion (354M)

Research background: The Dose-Window Hypothesis — the measured findings behind this model.

An office coworker distilled into a 354M-parameter model: it builds presentation outlines, edits spreadsheets and documents, answers strictly from provided material, and refuses when the material doesn't answer — all in a single JSON envelope, on a quantized GGUF that runs on a laptop.

It scores 1.000 on both frozen internal instruments (eval.v1, eval.v2) and passes real out-of-distribution files — and its walls are measured and documented below, not hidden.

Pick your rung — measured at every quantization

The same weights, four llama.cpp rungs, scored end-to-end on the frozen 210-item instrument (GGUF engine, 1024-token budget, greedy). This is the deployment truth — what llama.cpp users actually get per rung:

rung	file	size	eval.v8 overall (GGUF engine)
Q8_0	cowork-companion-350M-Q8_0.gguf	379 MB	0.7299
Q6_K	cowork-companion-350M-Q6_K.gguf	293 MB	0.6952
Q5_K_M	cowork-companion-350M-Q5_K_M.gguf	260 MB	0.7076
Q4_K_M	cowork-companion-350M-Q4_K_M.gguf	229 MB	0.5168

Engine honesty note: the 1.000 headline is measured with the training adapter on GPU (transformers). Serving the Q8 GGUF through llama.cpp shifts format fidelity (eval.v1 0.8700 at Q8) — small models have small format margins, which is exactly why the ladder above is published per rung instead of assuming quantization is free. Q8_0 is the recommended artifact.

File checksums (sha256)

cowork-companion-350M-Q8_0.gguf — d92425b6f586085757d891800a5cdf72b2666baf811e13cf1b533644fac9097e

cowork-companion-350M-Q6_K.gguf — 87a2dba0f72f8d5a5b55d365e5293d8cfadb5b8d4c8e281974f8df09f6178d64

cowork-companion-350M-Q5_K_M.gguf — ee1ff278f39e4b27f7fe0e339942653a0028f4bcbcaaf8fedd9bfbb5d61ea7e0

cowork-companion-350M-Q4_K_M.gguf — 710c9332ec73c32cadb53aba5eb350be7793daa1072db0107dd9d5ff611c51d3

The capability scoreboard

Seven production families, oracle-graded on a frozen 210-item instrument (eval.v8). Six families at or above 0.99:

instrument	score	what it is
eval.v1 (60 items)	1.000	frozen office-production bench, oracle-verified
eval.v2 (180 items, unseen variants)	1.000	generalization across topic/format variants
eval.v8 (210 items)	0.884	seven families incl. hard table aggregation
real OOD files	docx / pptx / refusal / ingest PASS; xlsx total exact (15,834.36) with the shipped --compute ledger	teacher-authored real documents, not synthetic

family	score
pptx_create	0.990
xlsx_build	1.000
docx_edit	1.000
doc_ingest	1.000
cross_doc_conflict	1.000
grounded_refusal	1.000
table_aggregation	0.200 ← the wall

Trained in, not bought with scale

Same instrument, stock bases — including its own base and a 3.4× larger model — are all near-chance on the office tasks. The skills live in the 3,258 training rows, not in the parameters:

The walls — measured, not guessed

• In-model arithmetic is a real floor at this scale. One-shot table aggregation: 3 rows → 1.000, 7 rows → 0.167. The product never asks the model to add: the CLI's --compute evaluates the sheet_spec formula ledger and prints exact totals even on total model failure. That is the "small model usable on a small device" design rule — route arithmetic to a deterministic harness.
• Full-document docx renovation on genuinely OOD real files is the residual format weakness at 350M (targeted dollar-format edits pass; the 1.2B sibling closes whole-document renovations).
• Grounded refusal discipline is trained, not prompt-hoped: null artifact, no invented digits — held at Q8 across runs.

Why pre-injection, not tool-calling — at this scale

We ran the A/B: identical 49-item premise bench, three access modes. At 350M, giving the model a retrieval tool costs 0.06–0.27 versus injecting the right fact into the prompt (0.327). The failure is not access, it's conversion — the model affirms despite the fact the tool returns. Only at 8B does tool-calling even begin to close:

Design consequence: the companion ships with facts pre-injected by the Tabula sidecar (below) and constrained decode, not with a tool loop.

Training — 3,258 rows: synthetic, teacher-distilled, with sourced selector exemplars

LoRA (r8/a16) on LFM2.5-350M-Base:

• 2,100 synthetic capability rows across the seven families
• 658 oracle-filtered traces distilled from LFM2.5-2.6B (598 docx edits + 60 xlsx; kept 658 of 1,250 drawn — every trace oracle-verified)
• 400 replay rows + 100 selector rows (2-shot demos; their 10 underlying facts are sourced from Qwen/RationaleRM (CC-BY-4.0), curated and normalized — attribution on the dataset page)

The exact corpus is published: cowork-companion-sft.

The lift curve this produced on eval.v1: base model 0.250 → first SFT arm 0.983 → 1.000 by arm 3 and held through v9. No external documents were used at any point; the only third-party content in the mix is the 10 CC-BY-4.0 selector facts and the LFM2.5-2.6B teacher traces, both attributed on the dataset page.

The method it ships with: Tabula, the fact sidecar

A 354M model will never know your tenant's policies. The answer is a fact-table sidecar — pinned documentation distilled to a few thousand statement-facts, retrieved per question, injected before generation. Zero training:

The knowledge half of the program is measured across scale — same bench, same retrieval, same injection. Correcting a wrong premise from world knowledge is the scale-bound half (a 354M will not do it alone — that is precisely why the sidecar injects the fact); the ladder shows where each engine lands once the sidecar is attached:

vertical (Microsoft Learn catalogs)	single-model score
Microsoft 365 — original bench	0.980 (0.959 at the strictest grader)
Microsoft 365 — blind holdout	0.90
PowerShell	0.829
SQL Server	0.878

Quick start, and in your apps

llama.cpp (reference path):

llama-server -m cowork-companion-350M-Q8_0.gguf --port 8080

Ollama — save as Modelfile, then ollama create cowork -f Modelfile:

FROM ./cowork-companion-350M-Q8_0.gguf
SYSTEM "<paste SYSTEM_PROMPT.txt from this repo>"
PARAMETER temperature 0

LM Studio — drop the GGUF into your models directory, set the system prompt from SYSTEM_PROMPT.txt, temperature 0.

Any OpenAI-compatible client (Open WebUI, your own code):

from openai import OpenAI
client = OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="local")
r = client.chat.completions.create(
    model="cowork-companion",
    temperature=0, max_tokens=1024,
    messages=[{"role": "system", "content": SYSTEM_PROMPT},
              {"role": "user", "content": instruction + "

" + document_text}])

Reply shape (always exactly one JSON object):

{"answer": "The Q3 total is 15,834.36.", "artifact": {"kind": "sheet_spec", "cells": [...]},
 "claims": [{"text": "Q3 total", "confidence": 0.99}], "overall_confidence": 0.99, "caveats": []}

Building an agent on top? Read AGENTS.md — the operational contract: envelope validation, the never-do-arithmetic rule, constrained decode, and refusal semantics. The full product path (constrained decode, exact --compute arithmetic, artifact rendering, the Tabula sidecar) is open source: the cowork CLI, github.com/chadstthomas-svg/cowork-cli.

Provenance

Every number above recomputes from frozen, committed instruments and saved generations (oracle-graded, shortcut-checked at 0.78–0.87 on the answerable-vs-unanswerable slice — under the 0.90 shortcut bar). Instrument hashes are published — INSTRUMENTS.sha256 pins exactly which frozen files every number was measured on; the instrument contents themselves stay unpublished to keep them uncontaminated.

License

Base weights are LiquidAI LFM2.5 under the LFM Open License v1.0 (see LICENSE): redistribution permitted with attribution; commercial use is licensed only for parties under the US$10M annual-revenue threshold.