Enterprise LLM Strategy: When to Build a Domain Model vs Call a Frontier API
In August 2026 Thomson Reuters launched Thomson, a proprietary model it trained in house on an open-weight foundation, reportedly the most recent base being Qwen 3.5, combined with decades of Westlaw, Practical Law, Checkpoint, and Reuters content. The reported numbers are the interesting part: a total investment near 40 million dollars covering talent and compute, but a final training run of only about 450,000 dollars, with early evaluations placing it comparable to leading frontier models on its target tasks. That gap between 40 million and 450,000 is the whole story of the build versus buy decision, and most teams read it wrong. This post is a decision framework, not a cheerleading piece: what you are actually buying when you build a domain model on open weights, what the real costs are beyond the headline training run, and the specific conditions under which owning a model beats calling a frontier API.
Enterprise LLM Strategy: When to Build a Domain Model vs Call a Frontier API
Thomson Reuters gave the enterprise world a clean case study in August 2026 when it launched Thomson, a proprietary model built in house on an open-weight foundation rather than trained from scratch. The reported figures are worth stating precisely, because they are what makes the decision legible: a total investment of roughly 40 million dollars covering talent and compute, a final training run of only about 450,000 dollars, a base model reported to be a recent open-weight release (Qwen 3.5), and decades of proprietary content from Westlaw, Practical Law, Checkpoint, and Reuters folded in. Early evaluations reportedly place Thomson comparable to leading frontier models on its target legal tasks, and the company keeps full ownership and control, sidestepping frontier inference pricing. The temptation is to read this as "building your own model is cheap now." That is the wrong lesson. Here is the right one.
| Factor | Build a domain model | Call a frontier API |
|---|---|---|
| Upfront cost | High: talent, data pipeline, evaluation, not just the training run | Near zero |
| Marginal inference cost | Yours to control, can be much lower at scale | Vendor priced, per token |
| Data moat | Uses proprietary data you already own | Data leaves for a third party unless contracted otherwise |
| Capability ceiling | Your target tasks only | Broad frontier capability |
| Ongoing burden | You own updates, drift, and serving | Vendor owns the model |
Read the 40 million versus 450,000 gap correctly
The single most misread number in the Thomson story is the 450,000 dollar training run. It is real, and it shows that the compute to specialize a strong open-weight base is now within reach of a mid sized enterprise budget. But the 40 million dollar total is the honest cost, and the 88x gap between the two is the point. The training run is the cheapest part of building a domain model. The expensive parts are the talent to run the program, the data engineering to turn decades of proprietary content into a clean training corpus, and the evaluation apparatus to prove the result is actually good on the tasks that matter. Thomson Reuters had all three: a rare data asset, the money to hire the talent, and a legal evaluation domain where "comparable to frontier" can be measured concretely.
If you take away one thing, take this: the training run is not the barrier, and the fact that it is cheap does not make building a model cheap. A team that budgets for the 450,000 and ignores the 40 million is planning to fail. The real question is whether you have the data asset and the evaluation clarity that made the other 39.5 million dollars produce something worth owning.
What you are actually buying when you build
You are buying three things a frontier API does not give you. First, a data moat: the model is trained on proprietary content you already own, so its edge on your tasks comes from data a competitor calling the same API cannot access. Thomson's edge is Westlaw and Practical Law, not a clever architecture. Second, cost control at scale: once the model exists, marginal inference cost is yours to optimize, and for a high volume, narrow workload that can beat per token frontier pricing by a wide margin, which is the same economics we worked through for self hosting an open-weight model versus paying API rates. Third, ownership and control: the weights are yours, the deployment is yours, and your data does not leave for a third party.
What you are not buying is broad capability. A domain model is excellent on its target tasks and unremarkable everywhere else, by design. That is a feature when your workload is narrow and high volume, and a liability when your needs are broad or shifting, because you have spent a fortune buying depth in one place and given up the frontier's breadth everywhere else.
The costs the headline hides
Beyond the training run, four ongoing costs decide whether owning a model pays off. Data engineering is first and largest: a proprietary corpus is not a training set until someone cleans, structures, deduplicates, and rights clears it, and that pipeline is continuous, not one time. Evaluation is second: to know your model is still good, you need a task specific benchmark you trust and rerun, because "comparable to frontier" is only meaningful against a measurement you own. Serving is third: you now run inference infrastructure, with all the capacity planning, latency management, and cost optimization that implies. Drift and updates are fourth: the frontier keeps moving, and a model you froze is a model that slowly falls behind unless you budget to retrain.
None of these are reasons not to build. They are reasons to build only when the math clearly supports it, and to size the program for the real costs rather than the training run. The teams that regret building are the ones that treated the model as a project with an end date rather than a system they now own forever.
The decision framework
Build a domain model when three conditions hold together. You have a genuine proprietary data asset that a frontier model cannot access and that materially improves performance on your tasks. Your workload is narrow and high volume enough that owned inference economics beat per token pricing at your scale. And you have a task specific evaluation you trust, so you can prove the model is good and know when it degrades. Thomson Reuters had all three, which is why the build made sense for them.
Call a frontier API when any of those conditions fails. If your needs are broad, if your volume is modest, if you lack a proprietary data edge, or if you cannot yet measure quality on your own tasks, a frontier API is the correct default, and it is not a compromise. It gives you breadth, zero upfront cost, and someone else owning the drift problem. For most enterprises, the right sequence is to start on a frontier API, instrument your workload, and only consider building once the data moat and the volume are both proven. In the meantime, the highest leverage cost work is usually not model ownership but disciplined use of what you already call, from prompt caching to cut production token spend to routing cheaper models at the right steps, the same cost per task discipline that separates frontier models in real workloads.
When this applies to your stack
If you are weighing a domain model, start by pressure testing the three build conditions honestly, because most teams fail at least one and do not know it until they have spent real money. Audit your proprietary data for whether it is actually a moat or just data you happen to have. Measure your workload volume against owned inference economics at your real scale. And build the task specific evaluation before you build the model, because without it you cannot tell success from expensive mediocrity. If the conditions hold, owning a model is a durable advantage; if they do not, a frontier API with disciplined cost engineering will serve you better for less. Our AI infrastructure practice helps enterprises run exactly this analysis before committing to a build.
FAQ
Does the Thomson Reuters model mean building your own LLM is now cheap? No. The final training run was reportedly about 450,000 dollars, but the total program was near 40 million dollars covering talent, data engineering, and evaluation. The cheap training run is the smallest cost, not the real one.
What is a domain specific or vertical LLM? It is a model specialized for a narrow field, usually by taking a strong open-weight base model and training it further on proprietary domain data. It is excellent on its target tasks and unremarkable on general ones, which is the intended trade off.
When should an enterprise build instead of using an API? When three conditions hold together: you have proprietary data that is a genuine moat, your workload is narrow and high volume enough that owned inference beats per token pricing, and you have a task specific evaluation you trust. If any condition fails, a frontier API is the better default.
What ongoing costs come with owning a model? Continuous data engineering, a maintained evaluation benchmark, inference serving infrastructure, and retraining to counter drift as the frontier advances. A model is a system you now own, not a project that ends at launch.
Sources
More from the lab.
vLLM vs SGLang: Choosing a Production LLM Inference Engine in Late 2026
vLLM and SGLang are both open source, both built to serve LLMs at production scale, and both frequently recommended for the exact same job, which is exactly why teams keep picking the wrong one. The real difference is not a benchmark number. It is which attention and caching architecture matches your actual traffic pattern, and most teams never check that before they commit infrastructure budget to one or the other.
Ollama's MLX Backend Beats Metal by 93 Percent: Apple Silicon Local Inference Tested (October 2026)
Ollama's 0.19 release notes say it plainly: on Apple Silicon, Ollama is now built on top of Apple's MLX framework to take advantage of its unified memory architecture, rather than the Metal backed llama.cpp path it shipped for years. On an M4 Max running Qwen3.5, that swap took decode speed from 57.8 tokens per second to 111.4, a 93 percent improvement, and prefill from 1,154 to 1,810 tokens per second. The catch is in the fine print: the MLX runner is in preview, it needs 32GB or more of unified memory to activate at all, and as of this release it only accelerates one model family. Here is what actually changed, what it costs to turn on, and where it still falls back silently to the slower path.
DGX Spark vs Mac Studio M5 Ultra: Local LLM Inference Benchmarked (October 2026)
The M5 Ultra Mac Studio shipping in September 2026 is a quad die chip with 1.2 terabytes per second of memory bandwidth and up to 256GB of unified memory, with a 512GB configuration arriving in late October. Against a single NVIDIA DGX Spark, it is not close: on a 27B dense model, the Mac decodes at roughly four times the speed. Cluster two DGX Spark units together over NVIDIA's GX10 networking instead, and the comparison flips for a different workload entirely, concurrent multi user serving. Neither machine is the right answer for every workload, and the decision comes down to whether you are serving one user or several at once.