Training a large model usually starts with a second job. You rent GPUs, keep them fed, watch for hardware faults, and restart work when a node dies. The actual idea you wanted to test sits in a queue behind all that plumbing.
Tinker tries to cut the job in two. You write a training loop in Python on a machine that needs no GPU at all. Thinking Machines Lab runs that loop on its own cluster of GPUs and handles the faults. The lab calls it a training API for researchers and developers, and the docs are blunt about the trade: full control of the algorithm, no control of the hardware, and no need for it.
Tinker
Official siteA training API for tuning open weight models while the provider runs the distributed work. Primary use case: supervised tuning and reinforcement learning on models too large to train on hardware you own, with your own data, loss and training loop.
Key features: four core calls cover the loop, with forward_backward for gradients, optim_step for updates, sample for generation and save_state for checkpoints; models from 1B to more than 1T parameters in the docs, in dense and MoE shapes; vision models in the list, with Qwen3.6-35B-A3B named in the docs as an example; and trained weights you can download for use with an inference provider of your choice.
Advantages: you change model by changing one string in code, per the docs; hardware failures are handled by the service, per the docs; and the adapter leaves with you, so the result is not trapped inside the platform. Limitations: LoRA only, with no full training of all weights; Python is the route in the docs checked; and token pricing means a careless loop can spend money while it learns nothing useful.
A small adapter on a huge base model is the whole design. The base stays frozen, the adapter learns. Illustration: Dirty Static
You write the loop. They run the cluster.
Most tuning services ask for a dataset and a few settings, then hide the training itself. Tinker does the opposite. Your script holds the data, the environment, the loss function and the evals. The service turns your calls into distributed training and brings back the result.
That split is why the product will feel familiar to researchers and strange to everyone else. If you wanted a button that says tune my model, this is not that button. If you wanted to try a new loss, a new reward or a new data mix without first becoming a cluster operator, that is exactly the gap it fills.
| Call | What it does, per the docs |
|---|---|
| forward_backward | Takes your data and loss, then computes and gathers the gradients |
| optim_step | Updates the model with the gradients you gathered |
| sample | Generates output from the model you are training |
| save_state | Saves weights and optimizer state so work can pause and resume |
The docs say a model swap is one string in your code. That detail matters more than it sounds. It means the same loop can be run on a small Qwen model while you debug, then on a much larger model when the loop is right, with the spend following the choice you actually meant to make.
Our coverage of Kilo Desktop made a similar point about workbenches: the durable value sits in the place where work happens, not in one model. Tinker makes the same bet one layer down, at the training loop instead of the editor.
LoRA only, and the lab says that is enough
Tinker trains LoRA adapters and nothing else. LoRA, short for low rank adaptation, trains a small set of added weights while the base model stays frozen. The result is a small adapter file that carries what your run taught the model, instead of a fresh copy of every weight in the base.
The lab argues, in its LoRA Without Regret post, that LoRA can match full training on many tasks that matter, with reinforcement learning named as a strong case. Treat that as the lab position, backed by its own research post, not as a settled law for every workload. The docs repeat the claim in careful form: the same performance for many important use cases, especially in RL.
The practical gains are plain even without the stronger claim. Adapters are small to store, fast to swap and cheap to share. You can train several adapters for several tasks on one base model, keep them all, and download the weights to serve elsewhere.
The model shelf and the cookbook
The pricing page checked on November 10, 2026 listed 39 models. The shelf mixes the lab own Inkling family with models from other makers, and the docs put the full range at 1B to more than 1T parameters, in both dense and MoE architecture. MoE, short for mixture of experts, means only part of the model works on each token, and Tinker prices those models by active parameters rather than total size.
Names on that page included Qwen models from Alibaba, Kimi K2.6 from Moonshot AI, GPT-OSS models from OpenAI, Nemotron models from NVIDIA, GLM models and DeepSeek models, along with Inkling and Inkling Small. Vision work is in the list too, with the docs naming Qwen3.6-35B-A3B for image understanding tasks.
That breadth comes with churn. The same pricing site carries a deprecations page, and several older models were retired in June, July and October 2026. Pin a base model only after you check that page, and expect to move a long project at least once.
The companion cookbook, published by the lab on GitHub, carries runnable recipes for the common jobs, from chat style supervised tuning to preference learning and reinforcement learning. Recipes matter here because the raw API is four calls and a blank page. A working example is the difference between an afternoon of progress and a week of plumbing, which is the very thing Tinker claims to remove.
What Works
- Your loop, your loss and your data, with the GPU cluster run for you
- Model swaps take one string, so cheap tests can stay cheap
- Adapters are small, portable and downloadable for use elsewhere
- A wide model shelf, from small dense models to models above 1T parameters
What Does Not
- LoRA only, with no route to training every weight
- Python SDK route in the docs checked, with the loop left for you to write
- Models retire on a schedule, so a pinned base can vanish mid project
- Token meters reward care and punish a sloppy loop at full speed
What a run costs
Tinker charges per million tokens, the way inference is usually charged, and splits the bill across three meters. Prefill pays for input tokens as they are processed. Sample pays for output tokens the model generates. Train pays for the forward and backward pass that computes gradients. Cached prefill gets a discount, and checkpoint storage is charged at $0.10 per GB per month.
A few train rates from the pricing page show the shape of the shelf. All figures are dollars per million train tokens at the standard context listed, checked on November 10, 2026.
| Model | Train rate per million tokens |
|---|---|
| GPT-OSS-20B | $0.396 |
| Qwen3.5-9B | $1.463 |
| Qwen3.8-27B | $4.103 |
| Inkling | $5.61 |
Train rate, dollars per million tokens
Standard context rates from the Tinker pricing page, checked November 10, 2026. Sample and prefill are charged apart from train.
Read that table with the meters in mind. Training is only one part of a bill. A reinforcement learning run samples a lot, and sampling on some models costs more per million than training does. On Qwen3.8-27B, the page listed sample at $5.595 per million against train at $4.103. Budget for all three meters before you start, and track tokens per run yourself if the economics of the project matter.
There is a quieter virtue in this pricing shape. An idle GPU costs you nothing here, because there is no GPU rental clock running. You pay when tokens move. For bursty research work, with long gaps for thinking between runs, that shape can beat renting a cluster you mostly stare at. It is the same logic that made Local Code on the Mac interesting at the other end of the scale: pay for the layer you actually use, and own the part that holds your judgement.
Which should you choose
Choose Tinker if you write training code and lack a cluster. Research teams, labs and product teams with a real loop to run get the core promise in full: your algorithm, their hardware, and an adapter you can take away at the end. Start on a small model, prove the loop, then move up the shelf.
Choose Tinker if you need reinforcement learning on a large open weight model. The docs and the lab research post both put RL at the centre of the LoRA case, the cookbook carries RL recipes, and the model shelf reaches sizes that very few teams could train at home.
Choose it if portability matters more than raw control. Downloadable weights mean a tuned model can be served by your own stack or another provider. A closed tuning service that keeps the model inside its own API asks for a different kind of trust.
Look elsewhere if you want a no code tuning flow. Tinker gives you primitives, not a wizard. Teams without training code will do better with a managed service that owns the loop, or with a recipe followed exactly as written before any custom work begins.
Look elsewhere if you need full weight training. That job still belongs on hardware you control or on a training platform built for it, with the cost and the plumbing that come with it. No adapter, however well trained, changes that boundary.
Final thoughts
Tinker is best understood as a refusal. It refuses to hide the training loop, refuses to rent you a cluster by the hour, and refuses to keep your tuned weights as a hostage. In exchange it asks you to bring the part that cannot be rented: a loop worth running, data worth learning from, and the discipline to watch three token meters while you work.
That is a fair trade for the people it was built for, and a poor one for everyone else, which is usually the sign of a tool with a real point of view. The shelf will churn and the prices will move, as they already have this year. The idea underneath, that post training should be code you own on hardware you do not have to babysit, is the part worth testing on your own work.
Sources
- Product, features, core calls and LoRA position: Tinker documentation, Thinking Machines Lab
- Models, context, pricing meters, storage and model types: Tinker Models and Pricing, Thinking Machines Lab
- General availability, Kimi K2 Thinking and vision input: Tinker: General Availability and Vision Input, Thinking Machines Lab
- LoRA case and research argument: LoRA Without Regret, Thinking Machines Lab
- Recipes and runnable examples: the tinker cookbook repository from Thinking Machines Lab on GitHub
- Illustrations: Dirty Static, generated in house style
END OF TRANSMISSION
Stay curious. Question everything.
