Confidence Comes From Experience: What XConf Changes About How We Measure LLM Confidence

A University of Cambridge and Google DeepMind team published XConf on 15 September 2026, a confidence-estimation method that reads confidence from a bank of past graded episodes rather than from the model's current answer. XConf retrieves the 50 nearest neighbours using a key combining the task embedding and the model's stated confidence, then averages that recall hit rate with a reflection step in which the model names its recurring failure mode before restating confidence; removing stated confidence from the search key costs 0.08 AUROC on reasoning and 0.12 on agents. The authors are Zhang, Zhu, Li, Chen, Kumaran and Collier.

Anyone who has put an LLM in charge of a real decision knows the question that comes right after the demo: when do we trust it? Routing an email to the right team, approving a patch, answering a customer without review. In all of these we need a number that says “this one can go, this one goes to a person”. The trouble is that the number usually comes from the model itself, and the model is not a good judge of itself. On 15 September 2026, a team from the University of Cambridge and Google DeepMind published “Confidence Comes from Experience: Experiential Confidence Estimation from Reasoning to Agents” Zhang, Zhu, Li, Chen, Kumaran and Collier . The method, called XConf , is simple to state and changes the starting point: confidence is not read from the current answer. It is read from the history of past answers. In this post I explain the idea, what the results actually show, how it compares with the rest of the confidence-estimation toolbox, and what it takes to use it in a real system, including the risks the paper does not cover. TL;DR There are three families of methods for putting a confidence number on a black-box LLM: All three have one thing in common: they only look at what the model is doing right now. And they share a blind spot. If the model has a stable misconception it reads “stop paying” and always thinks payments , when in your company that is a cancellation , it gives the same answer every time, with the same certainty and high probabilities. All three methods report “confident” on an error. The paper draws on decades of research on human metacognition. We do not judge our confidence only by re-inspecting the reasoning we just did. We also remember how similar situations turned out. A student who has solved a hundred determinants trusts the result without re-checking. The same student, facing a hard inequality, writes the answer already expecting it to be wrong, because they remember how often such proofs collapsed on the last line. XConf formalises this. Instead of asking the model what it feels , it asks the record what happened . The experience bank. Every time the model solves a task, an episode is stored with five fields: The lesson is quarantined: it is never shown to the model while it assesses a solution that has not been graded yet. The authors are explicit about why: knowing the outcome biases self-judgement in ways that instructions alone do not fix. Recall: a confidence-conditioned hit rate. For a new task, XConf retrieves the most similar episodes from the bank. The important detail is that the search key has two parts: the task embedding and the stated confidence . It does not look for “similar tasks”, it looks for “similar tasks where the model felt equally sure”. It takes the 50 nearest neighbours and computes the fraction in which the model was right. The paper shows this conditioning is not decoration: removing stated confidence from the key costs 0.08 AUROC on reasoning and 0.12 on agents. There is one more subtle detail: similarity is not raw embedding cosine. It is measured in a space rescaled using the bank’s own graded outcomes, so that “similar” means “fails for the same reasons” rather than just “is about the same topic”. Reflect: the model reads its own track record. The retrieved neighbours are shown to the model as short cards task, stated confidence, outcome, lesson . The model first has to name the recurring failure mode it sees, and only then restates a confidence. It is a short call that does not re-solve the task. Combine. The final confidence is the plain average of the two readings: ½ × Recall + Reflect . Two properties make this practical. When the bank is sparse around a task, the neighbours are only weakly similar and Recall relaxes towards the model’s base success rate at that confidence level: it degrades gracefully instead of failing. And nothing depends on the output format. A multiple-choice letter, a 200-line program and a 30-step agent rollout are stored in exactly the same way. Picture a system that routes customer emails at an insurance company to the right team. This one arrives: “I sold my car. How do I stop paying for the insurance?” The LLM reads “stop paying” and answers Payments , with high confidence. Any method that only looks at this answer agrees: the sentence is clear, the model is sure, and if you ask ten times you get the same answer ten times. XConf goes to the record, finds similar emails where the model also said “Payments, high confidence”, and checks where they ended up after a person handled them. Out of 10 similar cases, only 4 actually stayed in Payments. The rest ended up in Cancellations, because in practice people who write “stop paying” want to cancel. Recall = 0.40. Reflect, after seeing the cards, names the confusion and lowers it further. The final probability lands well below the threshold, and the email goes to human review instead of going straight to the wrong team. For contrast, “Can I pay by bank transfer?” also comes out as “Payments, high”, but there the record says 48 out of 50 were right, and the email goes through untouched. No new rule had to be written. The system learned to distrust the model exactly where it has a conceptual error, just by recording where the emails ended up. The numbers in this example are illustrative. The paper uses 50 neighbours; the figure shows 10 to fit. The evaluation covers nine benchmarks multiple choice, hard reasoning, maths olympiads, code, multimodal questions and three agent environments and four models from three families: Gemini 2.5 Flash, Gemini 3.5 Flash, Claude Sonnet 4.6 and Qwen3.5–397B. The protocol is careful: five-fold rotation, so the bank behind each estimate never contains the task itself. The authors also replay the protocol with the bank growing in strict chronological order, as it would in production. The numbers I find most relevant for people building systems: Measuring a historical hit rate is not a new idea. Classical calibration Platt scaling, histogram binning, isotonic regression does exactly that at the level of a score: “when the model says 0.9, how often is it right?”. Neighbour-based methods such as the Trust Score Jiang et al., 2018 and local variants of conformal prediction already asked “on similar examples, how reliable is the classifier?”. What XConf brings is the combination, applied to today’s LLMs: An honest reading of the table: post-hoc calibration and trained verifiers also use graded outcomes. The difference is that they need refitting or retraining to benefit from new data, whereas a new episode in the XConf bank counts from the moment it is stored. The paper evaluates the method on its own. In a real system I would not run it alone: I would add Recall as one more signal next to the ones you already have, and keep Reflect for the borderline cases. Online per request . The model answers with a single generation that includes its stated confidence a discrete scale such as “low / medium / high” works better than 0–100 . Recall is an in-memory lookup that does not call the model. A simple calibrator logistic regression is enough combines Recall with any other signals, and the result is compared with a threshold. The threshold is not picked by eye. Decide the error rate the business accepts on automated cases say, at most 3% and derive the threshold from a calibration set. That is the logic of selective prediction and conformal risk control. Offline when the outcome arrives . Every real outcome becomes an episode: a human fixed it, a test passed, a ticket was rerouted, an independent judge graded it. A periodic job writes the lessons, removes duplicates and refits the calibrator. Three variants, from simplest to most complete: Recall itself is a few lines: python import numpy as np python def recall q emb, q conf, bank, k=50, min neighbours=20 : """Hit rate on similar episodes with the same stated confidence.""" m = bank.conf == q conf same confidence level if m.sum < min neighbours: return bank.correct m .mean if m.any else None fallback: base rate sims = bank.emb m @ q emb normalised embeddings top = np.argsort -sims :k return bank.correct m top .mean Simplified, plain cosine. The authors’ code is at github.com/caiqizh/xconf. It pays off most where the real outcome arrives anyway and failures are silent: Where it is not the best choice: Most of these are not in the paper. They come from thinking about the method inside a real system. Labels must be independent of the model. This is the most important point, and the paper measures it. A bank labelled by an LLM judge that agrees 91% with the gold labels keeps most of the value. A bank labelled by the model itself ends up worse than having no labels at all, because self-judgements are wrong precisely on the confidently-wrong cases the bank is meant to catch. Cold start. No history means no Recall. Before asking anyone to label, look for operational signals you already have: reroutes between teams, reopened tickets, failed tests, manual corrections. Run the model over old closed cases and compare with where they ended up. That gives you a starting bank with zero annotation cost. Selection bias after you automate. Once confident cases go through on their own, only doubtful ones reach people, and the bank fills up with hard cases. Keep a random sample of automated cases under review, and weight it accordingly. Changing models. The bank describes the errors of one model. The paper measures that another model’s record loses 0.03–0.06 AUROC on the same tasks. Store the model version with each episode and treat a version change like a deploy. Leakage. Emails from the same thread, or near-duplicates, find themselves in the bank and inflate the results. Deduplicate, and split by thread or by customer when you evaluate. Personal data. The bank stores real tasks, so it stores real data. Mask what you do not need, set a retention policy, and remember that an embedding is personal data too. The paper is new. It is a week old, the numbers are the authors’ own, and there is no independent replication yet. The evaluation uses benchmarks, not a production system. Validate it on your own replay before trusting it. What convinces me most about XConf is not the win count against self-consistency. It is the change of question. For years we tried to extract confidence from inside the model, through probabilities, samples and introspection. XConf accepts that the model does not know where it goes wrong, and gets that information from something that does: the record of what happened. For anyone running LLM systems, the practical consequence is good news. Many of us already have that record, scattered across logs, reroutes and corrections. What is missing is storing it as experience and letting it decide when to trust the model. References Figures by the author, built from the results published in the paper. The email examples are illustrative. Confidence Comes From Experience: What XConf Changes About How We Measure LLM Confidence https://pub.towardsai.net/confidence-comes-from-experience-what-xconf-changes-about-how-we-measure-llm-confidence-c23e490af6b8 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.