Legal-domain open models
A survey entry, not a recommendation: legal tuning buys terminology and register, not judgement or citation discipline — and most releases in this category are academic artefacts with unclear maintenance.
Tier C — pilot only. Legal tuning buys terminology, register and comfort with legal shorthand; it does not buy abstention, citation discipline or judgement, and most releases in this category are academic artefacts whose maintenance cannot be relied on. There is real value here, but it sits in retrieval and classification components rather than in an assistant. Evaluate a legal-tuned model against a general model on your own tasks before taking it seriously, and expect the general model to win more often than the papers suggest.
Specifications, as published
| Publisher | Various academic and domain groups |
| Family | Legal-tuned open releases — decoder-only models continued-pretrained on legal corpora, and the older encoder-only legal models still used for classification and retrieval |
| Parameters | Two very different populations: decoder-only models in the single-digit billions, some continued-pretrained from a general base and a few much larger experimental mixtures of experts; plus encoder-only models in the low hundreds of millions of parameters |
| Context | Encoder-only legal models are built on short-window architectures and cannot be given a long document at all; legal-tuned decoders inherit their base model's window, frequently a generation or more behind current practice |
| Licence | Varies by release and by base model. Some legal-tuned decoders are released under permissive terms; several of the best-known encoder-only legal models were released under share-alike or research-oriented terms. Check each checkpoint, not the family name |
| Weights | Downloadable from academic and community repositories, often without versioning, maintenance or a stated support commitment |
| Release | Predominantly one-off academic releases from 2019 onwards, with a small number of continued lines |
| Licence posture | Varies by release and by base model. Some legal-tuned decoders are released under permissive terms; several of the best-known encoder-only legal models were released under share-alike or research-oriented terms. Check each checkpoint, not the family name |
Specifications are as published by the publisher at the review date and change frequently. Confirm them in your own evaluation before you procure.
Releases and variants
| Release | Size | Context | Serving footprint | What it is for |
|---|---|---|---|---|
| Saul-7B-Instruct-v1 | 7B dense, continued pretraining of Mistral-7B on legal corpora | 32,768 tokens as published in the model configuration | ~15GB at BF16, ~5GB at 4-bit | The most usable legal-tuned decoder for a small firm because it is MIT-licensed on its card and runs at 4-bit on one 24GB card, but it has had no maintenance since 2024 and should be treated as a bounded experiment rather than a supported product. |
| SaulLM-54B-Instruct | ~54B total, sparse mixture of experts — continued pretraining of Mixtral-class weights | 32,768 tokens as published in the model configuration | ~110GB at BF16, ~30GB at 4-bit | A server-class legal release whose model card declares MIT terms, but the 2024 release date and the absence of any continued line make it hard to justify hardware for a firm of 10–50 fee-earners. |
| SaulLM-141B-Instruct | ~141B total, sparse mixture of experts — continued pretraining of Mixtral-class weights | 65,536 tokens as published in the model configuration | ~280GB at BF16, ~75GB at 4-bit | The largest release in this survey and a multi-GPU deployment with a 2024 provenance, so it belongs in an evaluation paper rather than in a firm's infrastructure plan. |
| LEGAL-BERT (legal-bert-base-uncased) | 110M encoder-only (12 layers, 768 hidden), not a generative model | 512 tokens — it cannot be given a document, only a passage | ~0.5GB at BF16; runs acceptably on CPU | Still the workhorse for classification and retrieval in legal pipelines, cheap enough to run alongside everything else, but it is released under CC BY-SA 4.0, whose share-alike terms are a genuine question for a firm building a proprietary product on top of it. |
| InLegalBERT | ~110M encoder-only, pretrained on Indian legal text and court judgments | 512 tokens as published | ~0.5GB at BF16; runs acceptably on CPU | A permissively licensed (MIT) national-jurisdiction encoder that is a useful template for what a firm would have to build for English law, but it is trained on Indian material and offers nothing on UK statutes or case law. |
| Lawformer | ~100M-class encoder-only long-document model built on the Longformer architecture | 4,096 tokens as published in the model configuration | ~0.5GB at BF16; runs acceptably on CPU, though sparse attention makes long inputs slower than the size suggests | An early attempt at the long-document problem for Chinese judgments with no licence declared on the repository at all, so we would not put client material through it without legal review of the position first. |
| DISC-LawLLM | 13B dense, instruction-tuned on a Chinese legal corpus over a Baichuan base model | Inherits the base model's window; not published as a formal figure | ~26GB at BF16, ~8GB at 4-bit | An example of the licence confusion in this category: the repository declares Apache 2.0 for the released code, while the weights are built on a base model with its own terms that a firm would have to trace before commercial use. |
| LegalOne-8B | 8B dense, continued pretraining and reinforcement learning on a Qwen3 base for Chinese legal reasoning | 40,960 tokens as published in the model configuration | ~16GB at BF16, ~5GB at 4-bit | The most recent continued line in this survey and a clean MIT declaration, but its corpus and evaluation are Chinese-law focused, so for a UK firm it is a signal of where legal tuning is heading rather than a deployable option. |
Sizes, context windows and licences are as published by the publisher at the review date. The variant you pick matters more than the family name: a small dense release that fits one workstation and a large mixture-of-experts release that needs a multi-GPU server are not the same product, whatever the marketing says.
How it behaves on legal work
Start with what legal fine-tuning actually changes, because the surrounding marketing implies more than the technique delivers. Training or continuing to train a model on legal text makes it fluent in legal vocabulary, familiar with citation conventions, and better at producing text that reads like legal text. That is a real benefit for some tasks and a dangerous one for others: a model that sounds more like a lawyer is a model whose errors are harder to catch, because register no longer signals uncertainty. What legal tuning does not do is give the model a better sense of when it does not know, or a better habit of quoting the passage it was given rather than the passage it half-remembers. Abstention and citation behaviour are properties of post-training and prompting, and in our tasks legal-tuned releases are no better at them than a competent general model — and are sometimes worse, because a domain-tuned model is more willing to answer a legal question from memory. The decoder-only side of this category behaves, in our hands, like its base model with a legal accent. Extraction of definitions, obligations and clause types improves; drafting improves in register; the model is more comfortable with Latin, with statutory shorthand, and with the difference between a representation and a warranty. Analysis does not improve. Ask one of these models whether two clauses conflict and you get a plausible, well-worded answer with no better grounding than the base model would have given you — and an answer that is harder to challenge, because it is expressed in the language of the file. The encoder-only legal models are a different thing entirely, and are widely misunderstood because they are still cited as though they were assistants. They do not generate: they classify, embed and extract entities from a short input window, and they are good at it. A legal-tuned encoder used as a retrieval or clause-classification component can beat a general embedding model on legal text, which is a genuine and frequently overlooked win, given that retrieval quality drives output quality more than the generator does. Used as though it were a chat model it will simply fail, and the failure is often read as evidence that legal models do not work rather than that the wrong tool was chosen. The practical risk on this side of the category is licensing rather than quality: several of the best-known releases carry share-alike or research-oriented terms, and firms have deployed them without noticing. The maintenance problem defines the category. Most of these releases are academic artefacts — a paper, a model card, a repository that receives no updates. Base models move on, tokenisers change, the evaluation that justified the release is never repeated, and nothing in the ecosystem tells you when a release has quietly become stale. Compare that with a general open model that has had three generations since. The honest position is that a legal-tuned release is a component to be evaluated like any other, not a shortcut past evaluation. Where they earn their place is narrow and real: a legal-tuned encoder improving retrieval over a specialised corpus, a terminology model for translation consistency, a classifier for clause types at volume, and research or teaching where the legal corpus used for training is itself the point. In our experience week one is deflating. Fee-earners expect a legal model to be better at legal work; what they get is a model that sounds more legal and is no more reliable, with a shorter effective context and a shorter support horizon. The teams that get value from this category are the ones that stop asking it to be an assistant.
This is the category's weakest dimension and the reason we score it where we do. Legal-tuned models inherit the quotation habits of their base and then have those habits flattered by domain vocabulary: a paraphrase in fluent legal register is much harder for a reviewer to catch than the same paraphrase in plain English. Abstention is typically poor, because a model steeped in legal text is confident about legal text, and domain tuning does not fix it. The prompting that helps is blunt — explicit permission to say the documents do not answer the question, verbatim quotation with a page reference, and a prohibition on citing any authority not present in the supplied material.
What we would use it for
- Retrieval and ranking components over a specialised legal corpus, using encoder-only releases
- Clause-type classification and entity extraction at volume, against a labelled answer key
- Terminology and translation consistency where a legal glossary matters
- Research and teaching where the training corpus itself is the point
- A comparison baseline: run one against a general model on your own tasks and see whether the tuning buys anything
What to watch
- Domain tuning improves terminology and style, not abstention or citation discipline
- Fluent legal register makes fabricated or paraphrased content harder to catch
- Academic releases with no maintenance, no versioning and no support commitment
- Mixed licences across a family — share-alike and research terms hide behind familiar names
- Encoder-only models mistaken for assistants, then written off as poor ones
What it costs to run
The only pattern we would run here is a 7B-class legal-tuned decoder at 4-bit on a single 24GB card, with the encoder models doing retrieval and classification in the same pipeline — a workstation-scale deployment, not a server one, suited to one bounded task such as clause extraction or terminology checking. Expect a few concurrent requests at usable latency from that card, and treat the 54B and 141B releases as out of scope, because they need a multi-GPU server that nothing in this category justifies. Choose the release against your jurisdiction and your licence tolerance rather than the family name.
| Basis | GPU hours | Hourly (USD) | Monthly (USD) | When this is the right pattern |
|---|---|---|---|---|
| Always-on server (24/7) | 730 h | $0.58 – $1.65 | $425 – $1,205 | Firm-wide access, no cold starts, predictable latency |
| Business hours (10 h × 21 days) | 210 h | $0.58 – $1.65 | $125 – $345 | The realistic pattern for a firm of 10–50 fee-earners: power it up, use it, stop paying |
| Bursty / autoscaled endpoints | 60 h | $1.03 – $1.95 | $60 – $115 | Occasional analysis and pilots; you pay only for the seconds the model is working |
| Storage — weights, index and evaluation sets (~150 GB) | — | — | $20 | Billed whether the model is running or not — the quiet line on the invoice |
Indicative GPU class: 24GB class — RTX 4090 / L4 / A5000. Every figure above includes a 50% buffer on the underlying cloud rates — for encrypted storage, egress, idle capacity between requests, cold starts, operational overhead, and the plain fact that these are estimates rather than quotes. Rates move weekly and vary by region, tier and commitment.
Here the argument for buying hardware is weak: most of these releases are unmaintained academic artefacts, so a workstation bought for one is a capital outlay on a checkpoint nobody is updating, and a 24GB-class machine is indicatively $3,000–6,000 before you add the operational time. Rent a 24GB instance, or run the encoder models on hardware you already own, while you decide whether legal tuning earns a place in your pipeline at all. If you do buy, buy for the pipeline — retrieval, embeddings and evaluation — rather than for any single checkpoint, and treat these figures as indicative only.
Two rules of thumb that hold across the models we have deployed: renting beats buying until a firm is using the model more than about half of every working day, and stopping the instance matters more than the hourly rate — an idle server, and an idle storage volume attached to it, are where private AI budgets quietly go.
Sampling and prompt settings
For encoder-only releases there is no sampling to tune: run them at their published defaults and evaluate by accuracy against a labelled sample, because no temperature setting rescues a classification component that is wrong. Generative legal-tuned decoders: temperature 0 for extraction, 0.2–0.3 for drafting, with the same verbatim-quotation and refusal rules you would apply to any general model. Pin the exact checkpoint hash rather than the repository name — these releases are frequently re-uploaded or renamed and there is no versioning discipline to rely on.
Pin the exact model release in your evaluation record. Behaviour moves between point releases, and an evaluation that does not name a version cannot be reproduced.
Hardware and quantisation
| Deployment profile | What it fits | What to know |
|---|---|---|
| CPU or a single modest accelerator, encoder-only models | Retrieval, ranking and classification as one component of a larger pipeline | Small enough to run alongside everything else; the limitation is the short input window, not the memory |
| Single workstation, legal-tuned decoder at low precision | Terminology work and clause extraction on individual documents | Cheap to try and cheap to abandon, which is the right posture for a category with this maintenance profile |
| Multi-GPU deployment for the largest legal-tuned experiments | Research and evaluation, not production | We would not build a firm workflow on hardware at this scale for a release with no maintenance commitment behind it |
Who it suits
Teams building retrieval or classification layers over a specialised legal corpus, and researchers who need a model trained on legal text rather than one that merely talks about it.
Anyone looking for an off-the-shelf legal assistant, a drafting tool or a citation-safe research model — that is not what domain tuning produces.
Review history
| Date | Change |
|---|---|
| Sep 2026 | First entry. Survey entry covering legal-tuned decoder releases and encoder-only legal models. |
Sources
- SaulLM legal language models (Equall)
- LEGAL-BERT: encoder-only legal models
- The state of the art in open-source AI for Swiss legal tasks
- Open-weight legal LLMs 2026 (Presenc AI)