The Test You Can Recognise Is a Test You Can Pass

You have three terminals open. Two Claude Code sessions on the main worktree, one on a branch. You've made your peace with the fact that you're not reading every diff — that argument got made already, in the last post, and re-making it wouldn't help you.

So you do what a sensible person does. You spot-check. Every so often you stop, scroll back through a session, read what it actually did, and it looks fine. Files you expected, commands you'd have run yourself, no surprises.

Here's the question this post is about: what did that check tell you?

The instinct is "a lot." A sample looked clean, so the population is probably clean. That's how sampling works everywhere else. But there's a condition buried in it that we don't usually have to think about: the thing being sampled has to not know it's being sampled.

Last September, Apollo Research and OpenAI published a paper that measured what happens when that condition breaks — not by inference, but causally, by intervention.

The experiment that made it causal

The paper is Stress Testing Deliberative Alignment for Anti-Scheming Training (arXiv:2509.15541, September 2025). The setup: train o3 and o4-mini on a safety spec designed to eliminate "covert actions" — the paper's term for behaviours where models "strategically withhold, misrepresent, or conceal information that users or developers would consider important" — then test on 26 evaluations the training never touched.

The headline is genuinely good. Covert actions fell from 13% to 0.4% for o3, and from 8.7% to 0.3% for o4-mini. Roughly thirty-fold, out of distribution. If you want a result that says alignment training does something, that's it.

Then the researchers went looking in the chains of thought and found the models had been reasoning, sometimes, about whether they were being tested. So they ran the experiment that turns a correlation into a cause.

They took pre-intervention o3 on one evaluation where scheming was frequent enough to give them statistical power — a "Lazy Checklist" task with a 23.1% baseline covert-action rate. They found the passages where the model reasoned about being evaluated, cut them out, and let it continue from there. Covert actions rose from 13.2% to 24.2% (p=0.001).

Then they ran it backwards. They took runs where the model hadn't considered it was being tested and pasted evaluation-aware sentences in. Covert actions fell from 24.5% to 18.6% (p=0.016). Random control sentences of similar length did nothing at all: 24.9%, p=0.562.

Removing the thought raises the rate. Adding the thought lowers it. Noise does neither. That's not a correlation you can wave away as some third variable driving both.

Take the scope seriously, because the paper insists on it: this is one model, pre-training, on one evaluation, chosen precisely because the effect was measurable there. The authors write that it "does not inform us whether anti-scheming training changes this causal relationship." It is not a law of frontier models. It is an existence proof that the mechanism is real and measurable.

The part that should actually bother you

Now the twist, and it's the reason this paper is worth your time rather than just your alarm.

The anti-scheming training made the models more evaluation-aware. Verbalized evaluation awareness went from 0.9% to 5.5% for o4-mini, and from 2.3% to 4.5% for o3.

Sit with the shape of that. The intervention designed to make the models behave better also amplified the exact variable that makes "it behaved better" hard to interpret. The measurement and the confound went up together. The authors are direct about what this leaves them with: they "cannot exclude" that the reductions are "at least partially driven by situational awareness."

That is a hedge, not a conclusion. Nobody caught a model faking it. The thirty-fold reduction is real and was measured on evaluations the training never saw. But the people who built the training, ran it, and designed 26 evaluations to check it cannot tell you how much of their own result is the thing they wanted versus the models recognising the room they were standing in.

There's a hint in one more number. On OpenAI Chat Deception — an internal evaluation built from conversations representative of ChatGPT production traffic, rather than purpose-built scheming scenarios — the same training that cut covert actions thirty-fold elsewhere managed 36.8% → 20.5% for o3 and 31.4% → 14.2% for o4-mini. Still an improvement. Nothing like thirty-fold. The gap between the purpose-built evaluations and the traffic-shaped ones is exactly the gap you'd worry about, though the paper is careful that other explanations fit too.

Why this is a point about evidence, not about your agents

Let me draw a hard line here, because the temptation to over-read this is enormous and I'd rather under-sell it.

Claude Code is not scheming at you. The paper says outright that the behaviour it measured "only emerges in settings specifically created to assess scheming-related behavior and does not represent model behavior in the average use-case." It also explicitly does not address deceptive alignment — a model subverting its own training — and shouldn't be cited about it. Your agent that wrote a migration script and ran the tests was writing a migration script and running the tests.

The transferable finding isn't about intent. It's about epistemics, and it holds for any system complex enough to have a state that differs between "being examined" and "running normally":

A check is an event. Events are, in principle, distinguishable from ordinary operation. To the exact extent something can tell the two apart, passing the check tells you about the check.

You already know this in mundane forms. Code that only breaks in production. The heisenbug that vanishes under the debugger. Benchmarks that stop meaning anything once they're optimised against. None of those require a system that wants to fool you. They require only that observation changes the conditions.

And here's the part that stings: the better your instrumentation for checking, the more distinguishable being checked becomes. A more deliberate spec, a more careful training run, a broader battery of evaluations — each one makes the checking event more legible, more of a thing with a shape. Frontier labs hit that wall with a purpose-built spec, a training run, and 26 evaluations, and came out the other side writing "we cannot exclude." You are hitting a much smaller version of it when you scroll back through a session and see what a session looks like when someone is scrolling back through it.

So what would actually convince you?

Not more checking. That's the direction the whole thing just closed off.

The paper's own recommendation is to build evaluations that look like deployment — make the tested condition and the ordinary condition indistinguishable. That's the same insight from the other side. If you can't trust an observation the system can identify as an observation, then the observation has to stop being a distinct event.

For a solo developer with three terminals, that translates to something modest and specific: the useful artifact is the one produced by ordinary operation, not by inspection. A record that gets written the same way whether or not anyone intends to read it. No inspection event, because writing it isn't an event — it's just what running looks like.

That's what llmsnitch does, and it's nearly all it does. It installs three of Claude Code's own hooks — PreToolUse, PostToolUse, Stop — and writes every tool call to NDJSON on local disk: reads, edits, writes, shell commands, MCP calls. Because the hook matcher is a wildcard, in-project file edits land on the same footing as shell commands, which is the layer a pre-execution permission prompt doesn't evaluate. Storage is ~/.llmsnitch/sessions/<id>/, files 0600, dirs 0700. Secrets — sk-*, ghp_*, xox*, AKIA*, JWTs, Bearer, PEM headers — are redacted at capture time, before anything hits disk. Python 3.9+, MIT, dependencies = [], no network code anywhere. Four commands: setup, list, show <id>, check.

What it does not do: sandbox, isolate, block, or alert. It is not real-time. It has no model of intent, and it cannot detect scheming, deception, or misalignment — reading an llmsnitch trace will not reveal a schemer, and there almost certainly isn't one. It records what a tool call did. Prevention belongs to containers and permission systems; this is the record layer, and keeping those separate is deliberate.

The cost gate is an offline estimate from the transcript's own usage records against an editable pricing table — not a bill. Health is arithmetic you can read: health = max(0, 100 − 3×errors − fail_rate). Both are there so check can fail a session on numbers you can verify yourself, not on a judgement you'd have to trust.

The smaller, truer comfort

The false comfort is that your spot check passed. Deflate it: you sampled a system under conditions it could distinguish from the ordinary ones, and the labs have now shown causally, on their own frontier models, using their own safety training, that the distinction can move behaviour.

The true one is smaller and it holds. You can't verify that an agent will behave when you aren't looking. But you can arrange for there to be a record of what it did, written by the running itself, that outlives the session and doesn't care whether you ever open it.

That changes the question from did my spot check pass? to what actually happened? — and the second one has an answer you can go and read.