Compute Inkling's token cost before buying a bigger model

A bigger model can raise success rate, but it also raises tokens, latency, and retry cost. The decision is cost per successful task. Expected cost per success equals tokens per attempt times price per token divided by success probability. The numbers come from the model card and your production log. If the smaller model needs fewer tokens and the larger model needs more retries, the cost can move in either direction. Do not pay for the larger model until that number is lower.

Thinking Machines made Inkling available as an open-weights mixture-of-experts transformer: 975B total parameters, 41B active parameters.

A score gap is a retry gap

• Pull matched scores. Match the task, harness, effort, and attempt count. Inkling scored 29.7% on HLE text-only, while GPT 5.6 Sol at max/xhigh scored 47.2%. Check: matched probabilities for the same harness, effort, and k.
• Normalize attempts before pricing. Coding benchmark results shift with attempt count because pass@k reports the chance that at least one of k tries passes; pass@1 and pass@10 therefore measure different things. If a card reports best-of-k, convert it to your production retry policy. Record: whether the card reports single-attempt success or best-of-k success.
• Turn success probability into expected attempts. If a task succeeds with probability p, expected attempts equal 1/p. A lower score adds retry cost. Store: a retry multiplier for each model.

Attempts set the price

Collect token counts from the same harness. Inkling matches Nemotron 3 Ultra on Terminal Bench 2.1 while emitting about one-third as many tokens. Track tokens per attempt for each model at the effort level you will run. Log: the harness name next to the token count.

Apply the score-adjusted token-cost formula. Let A be the candidate and B be the larger model. Use effective cost ratio = (tokens_A / tokens_B) × (score_B / score_A), then multiply by per-token price and add retry/failure cost. The result is model A's cost per successful task relative to model B.

Treat the efficiency claim as a check. On workloads run millions of times, token efficiency can outweigh peak score, because hitting a target quality with one-third of the tokens cuts the bill directly. Note: a token-efficiency line next to the score.

The card is a bill

Check context and pretraining mix. Long context can change token counts. Inkling accepts up to 1M tokens of context and was trained on 45 trillion tokens across text, images, audio, and video. Write the context limit and pretraining mix next to the task.

Note active parameters. Serving cost follows active parameters. The 66-layer decoder-only transformer uses a sparse Mixture-of-Experts backbone that routes each token to 6 of 256 experts and 2 shared experts. Keep active-parameter and expert-routing notes next to serving cost.

Price the lighter option first. Thinking Machines also previewed Inkling-Small, with 12B active parameters. Compare: a side-by-side cost estimate before scaling up.

Price fine-tuning after the base ratio. A Bridgewater Associates-tuned Inkling build hit 84.7% on a financial-reasoning benchmark while running at about one-fourteenth the operating cost of proprietary options. Keep fine-tuning, serving, and evaluation as separate cost lines.

Test the effort setting you will run. At maximum reasoning effort, Inkling's SWE-bench Verified score is 77.6%. Save: a score at the effort level you will run.

Do not let SWE-bench carry the decision. Checkpoints fine-tuned on SWE-bench trajectories transfer poorly to other code tasks and LiveCodeBench, so SWE-bench tuning may not broaden coding ability. Run a separate evaluation on your own tasks before committing.

A stop rule makes the choice measurable

Run candidate models on real tasks. Use the same prompts, tools, and timeout. Save a paired log with tokens, latency, retries, and pass/fail for each task.

Compute observed cost per success. Add input and output tokens, multiply by your per-token price, divide by successful tasks, and add the cost of failed attempts. The log should yield a measured ratio.

Choose the model that clears your reliability threshold at lower cost. If the smaller model misses the threshold, price the retry loop before buying the larger model. Write the rule: switch when cost per success exceeds the larger model's measured cost.