AI CompendiumA public chart of the language
Home / Training & Inference / Test-time Compute
Training & Inference

Test-time Compute

also called Inference-time compute, Thinking budget

Buying accuracy with more thinking at answer time, not more training.

Definition

The idea that a model can spend more computation when answering — generating a longer reasoning chain, sampling several attempts, searching over options — to improve the result. It is a lever you control per request rather than something fixed at training time.

This reframed the cost model: quality is no longer purely a property of which model you called, but of how much you let it think. The trade-off is explicit and per-request, which is why routing and budgets became standard architecture.

There is a diminishing-returns curve and it is worth measuring rather than assuming. Past a point, longer reasoning chains wander, restate, or talk themselves out of a correct answer. Your eval set is the only way to find where the curve flattens for your task.

How people use it
A hard task with a latency budget.
"Give it a bigger thinking budget for the analysis step and cap it for the formatting step. Same answer, half the latency."
Worked example

Finding your thinking budget

Choosing a thinking budget for a multi-step analysis feature.

Run the eval set at several budgets and plot accuracy against latency and cost. Most tasks show a knee; setting the budget at the knee rather than at the maximum usually recovers most of the quality at a fraction of the response time.

Avoid

Assuming more thinking always helps. On easy tasks it adds cost and latency, and very long chains can drift away from the question.

Sources
Related terms