Certo v1

Certo v1 is a 0.4B-parameter dense encoder from AltSlate Labs that does not generate text. It scores options. Given a state and a list of candidate actions described in text, it returns a calibrated probability for each option in a single forward pass. That distinction matters more than the parameter count: this is a decision model, not a chat model, and it occupies a category that almost nothing else in the open-weights ecosystem fills.

The backbone is ModernBERT-large with a per-option query/scoring head bolted on. Each option is scored independently against the state, which makes the model order-invariant by construction — shuffling the option list cannot change the output distribution. That's a property most small LLMs used for routing do not have, and it's the kind of thing that quietly breaks production classifiers.

What makes Certo v1 interesting is how it was trained. AltSlate built a synthetic world with a known correct answer and trained the model against the exact posterior using soft, distributional targets — 60k examples, 25 epochs. Calibration isn't a post-hoc temperature fit here; it's the training objective. The held-out numbers reflect that: ECE of 0.004 on unseen options, 0.003 when presented with 8–10 options despite training only on 3–6.

The honest caveat, stated plainly by the authors: it does not transfer to arbitrary natural-language prose yet. On real free text it tends toward a near-uniform distribution and abstains. Treat it as a research preview and a reference checkpoint, not a drop-in triage system.

• Parameters: 0.4B, dense — every parameter is active on every forward pass
• Backbone: ModernBERT-large encoder
• Head: per-option query/scoring head, options scored independently
• Modality: text-only
• License: MIT
• Context length: not specified in the model card
• Training cutoff: not specified

Dense at 0.4B means there's no routing overhead and no expert-selection latency — inference cost is flat and predictable. For a scoring model this is the right tradeoff. You want deterministic latency per request, not a MoE whose active-parameter count varies with the input.

The per-option scoring head is the architecturally significant part. Rather than concatenating state and options into one sequence and asking a decoder to pick, Certo encodes the state once and queries each option against it. Two consequences follow. First, order invariance is structural, not learned — the model card reports exact 0.00 KL divergence under option reordering. Second, adding options scales the head linearly while the state encoding is amortized, so 10-option decisions cost far less than 10 separate forward passes through a generative model.

Context length is not documented. ModernBERT as an architecture supports long sequences, but AltSlate has not published the configured value for Certo v1, so plan around short, structured inputs — the in-distribution format is option "profiles" of the form "typically attribute value, …".

Certo v1 is excellent at one thing: assigning calibrated probabilities to a small set of discrete options when the state and options are expressed in the structured, profile-style format it was trained on. It generalizes to new prototypes, new names, new wording, and option counts it never saw — 84.4% accuracy on unseen options and 76.0% when the option list grows to 8–10.

Concrete places this fits:

• Rule-following evaluation. The certo-decisions-v2 dataset shows the shape: return-policy thresholds, lending conjunctions, program-verified labels. If you're building a harness that checks whether a system applies a stated policy correctly, Certo gives you a probability rather than a token.
• Synthetic data pipelines. When you generate structured decision data with a known ground truth, you need a scorer that reports confidence honestly. A generative model will produce a plausible answer with no notion of whether it's right.
• Calibration research and benchmarking. ECE of 0.003–0.004 on held-out structured inputs is a useful reference point for comparing calibration techniques.
• Abstention-gated routing prototypes. The abstain_below threshold is a first-class parameter. On out-of-distribution free text the model returns near-uniform probabilities and abstains — a safe failure mode you can build a fallback around.

What it is not for: real prose. If your states are "The customer said they were unhappy and want a refund," Certo v1 will not route that. The authors are explicit that handling real language is the v2 goal, via real data plus a paraphrase layer.

VRAM is a non-issue. At 0.4B parameters the weights are small enough that this model runs on hardware you already own — including CPU-only.

Add roughly 200–500 MB for activations and the scoring head at typical batch sizes. A 4 GB GPU is comfortable. So is a laptop.

• Any modern consumer GPU — RTX 3060, 4060, 4090, all trivially sufficient. The 4090 will be bottlenecked by Python overhead, not compute.
• Apple Silicon — M1 through M4 Max, any variant. Runs on the Neural Engine via Core ML export or on the GPU via MPS.
• CPU-only — entirely viable. An encoder this size does a forward pass in tens of milliseconds on a modern x86 or ARM core.
• Edge devices — a 0.4B encoder is within reach of Jetson-class hardware and even high-end mobile SoCs.

There is no published GGUF or official quantized release. The model card specifies library_name: pytorch and the supported path is infer.py from the certo repo. If you want INT8 or INT4, you'll be exporting it yourself — ONNX Runtime and PyTorch's dynamic quantization both work well for ModernBERT-class encoders. Validate against the reported ECE numbers after any quantization; calibration is the whole point of this model, and quantization is exactly the kind of change that degrades it silently.

Don't measure this model in tokens per second — it doesn't generate tokens. Measure decisions per second. On a mid-range GPU you should see hundreds to low thousands of state-option scoring passes per second at batch, depending on option count. On CPU, expect single-digit to low-double-digit milliseconds per decision. The state encoding is amortized across options, so scoring 10 options costs meaningfully less than 10× scoring one.

Ollama is the usual quickstart for local models, but it isn't the natural fit here — Ollama serves generative models, and Certo v1 is a non-generative scorer with no published Ollama manifest. The actual path is PyTorch:

1from huggingface_hub import snapshot_download
2from infer import DecisionModel
3
4m = DecisionModel.load(snapshot_download("altslate/certo-decision-model"))
5r = m.decide(
6    state="We measured salinity as ember, tempo as gale, density as gale.",
7    options=[{"id": "A", "description": "typically salinity ember, tempo gale, density gale"},
8             {"id": "B", "description": "typically salinity dawn, tempo frost, density brine"}],
9    abstain_below=0.6)
10r["probs"]

If you want an HTTP service, wrap that in FastAPI — the model is small enough that a single worker handles substantial throughput.

vs. Qwen3-0.6B. Similar parameter count, completely different tool. Qwen3-0.6B is a generative decoder that handles arbitrary natural language and can be prompted to output a choice. It has no calibrated probability output, no order invariance, and no abstention mechanism — you'd be parsing logits and hoping. Choose Qwen3-0.6B when your inputs are real prose and you need generation. Choose Certo v1 when your inputs are structured and you need a trustworthy probability.

vs. ModernBERT-large (base). Same backbone, different head and training regime. Base ModernBERT is a general encoder you'd fine-tune for classification or retrieval; it's not calibrated out of the box and doesn't do per-option scoring. Certo v1 is the specialized version of that architecture for the decision-scoring task, with calibration baked in. If you're fine-tuning on your own labeled decision data, start from base ModernBERT. If you want calibrated option scoring on structured inputs without training, start here.

The tradeoff across all three is the same: Certo v1 buys you calibration and order invariance at the cost of handling only the input distribution it was trained on. That's a narrow window, but within it, nothing else at this size does the job.