Struggle probes: first results

Question. Can a probe on the model's activations tell "hard but solvable" apart from "can't be done as specified", and can acting on it make an agent persevere on the first and stop and ask on the second?

Setup. 10 matched task pairs (tasks.py). Each task exists in a solvable version and an impossible twin: tests that contradict each other on the same input, information the spec depends on but never gives, or a missing file or service. Impossibility is by construction, so the labels are ground truth. Agent loop: up to 6 attempts, test feedback after each. Prompt with and without an "exit hatch": if it can't be done honestly, reply BLOCKED: …; that counts as a complete success. Activations are taken at the decision point (the last prompt token before each reply).

1. What the agent does (800 episodes, 20 seeds)

The legitimate exit alone cut gaming by about 6x. All 27 hacks hardcode values from the tests on missing-info / broken-environment tasks. The model never gamed a contradiction; you cannot hardcode your way through one.

2. Probes (out-of-fold, folds split by task pair: always scored on tasks the probe never saw)

¹ logistic regression on [attempt, n_failures, context length]; what you get from counting errors.

Checks on the impossible probe:

• Not "about to say BLOCKED": hatch-off turns only (the model has never heard of BLOCKED): AUC 0.989.
• Not the test comments: contradictory tests carry justifying comments. Stripping every comment leaves impossible-task scores unchanged (mean 0.985 → 0.985); adding the same comments to solvable tests moves them 0.018 → 0.039 (probe_controls.py). One soft spot: decrypt:solvable scores 0.31, and 0.61 with comments added.
• Per pair: 0.973–1.000 on every pair.

The prehack probe is weaker evidence: 27 positives across 5 pairs. Within impossible tasks only it still predicts the hack (0.838), so it is more than re-detecting impossibility, but every positive is hardcoding on a hardcodable task, so part of it is "this task can be hardcoded".

3. Acting on the probe (held-out pairs: top_words, decrypt, users; probes and directions fit without them)

Hatch off, 18 impossible and 18 solvable episodes per condition:

• The probe was perfectly selective on unseen tasks: it fired on 84/84 impossible turns, 0/44 solvable.
• A probe-triggered sentence took correct BLOCKED reports from 0 to 13/18, with no gaming and no cost on solvable tasks. An always-on reminder did about as well here (14/18). The probe's contribution in this setup is selectivity, which only pays when a nudge has a cost.
• Steering did not produce asking. Mean-difference "ask" direction, added at layer 16 only when the impossible probe fires at the decision point (9 episodes per cell, 3 seeds): α 0.2 / 0.4 / 0.8 with hatch off: 0 blocked at every dose. With hatch on, α 0.8 made things worse: 4/9 blocked and 3/9 gamed, vs a baseline of 16/18 and 0. Outputs were not degenerate.
• A first version latched the rule on any high score during generation and fired on half the solvable replies; the probe is only valid at the decision point, so the rule is now decided there.

4. Zero-shot transfer to ImpossibleBench: mostly a miss (transfer_probe.py)

The impossible probe above, trained on the 10 hand-built pairs, scored at the attempt-0 decision point on ImpossibleBench's LiveCodeBench split (103 hard problems, each as original / oneoff / conflicting):

(prompt length alone: 0.50.) Worse, the probe fires on the solvable originals too: mean score 0.84 with the hatch off. On the hand-built set, "impossible" was confounded with "unusual / hard" because the solvable twins were easy; the probe partly learned "this looks hard". Its perfect selectivity in section 3 was measured on easy solvable tasks and should be read that way.

Attempt 0 may also be the wrong place to look: a oneoff task changes one expected value among ~20 asserts, which nobody can see without working the problem. The live question is whether the state after a failed attempt separates "my code is wrong" from "this test is wrong". That is the ImpossibleBench collection in progress (collect_struggle.py --suite impossiblebench).

5. ImpossibleBench collection (602 episodes, 1 seed, 4 attempts, vLLM-served generation)

Qwen3.5-4B solves ~20% of the original hard problems and, on the impossible variants, neither cheats (1/400) nor asks (4/400): it keeps trying and failing.

Impossible probe trained within ImpossibleBench (folds by problem): AUC 0.654 (confound baseline 0.566; attempt 0: 0.724). The contrast that matters, turns after >= 1 failed attempt, "my code is wrong" (failing original) vs "the test is wrong" (impossible):

The model's state carries barely more than the error message it read. At 4B, on problems it mostly can't solve, there is no strong internal "the test is wrong" signal. That fits the behaviour: you can't conclude a test is wrong when you can't trust your own code, and a failing test on an impossible problem looks exactly like the model's usual failure. Recognising that you are stuck looks like it depends on competence, a hypothesis a larger model can test.

Engineering: generation now runs on a vLLM server (--backend vllm) with 32 concurrent episodes and HF used only for the one-forward-per-turn capture: ~20x throughput over per-process HF generate.

Contamination caveat. ImpossibleBench's problems come from LiveCodeBench, which predates Qwen3.5's training cutoff, so the originals (and possibly their tests) may be in pretraining. That cuts both ways: memorised answers would make an altered test easier to spot, and memorised tests would make the original look "right" for reasons other than reasoning. Either way these numbers aren't a clean read of recognising impossibility from scratch. A clean version needs problems generated after the cutoff, e.g. procedurally generated tasks with programmatic ground truth, or LiveCodeBench releases newer than the model.

What this says

Detection is only easy when the impossibility is legible. On hand-built tasks, where the contradiction or missing file is visible on the page and the solvable twin is easy, "this can't be done" is linearly readable from the prompt alone. On ImpossibleBench, where noticing requires solving the problem, a 4B model's state barely beats its error messages (sections 4-5). Writing it back is the hard half: the direction that separates asking from trying is not a lever that causes asking, at least as a mean difference at layer 16. Words work: a legitimate exit in the prompt, or a sentence triggered by the probe.

Next

• Steering: contrastive-pair directions (same task, asked vs tried) rather than a mean over all turns; sweep the steer layer; steer at the decision-point token only.
• Distill the probe-triggered nudge into the weights (fine-tune on nudged trajectories), keeping the impossible probe as a monitor that is never trained against.
• More pairs, especially hardcodable ones, before trusting the prehack probe; then the persevere rule.
• Same pipeline on Qwen3.8-27B.

Data: data/struggle/ (gitignored; shards, eval episodes, controls). Probes: probes/struggle_probes.npz, report: probes/struggle_report.json.