Latest in AI
Inkling 2 Small Pricing: Tinker Costs, Context Limits and Fine-Tuning
A practical guide to choosing the right Tinker endpoint and budgeting an Inkling 2 Small experiment before committing to production.
Inkling 2 Small is available on Tinker for inference and fine-tuning, but its model card, training configurations and serverless endpoint describe different limits. Before building around it, choose the access route you actually need and price the experiment separately from the application you eventually want to run.
Thinking Machines released the model on November 5. The useful question for a developer is whether it can learn a narrow job cheaply enough to justify maintaining another model. A large benchmark table cannot answer that for your workload.
What you can use today
At launch, Inkling 2 Small's weights are closed. Thinking Machines says it intends to release them under Apache 2.0 the following week, after external safety testing. Fine-tuning and sampling are available through Tinker, while downloadable checkpoints are tied to that later weight release. Treat those as separate milestones when planning an export or self-hosting project.
The model card describes a mixture-of-experts model with 594 billion total parameters and 17 billion active per token. It accepts text and images and produces text. Unlike the earlier Inkling models, it does not accept audio.
That active-parameter figure does not turn it into a small laptop model. It describes how much of the model participates in processing a token, while deployment still has to account for the full model's weights and serving implementation. There is little value in designing a local deployment before the actual downloadable artifacts and runtime support exist.
Read the endpoint's context limit
The model card states support for up to one million tokens. Tinker's currently listed configurations expose different limits: 64K for standard training, 256K for extended-context training, and 256K for the serverless inference variant.
Use the limit attached to your exact Tinker model ID. The larger architectural figure is not permission to send a million-token request to a 256K endpoint. This is especially easy to miss when an application stores only a friendly model name and hides the serving configuration behind it.
For a first experiment, keep a manifest with the full model ID, input format, maximum sequence length and evaluation settings. If you later change the endpoint, rerun the same cases rather than assuming the only difference is price.
Tinker pricing and a small budget example
The current pricing table lists these USD rates per million tokens, checked November 6:
| Configuration | Uncached input | Cached input | Output | Training |
|---|---|---|---|---|
| Standard, 64K | $0.30 | $0.03 | $1.00 | $1.50 |
| Extended, 256K | $0.30 | $0.03 | $1.00 | $3.00 |
| Serverless inference beta, 256K | $0.30 | $0.03 | $1.00 | Not applicable |
The standard training ID is thinkingmachines/Inkling-2-Small; extended training uses thinkingmachines/Inkling-2-Small:peft:262144. The serverless variant is thinkingmachines/Inkling-2-Small:peft:262144:sampling-nvfp4.
Serverless inference is in beta, with a separate waitlist for production use. Checkpoint storage is $0.10 per GB per month. Tinker also bills forward-only passes through training clients at the training rate.
Consider a hypothetical evaluation with two million uncached input tokens and 500,000 output tokens. Its token cost is $1.10. A separate 64K training run processing ten million training tokens costs $15 before evaluation, storage or other work. The same training-token volume at the 256K rate costs $30. These are arithmetic examples, not measured workload costs.
Do not choose extended context simply because it is available. First check whether your training examples need it. Otherwise, you pay more for capacity that never changes the result.
Set up a useful fine-tuning comparison
The Inkling cookbook guide uses thinkingmachines/Inkling-2-Small in existing Cookbook workflows and recommends checking both learning rate and thinking effort. Its renderer handles the model's message format. Reusing a renderer from another family can turn a reasonable experiment into a formatting problem before learning even starts.
I would begin with a narrow task, such as turning a support conversation into a structured escalation brief. Define the required fields, the evidence each field needs and what the answer should do when the conversation is incomplete. Keep a held-out set containing ordinary cases, ambiguous requests and examples where the correct answer is to ask for more information.
Then compare the base model with your best prompt against a fine-tuned checkpoint on the same inputs. Score missing facts, invented facts and usable output separately. A prettier brief with an invented customer commitment should lose to an awkward but accurate one.
Tinker's supervised-learning loop supports dataset builders, evaluation intervals and checkpoint intervals. Use those controls to inspect intermediate results. There is no reason to judge only the final checkpoint if an earlier one performs better on held-out cases.
Decide what would make the experiment worth keeping
Choose a measurable adoption rule before looking at the results. For the escalation example, that might be fewer unsupported statements without increasing the time an operator spends checking each brief. Record token cost and review time alongside accuracy, because an economical training run can still produce an expensive workflow.
Thinking Machines acknowledges verbose answers, imperfect tool selection and presentation weaknesses. Those are useful test cases, especially if you expect a model to navigate a large tool collection. This guide is based on documentation, not a hands-on performance test, and there is no evidence here that Inkling 2 Small will outperform your current system.
The first useful win would be a repeatable improvement on a job you already understand. Once that exists, production access and eventual weight portability become decisions worth spending time on.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help technical teams turn product decisions and engineering work into clear stories that developers and founders want to read.