Model launches
HIPAA-compliant mammoth-1 and elephant-1 decision models
Base Labs released two MIT-licensed decision models on October 21: a 27B and a 9B trained from Qwen3.5, returning calibrated probabilities instead of text
TL;DR
mammoth-1 (27B) and elephant-1 (9B) are open-weight decision models from Base Labs at Baseten, MIT-licensed and fine-tuned from Qwen3.5. They answer fixed questions with calibrated probabilities rather than generating text, and both are available under a signed BAA with zero data retention.
A hospital portal generates thousands of messages a day, and each needs a small decision before it needs a sentence: is this a refill request, does it belong to a clinician, does it mention a symptom that changes the urgency. Running those decisions through a generative model works, and costs far more than they are worth.
On October 21, 2026, Base Labs, the research team at Baseten, released two models built for exactly that layer. mammoth-1 is 27B parameters and elephant-1 is 9B. Both are open weights under the MIT license, both are full fine-tunes of Qwen3.5 checkpoints, and both return a probability for every answer option instead of writing prose.
They are the first open-weight decision models good enough to challenge a proprietary scorer. Today, both are available on our HIPAA-compliant design-partner program under a signed BAA, with end-to-end encryption and strict zero data retention. Because the license is MIT, that is a choice rather than a lock-in: you can use our endpoint or download the weights and run them yourself.
What are mammoth-1 and elephant-1?
Base Labs post-trained Qwen3.5-27B and Qwen3.5-9B into decision models. The pipeline is a full fine-tune, text only, with the vision encoder frozen. Attention uses a block-bidirectional mask on the full-attention layers, and the maximum sequence length is 16,384 tokens.
The interface is structured: you send a state and a set of typed
questions. noul is a yes or no with a
single probability. choice picks one of named options and returns a full
probabilities map. score rates the input on an ordered scale, lowest
first. All questions are answered from one shared-prefix prefill, so a
twelve-question intake form is not twelve forward passes.
One detail matters: requests longer than the trained length limits are refused, not truncated. Silent truncation is the failure mode that turns a classifier into a liability, because the model confidently answers a question it only half read. A hard refusal is easier to handle and easier to audit.
Both models are MIT licensed on Hugging Face as baselabs/mammoth-1
and baselabs/elephant-1. The base checkpoints are Qwen3.5 models, so
confirm the upstream terms as well before a commercial deployment; the
MIT tag on the fine-tune is not the whole licensing picture. At the time
of writing, Baseten is also serving both free for one week through its
Model APIs, with zero data retention on by default, through October 27,
2026 at 11:59 PM PT.
The calibration is the product
Most classifiers give you a label. These give you a label and a number that is supposed to mean something, and the training objective is where that comes from.
Base Labs trained on 6.21 million decision examples, a mix they call Mix 8: 58.3% core decision skills, 16.1% safety and abstention, 16.1% judging and expert domains, and 9.5% public decision data. The objective was cross-entropy plus a Brier calibration term with lambda set to 1, alongside a trained "I don't know" option. The model is penalized twice for a confident wrong answer: once for being wrong and once for the confidence itself.
The two runs differ in scale. mammoth-1 trained for one epoch over 9,859 steps at a peak learning rate of 2.7e-6 on 18 nodes of four GB300s, 72 GPUs in total. elephant-1 ran 5,546 steps at 3.5e-6 on 16 nodes of eight H100s. The recipe is otherwise the same, so the comparison below reads on size rather than tuning.
That calibration term is the reason a workflow can set a threshold at all. If 0.9 does not mean "right about nine times in ten on cases like mine", the threshold is decoration. The Brier term is an attempt to make it mean that.
How the two models compare
The headline ranking is on the Jev Decision Index 0.4, a third-party index, not a Baseten benchmark.
| Model | Jev Decision Index 0.4 |
|---|---|
| mammoth-1 | 71.24 |
| Perplexity Decider v1.2 | 69.42 |
| elephant-1 | 62.65 |
| Jev 1.14 | 62.20 |
| Cloudflare Clef | 55.70 |
mammoth-1 ranks first of the 208 models on that index. elephant-1 is the leading model under 15B and ties for eighth overall. On the public split, mammoth-1 leads in four of five areas, and elephant-1 beats Jev 1.14 in all five.
Baseten also reports a replica of the Artificial Analysis Decision Index. This is their own reproduction, not a score published by Artificial Analysis, and it should be read that way.
| Model | Baseten's AA Decision Index replica |
|---|---|
| mammoth-1 | 65.9 |
| elephant-1 | 65.2 |
| d1-ultra | 65.0 |
The gap between the two models is the interesting number. It is 8.6 points on the Jev index and 0.7 points on the replica. Two reasonable indexes disagree by more than an order of magnitude about how much the extra 18B parameters buy. Measure on your own cases before paying for the larger model.
Choosing between them
- Choose mammoth-1 when the decision needs knowledge. Complex clinical workflows, tasks, and classifications all depend on facts the model has to recall. The 27B is better at that and the Jev index is where the difference shows.
- Choose elephant-1 when the decision is simple and needs to be made quickly. Urgency of response, message sentiment, and guardrail checks depend on the text in front of the model, not on stored knowledge. At 9B it is cheaper to serve and easier to fit on a single GPU.
- Choose neither for a decision that needs an explanation. If you need to read the rationale for every output, consider using an LLM.
Where they fit in a healthcare workflow
The pattern that makes these models useful is not classification for its own sake. It is the threshold.
Take prior-authorization intake. A packet arrives, gets OCR'd, and needs five determinations: which payer, which service category, whether clinical documentation is attached, whether the request is urgent, and whether it is a duplicate. Today that is either a rules engine that decays every time a payer changes a form, or a generative call per packet. A decision model answers all five in one pass and returns a probability for each. Above 0.9, route automatically. Between 0.7 and 0.9, route but flag for sampling. Below 0.7, send to a person with the distribution attached. The threshold is a policy decision your compliance team can actually review, which is more than can be said for a prompt.
The same shape applies to portal triage, agent tool-call gating, and second-reader checks on drafted responses. None are clinical judgments (word of warning: builders should be careful that any use of these decision models don't take you into Software as a Medical Device territory!).
Limitations to keep in mind
- 16,384 tokens is a short document. A full chart, a long thread, or a complete packet will likely not fit. Chunking reintroduces the aggregation problem the decision model was supposed to remove.
- Text only, and the vision encoder is frozen. Scanned faxes need OCR before they reach the model, and OCR errors become decision errors with no way to trace them through a probability.
- 16K is the trained length, and longer requests fail closed. That is safer than truncation, but it means your application has to handle refusals as a normal path, not an exception.
- The indexes are decision benchmarks, not clinical validation. A high Jev score says the model makes good general decisions. It says nothing about whether it is right on your population, your payer mix, or your coding conventions.
- Abstention has to be designed for. The "I don't know" path only helps if your application treats it as a distinct outcome rather than mapping it to a default label.
- Upstream licensing is a separate check. The fine-tune is MIT; the Qwen3.5 base weights carry their own terms.
- Self-hosting needs a GPU and a pinned runtime. The Hugging Face
cards ship a
setup.shthat installs OneJev plus a serving patch and needs one CUDA GPU. Our platform removes that work, not the 16K limit.
Why run them via our HIPAA-compliant API?
- The classifier sits inside the boundary. These models see every request before the generator does, including the ones with identifiers. Running them under the same BAA, with end-to-end encryption and zero retention, keeps the decision out of a separate data-flow review.
- No runtime work. The pinned OneJev runtime, the serving patch, and the GPU are our problem. You send a state and a question set.
- Open weights, so the exit is real. MIT means you can leave: the same weights run on a single GPU if you decide to bring them in house.
Open weights matter here for the same reason they matter everywhere in clinical infrastructure. The decision layer sees more of the request than anything downstream, so one contracted boundary is easier to document than two. The catalog is here, and the contractual questions are covered in the compliance guide.
If you are evaluating mammoth-1 or elephant-1 against a workflow of your own, measure the flip rate under paraphrased instructions before you measure accuracy. A routing rule that changes its mind when someone rewrites a dropdown label will cost more in incident review than it saves in inference.
Ready to put your decision layer under a BAA? Join the waitlist.
Run it HIPAA-compliant
mammoth-1 on OpenMed Router
On demand input · On demand output · 16384 context
Chris Williams, MD
Chris Williams, MD is a physician, clinical AI researcher and the co-founder of OpenMed Router, working to make open source AI models safely accessible to healthcare organizations under HIPAA. He writes about clinical AI, model selection, compliance, and the practical adoption of open source inference in clinical and operational workflows.
Join the waitlist