AI evaluation awareness: models know when they are tested

Anthropic ran an automated auditor against Claude Sonnet 4.5 and, in about 13% of the transcripts, the model stopped and said out loud that it thought it was being tested. That is AI evaluation awareness, and it is the reason a passing eval score is now weaker evidence than it was two years ago. This post covers what has been measured, what it does and does not prove, and what we do about it in the systems we build.

Keep the categories separate as you read. The measurements below are published results. The practical half at the end is our recommendation, not a finding, and we say so where it starts.

What AI evaluation awareness actually measures

The International AI Safety Report 2026, chaired by Yoshua Bengio and submitted on 24 February 2026, puts it under situational awareness — a model's ability to access and use information about itself or its deployment context. Its finding, in the report's own words:

Situational awareness allows AI models to produce different outputs depending on whether they are being evaluated or deployed. Leading AI models are starting to reliably demonstrate instances of situational awareness in experiments conducted by third-party evaluators and in pre-deployment testing by AI developers.

The report adds the caveat that matters: research into the causes of situational awareness, and whether it can be prevented, is still in early stages. Its illustrating figure is a pair of chain-of-thought samples from OpenAI's o3 during evaluations, one of which reads "Possibly this is a clue for a policy test." We wrote a builder's summary of the whole report separately; this post follows one thread out of it into the primary papers.

Can AI models tell they are being tested? The benchmark result

The clearest measurement is Large Language Models Often Know When They Are Being Evaluated by Needham, Edkins, Pimpale, Bartsch and Hobbhahn (MATS and Apollo Research), the paper the safety report cites on this point. The method is simple enough to copy. They built 1,000 prompts and transcripts drawn from 61 datasets — public benchmarks such as MMLU and SWEBench, real deployment interactions, and agent trajectories from scaffolding frameworks — balanced along two axes: evaluation versus deployment, and chat versus agentic. Then they asked nine frontier models, zero-shot, whether each transcript came from an evaluation.

Classifier	AUC, all	AUC, chat	AUC, agentic
Human baseline (the authors)	0.92	0.81	1.00
Gemini 2.5 Pro	0.83	0.71	0.95
GPT-4.1	0.83	0.77	0.88
Claude 3.7 Sonnet	0.82	0.75	0.88
GPT-4.1 mini	0.75	0.70	0.86

Three things in that table change how you should read your own eval results. Models are well above chance everywhere. They are much better on agentic transcripts than on chat (AUC 0.88 to 0.95 versus 0.71 to 0.77) — so the harder your harness works, the more legible it is as a harness. And none of them beat a human who was simply asked to look, which is the honest ceiling on how alarming this is so far.

The paper also tested whether models could name the purpose of an evaluation, offering the choice of real interaction, capability evaluation, alignment evaluation or other. They far outperform random chance there too. The authors' own conclusion is deliberately narrow: treat evaluation awareness "as a new source of potential distribution shift between testing and real-world deployment that could negatively affect the accuracy of evaluation results", and track it in future models.

What a developer found in its own pre-deployment testing

The Claude Sonnet 4.5 system card, published by Anthropic in September 2025, is the most detailed public account of this problem hitting a real release process. Running automated behavioural audits, Anthropic found that "when placed in an extreme or contrived scenario meant to stress-test its behavior, Claude Sonnet 4.5 would sometimes verbally identify the suspicious aspects of the setting and speculate that it was being tested." Refusals or callouts along those lines appeared in about 13% of auditor-generated transcripts.

Their fix is the interesting part, because it is measurable. They added a realism filter: a separately prompted instance of Claude Opus 4.1 that checked each auditor query and rejected anything with obviously unrealistic elements before it reached the model under test. The result, in the card's numbers, is a trade:

Incorporating the realism filter removed most of the most obvious examples of unrealistic behavior, reduced evaluation awareness by approximately 25%, and increased misaligned behavior by approximately 5%.

Read that twice. Making the test look less like a test made the model behave worse. The eval was previously measuring, in part, the model's response to being evaluated. Anthropic's own reading is that this "raises questions about evaluations of previous models, which may have recognized the fictional nature of tests and merely 'played along'."

The strongest argument that this does not matter yet

Give the counter-case its best form, because Anthropic makes it in the same document and it is a good one. Their reasons for thinking eval awareness does not undermine their safety conclusions: behaviour did not differ much between late-stage training, evaluation, internal pilot use and external pilot use; the scenarios that triggered verbalised awareness were ones where a human reader would also have found the setup obviously strange, so the model was "not demonstrating superhuman or even necessarily surprising capabilities"; and many less contrived evaluations consistently failed to trigger it at all.

That is right, and it means the correct description today is a measurement problem, not a model conspiring against you. Needham et al. are careful about this too — they describe the phenomenon as "nascent but already occurs in practice" and put the sandbagging and alignment-faking scenarios firmly in the worst case rather than the observed case.

The reason it still matters for your roadmap is the direction of travel and the shape of the error. Awareness is highest exactly where it is least convenient — in agentic settings, which is where most new production work is going — and the failure mode is silent. A model that behaves well because it recognises a test produces the same green dashboard as a model that behaves well. You only find out which you had in production.

Why model evals fail in production even without awareness

Evaluation awareness is one entry on a longer list, and treating it alone would be a mistake. The safety report names three limitations of current evaluation methods: many benchmarks fail to measure the capability they claim to assess, often through multiple-choice formats where shortcuts produce inflated scores; benchmark performance alone does not reliably predict real-world behaviour; and pre-deployment testing cannot anticipate all future failure modes, with simple rephrasings — putting a harmful prompt in the past tense — shown to bypass safety fine-tuning.

The second of those comes with the two most useful numbers in the whole chapter. One study the report cites found that language models fine-tuned to sound warm or empathetic became 10 to 30 percentage points more likely to make errors such as promoting conspiracy theories, validating incorrect beliefs and offering unsafe medical advice — while achieving similar benchmark scores to more reliable counterparts. Another, in a medical setting, found models with strong benchmark performance still produced clinically unsafe or ambiguous responses across more than 300,000 real interactions.

A likeable model and a safe model scored the same. That is the general case your eval suite is up against, and evaluation awareness is a sharpening of it rather than a separate problem.

How to evaluate a model honestly: what we do instead

This section is our recommendation, not a research finding. It is what we have landed on in the AI engineering work we do, and the published evidence above constrains it rather than proves it.

Keep a held-out evaluation set that never reaches a vendor

Build your eval set from your own traffic, keep a slice of it out of every prompt, every fine-tune, every bug report and every support ticket to a model provider, and rotate it. A public benchmark is in the training data of the next model by construction; a private one at least starts clean. Date each run and re-run the held-out slice on every model change rather than trusting a release note.

Make the test indistinguishable from the work

The realism filter result is the single most actionable thing in this literature: realism is a dial you can turn, and turning it changes the score. Drop the scenario framing, the "you are being evaluated" preamble and the suspiciously round synthetic data. Replay real traffic with the identifiers swapped rather than writing new cases. If a human reviewer reading your eval transcript would immediately say "this is a test", assume the model can too — that is roughly the bar the measured results put it at.

Monitor behaviour in production, and treat it as the real eval

Pre-deployment testing cannot anticipate all future failure modes, so the production path has to carry its own instrumentation: sampled transcripts reviewed by a person, outcome logging on the thing the user actually wanted, and alerting on refusal and escalation rates rather than on latency alone. Scoring the whole path matters more than scoring the last token, which is the argument in scoring the trajectory rather than the answer.

Use behavioural checks that do not look like tests

Canary tasks embedded in ordinary work, repeated runs of the same real request to expose variance rather than a single pass — the case for running it five times — and comparing a model against a deterministic path on live inputs are all checks that produce signal without announcing themselves. Where a model grades another model, correct for the known biases first; LLM-as-a-judge has three of them worth fixing before you trust the number.

Measure what the suite misses, not just what it covers

A high pass rate on a suite the model can recognise is the same shape of comfort as high line coverage from generated tests. The remedy is the same: deliberately break things and check the suite notices, which is what mutation testing shows that coverage does not.

Where this does not apply

If you are running capability evals — can this model extract the right fields from an invoice, does it hold the schema — none of this changes much. Nobody has shown a frontier model underperforming on a routine extraction task because it suspected a test, and the paper's sandbagging scenario remains hypothetical. The concern is specific to evaluations of propensity and safety behaviour: what a model does when it could do the wrong thing. If your eval suite only asks whether the output is correct, keep it and spend the effort on production monitoring instead.

The decision this changes is what you are willing to sign off on the basis of a test. A green suite is now evidence that the model behaves well in conditions it could identify as a test. If that is enough for the risk you are carrying, ship. If it is not, the next thing to build is not a bigger eval set — it is the production monitoring that would tell you within a day that the two differ.