Fine tuning spent 2024 and most of 2025 being quietly written off. Every few months another post explained that a bigger model with a better prompt would beat your carefully trained specialist, and for a while that was usually true. Then the economics moved, and the argument moved with them.
Thinking Machines Lab has built a company on the other side of it. Founded in February 2025 by former OpenAI chief technology officer Mira Murati with a group of OpenAI alumni, it raised a two billion dollar seed round at a ten billion dollar valuation with NVIDIA, AMD and ServiceNow among the backers, and recruited PyTorch co creator Soumith Chintala from Meta. It has shipped two things: Tinker, a hosted fine tuning service, and Inkling, an open weight model.
Their thesis is a single sentence, and it is worth taking seriously whether or not you ever use their products: AI that organisations can adapt for themselves will outperform the one size fits all models the biggest labs currently sell, because so much of the expertise that matters is specific to the people who hold it and was never in anyone's pretraining corpus.
1. Ask the diagnostic question first
Before any of the tooling matters, one question decides whether you should be here at all, and getting it wrong is the most expensive mistake in this area.
Does the model lack knowledge, or does it behave wrongly on knowledge it already has?
If it does not know your product codes, your pricing rules or last quarter's policy change, that is a knowledge gap. Training it in is slow, costs real money, goes stale the day the policy changes, and is worse than putting the facts in front of the model at request time. That is a retrieval problem, and we set out how we build the read and write path for it in Read write memory.
If the model knows the material perfectly well but reasons in the wrong order for your domain, formats output the way a general assistant would rather than the way your systems need, hedges where your users want a decision, or misjudges which of two rules dominates, that is a behaviour gap. No amount of retrieval fixes it, and no length of system prompt reliably fixes it either. That is what fine tuning is for.
Most teams asking us about fine tuning turn out to have a retrieval problem. Some do not, and those are the ones where training pays for itself quickly.
2. What Tinker actually is
Tinker was announced on 1 October 2025 and became generally available on 12 December 2025. It is a training API rather than a product with a button.
You write what looks like an ordinary single process Python script and the service distributes it across many GPUs. You keep control of the algorithm and the data; it takes the distributed systems work, which is the part that historically made fine tuning a project rather than an experiment. It covers open weight models from around one billion parameters up past a trillion, dense and mixture of experts alike, including large models such as Qwen3 235B.
Two design choices matter more than the marketing.
Every run trains a LoRA adapter, rank 32 by default, against a shared copy of the base model. Low rank adaptation means you are not rewriting the model, you are training a small add on that adjusts it. The artefact you ship is measured in megabytes. Many specialists share one hosted base rather than each needing its own deployment. And rolling back is detaching an adapter, not redeploying a model. That reversibility is the single biggest reason fine tuning became worth trying again, because it turns a commitment into an experiment.
Pricing is per million tokens, not per GPU hour, split across three meters: prefill, sampling, and training. Training Qwen3 8B was listed at 40 cents per million tokens, rising to 44 cents on 17 July 2026. That sounds like a detail and is not. Per GPU hour billing makes the cost of a training run a function of how well you configured the cluster, which nobody can estimate in advance. Per token billing makes it a function of your dataset size, which you know before you start. Fine tuning became something a finance team can approve.
3. Inkling, and what an open frontier model is for
On 15 July 2026 the company released Inkling, its first in house model, with open weights. A mixture of experts design with 975 billion total parameters and roughly 41 billion active per task, trained on 45 trillion tokens, reasoning natively across text, image, audio and video while producing text, code and structured data.
The sparsity ratio is the interesting number. Around 4 percent of the parameters fire for any given task, which is what makes a model of that size servable at all, and it is the same architectural bet we saw in Kimi K3. Thinking Machines claims Inkling reaches equivalent coding performance using a third as many tokens as NVIDIA's Nemotron 3 Ultra, which if it holds is a cost claim as much as a capability one.
But Inkling's real job is to be a substrate. It exists so that Tinker customers have a capable open base to adapt, and the company is explicit that customers own the safety of what they build on top. The most quoted result is a Bridgewater Associates project where a fine tuned model scored 84.7 percent on financial reasoning tests, beating proprietary models at roughly a fourteenth of the running cost.
Take that figure as a vendor reported result on one domain, because that is what it is. The direction is what matters: a specialist trained on expertise that was never public, beating a generalist that never saw it, at a fraction of the cost to run. That is the thesis stated as a number.
4. Where this sits next to distillation
This connects directly to the argument in the small language models note. Distillation and fine tuning are the same move made for different reasons.
Distillation takes a capable model's behaviour on your traffic and compresses it into something smaller and cheaper that does the same job. Fine tuning takes a base model and teaches it something it did not know how to do. In practice, on a real system, you often do both with the same dataset: the logged trajectories that let you distil are the same trajectories that let you adapt.
The economics rhyme too. In both cases the valuable input is not compute, it is a correctly labelled record of your own work, which you already have if you have been running the system and logging it properly. The competitive asset in a business is not the base model, which anyone can download. It is the trajectories, and almost nobody treats them as an asset until somebody points at them.
Two warnings from doing this. A specialist inherits every bias in the examples you fed it, including the ones your team did not know it had, so the evaluation set has to be built by somebody who did not build the training set. And an adapter is a deployment artefact like any other: it needs a version, an owner and a rollback path, or you will end up with a model in production that nobody can explain. That is the same discipline as Governed autonomy, applied to weights rather than actions.
5. What we would do
- Run the diagnostic honestly. Collect twenty real failures and sort them into missing knowledge and wrong behaviour. If they are mostly the first kind, close this paper and go improve retrieval.
- Build the evaluation before the training set. Held out, built by somebody else, scored on a metric the business recognises. Without it you cannot tell whether the adapter helped.
- Start with the narrowest task that fails often. One behaviour, high volume, clear right answer.
- Use LoRA and keep the rollback path. The value is in being able to try, measure and detach in the same week.
- Treat your trajectories as an asset. Log inputs, outputs and corrections in a form that can become a training set, starting now, whether or not you plan to train anything this year.
Fine tuning is not back because the technique improved. It is back because LoRA made it reversible and per token pricing made it estimable, and those two changes turned it from a capital project into an experiment. Most businesses should run the experiment on one narrow task, and most will learn something either way. If you want that set up properly, talk to us, or see how we build systems for businesses.
6. Sources
- Thinking Machines Lab, Tinker and the announcement post.
- Tinker documentation, models and pricing, for the supported model range and the per token meters.
- DeepLearning.AI, The Batch on the Tinker API, for an independent description of the distribution model.
- TechCrunch, Thinking Machines releases Inkling, for the architecture, the licence position and the Bridgewater result.
- Hu et al, LoRA: low rank adaptation of large language models, the original method.
Capability and cost claims about Inkling, including the Bridgewater figure and the token efficiency comparison, are reported by the vendor and have not been independently reproduced here. Pricing was checked at 1 September 2026 and changes; confirm current rates before budgeting a run.
This paper sits in our Engineering track, alongside the foundation models, system design and operations threads. The full library is at Research.