Classification Thresholds Explained: Turn Scores Into Decisions

Your spam filter just flagged an email with a score of 0.55. Is it spam? The model isn't telling you—it's asking you to decide. Somewhere between the probability and the verdict, a human choice got made. That choice is the classification threshold, and it deserves more attention than the default setting most beginners inherit.

The Score Is Not the Decision

Here's the confusion that trips up most beginners: they treat a model's output as a verdict when it's actually a suggestion.

A binary classifier outputs a score that expresses how strongly the model believes an example belongs to the positive class. That score is often a probability between 0 and 1, but not always. Some models output raw decision scores that only rank examples—they tell you which emails are more spammy than others, not how likely each one is to be spam. What matters for this article is that neither output is a final answer. The model doesn't decide whether an email lands in spam or your inbox. It says, "I think there's a 55 percent chance this is spam," and then a separate rule takes over.

That rule is the classification threshold: the cut-off point that converts a score into a class label. Score above the threshold? Predict positive. Below it? Predict negative.

The default of 0.5 feels like a law of nature, but it's a convention. Scikit-learn and other libraries hard-code that default because it's a reasonable starting point, not because it's optimal for your problem. The threshold is a value a human chooses, not something model training discovers.

In logistic regression, you saw how the model produces probabilities from raw scores. This article is about what happens after that score exists—the moment where math becomes a decision with real consequences.

What Moving the Threshold Actually Changes

Think of the threshold as a gate that decides which borderline cases tip into the positive class.

Lower the threshold, and the gate opens wider. The model becomes more eager to predict positive: more true positives, but also more false positives. Raise the threshold, and the gate narrows. The model turns cautious: fewer false positives, but more false negatives.

The model itself never changes. Same scores, same underlying patterns. Only the decision rule moves.

Let's make this concrete with a tiny example. Imagine five emails with true labels and predicted spam probabilities:

Email	True Label	Probability
1	Spam	0.92
2	Spam	0.71
3	Not spam	0.58
4	Not spam	0.44
5	Spam	0.31

At a threshold of 0.5, emails 1, 2, and 3 get flagged as spam. Emails 1 and 2 are true positives. Email 3 is a false positive—a legitimate message wrongly sent to spam. Email 5, genuinely spam, escapes as a false negative.

Drop the threshold to 0.3, and the same three emails are still flagged, but now email 5 is caught too. You've gained a true positive and lost a false negative. The cost? Email 3 remains a false positive, and you're now one wrong decision away from flagging email 4 as well.

Raise the threshold to 0.8, and only email 1 is flagged. You've eliminated false positives entirely, but you've missed two of the three true spam emails.

Same model. Three different behaviors. The threshold is the dial you turn.

Precision and Recall: The Two Sides of the Tradeoff

If you've worked with classification metrics, you already know precision and recall. What matters here is how the threshold moves them—and why they move in opposite directions.

Precision asks: of everything the model flagged as positive, how much was actually correct? Recall asks: of everything that truly was positive, how much did the model catch?

A higher threshold tends to raise precision and lower recall. The model only predicts positive when it's quite sure, so the positives it does flag are mostly correct—but it misses more real positives along the way.

A lower threshold does the reverse. The model catches more true positives but also flags more false ones, dragging precision down.

This inverse relationship isn't a bug. It's structural. The same borderline cases can't be both excluded and included. Every example sitting near the threshold has to go somewhere, and whichever way you move the gate, you're making a trade.

The precision-recall curve shows this trade visually: as you sweep through candidate thresholds, you trace out the possible combinations of precision and recall your model can achieve. The curve doesn't tell you which point to pick. It shows you what's available.

Choosing a Threshold From the Cost of Mistakes

So which threshold should you choose? The honest answer: the one that minimizes the mistakes you can't afford.

The right classification threshold depends entirely on the real-world consequence of a false positive versus a false negative. There is no best threshold in the abstract—only a best threshold for a stated cost structure.

Consider two very different problems.

A cancer-screening model should favor recall. Missing a tumor is catastrophic; sending a healthy patient for extra tests is inconvenient. You'd lower the threshold so the model errs toward flagging suspicious cases, accepting more false positives because the cost of a false negative is so much higher.

A spam filter may favor precision. Losing a legitimate email from a client or a job offer is worse than seeing a few spam messages in your inbox. You'd raise the threshold so the model only flags emails it's confident about, accepting more false negatives because the cost of a false positive is so much higher.

The practical method: assign a relative cost to each error type, then choose the threshold that minimizes expected cost. If a false negative costs ten times more than a false positive, you want a threshold that catches far more positives—even at the price of extra false alarms.

The numbers alone don't decide this. Subject-matter judgment does. You need to know what a missed tumor costs your users, or what a buried invoice costs your business, before you can set a meaningful threshold.

How to Tune the Threshold in Practice

Once you know which error hurts more, the workflow is straightforward.

First, get scores instead of hard labels. In scikit-learn, that means using predict_proba or decision_function rather than predict. The latter already applied a threshold for you; the former give you the scores you need to make your own choice. Just remember the scale: predict_proba returns values between 0 and 1, while decision_function returns raw scores that can be negative or exceed 1. A threshold of 0.5 only makes sense for probabilities.

Second, examine how precision and recall change across candidate thresholds. A precision-recall curve gives you the full picture at a glance. You can also inspect a table of metric values at specific thresholds to find the point that matches your cost structure.

Third—and this is critical—use a validation set, not your training data, to choose the threshold. If you tune the threshold on the same data the model learned from, you'll pick a threshold that reflects the training set's quirks rather than genuine generalization.

Scikit-learn provides tools for tuning the decision threshold through the scoring parameter, which lets you optimize for a specific metric during model selection. That's the entry point if you want the library to help you search for a good threshold automatically.

The workflow matters more than the specific function calls: get scores, explore the trade, pick the point that matches your costs, and verify on data the model hasn't seen. That last step deserves emphasis: once you've chosen a threshold on validation data, freeze it. Report your final performance estimate on an untouched test set. Otherwise, you're describing how well you searched, not how well your model will perform.

Common Threshold Mistakes

Beginners make the same threshold errors repeatedly. Here are the ones worth avoiding.

Assuming 0.5 is always right. The default fails whenever classes are imbalanced or error costs are unequal. If 1 percent of your emails are spam, a 0.5 threshold might catch almost nothing useful. The default is a starting point, not a destination.

Tuning on the training set. Choosing a threshold on training data overfits the decision rule. The threshold inherits the model's overconfidence about examples it already saw. Always validate the threshold on held-out data.

Confusing calibration with thresholding. A well-calibrated probability—one where 70 percent confidence means the event happens 70 percent of the time—is not the same as a well-chosen threshold. Calibration is about the quality of the scores. Thresholding is about what you do with them. You can have perfect calibration and a terrible threshold.

Re-reporting the model after changing the threshold. Moving the threshold doesn't improve your model. It changes the operating point. If you tuned the threshold on a validation set and then report performance on that same set, you're reporting the result of your search, not an honest estimate of generalization.

Forgetting to revisit the threshold. Data distributions shift. Cost structures change. A threshold that made sense last year—when false positives were cheap and false negatives were expensive—may be wrong today. The threshold is a decision you make, and decisions need revisiting.

The Model Proposes, the Threshold Disposes

Here's the decision rule to carry forward:

Name your positive class. Decide which error is more expensive—false positive or false negative. Move the threshold in the direction that reduces that expensive error. Verify your choice on held-out data, then confirm it once on data the model has never seen.

The model proposes scores. The threshold disposes of them into actions. When you separate those two steps, you stop inheriting defaults and start making deliberate choices about what your model's mistakes are worth.

That's the difference between running a classifier and owning a decision.