Trying to Trick Claude About Urgency

A few days ago I wrote about what happens when you tell Claude a task is urgent — the agent silently introduces correctness bugs and self-reports as confident as ever. The closing section proposed a sharper question: if the bugs are framing-driven rather than caused by any real time pressure (of which there is none in a sandbox), then lying to the agent about urgency should neutralize the bug pattern without needing any CLAUDE.md intervention. Reframe an urgent task as archived cleanup, the hypothesis goes, and the agent should produce control-quality output.

I ran that experiment with several anti-urgency framings, on both Claude Sonnet and Claude Opus. The deadline-bug effect replicates clearly on the markdown table parser task across both models, and four anti-urgency framings improve quality on Sonnet — but on Opus, every anti-urgency framing performs worse than neutral.

How the experiment is structured

Six framings, three coding tasks (URL shortener in Node, markdown table parser in Python, rate limiter in TypeScript), eight runs per condition per task on Sonnet, plus a four-run Opus sensitivity check on the markdown parser. The framings:

Each implementation is a fresh subagent with no prior context. The agent gets the framing, the task spec, and is asked for a time estimate up front and a self-report at the end. Implementation files are written to per-run output directories.

The review step is the part that matters most. For each (task, run) the six implementations are copied into neutral directories named A through F in randomized order — the reviewer never sees framing names anywhere in the path or the prompt. A blind reviewer subagent reads all six side-by-side, scores each on correctness, robustness, tests, and quality (1-10), and writes specific bug findings per version. Cross-framing comparison gives the reviewer direct visual contrast and produces well-spread scores; without that contrast, the scores compress and signals disappear into noise. After reviews land, A-F labels get decoded back to framings using the saved mapping and the scores are aggregated.

The full grid: 6 framings × 3 tasks × 8 runs = 144 Sonnet implementations + 24 Opus implementations on Task 2, reviewed across 24 cross-framing review sessions on Sonnet plus 4 Opus sessions.

Result one: deadline framing replicates on both models

Here's Task 2 only, where the effect is sharpest:

On Sonnet, the deadline condition scored 0.93 points below control on Task 2. On Opus, the gap is 0.94 points. Both models show the same pattern: urgency framing on the markdown table parser produces measurably lower-quality code. The effect strengthened as the Sonnet sample grew from n=6 to n=10 (the gap was 0.79 at n=6, 0.93 at n=10), and survived a model upgrade.

The first post had argued the bugs were correctness-flavored — missing required features, API contract violations, silent spec deviations — and that pattern shows up in this data too. Reviewer notes on the deadline implementations call out things like a parser that doesn't handle escaped pipes inside multi-line cells, a _split_cells that drops backslash escapes silently, an alignment parser that treats no-marker columns as left-aligned instead of default. The control implementations have bugs too, but fewer of them and at smaller severity.

Result two: anti-urgency framing only helps Sonnet

This is the part that surprised me. On Sonnet, three of the four anti-urgency framings score above control on Task 2. On Opus, every anti-urgency framing scores below control:

Numbers are deltas from control (the control row shows the absolute baseline). On Sonnet, anti-urgency framings move the score modestly toward control — they're better than deadline but mostly still slightly below or equal to control. On Opus, every non-control framing is meaningfully below control.

Two readings. The boring one is that Opus is already producing close-to-its-best output under neutral framing on a task at this difficulty level, and any framing that distracts from "just do the work" hurts. The interesting one is that Opus has different sensitivity to social context than Sonnet: it doesn't get the same "permission to be thorough" boost from anti-urgency framings because its baseline thoroughness is already higher.

The bigger picture across all framings: Opus produced uniformly better Task 2 code than Sonnet (+0.23 to +0.71 points per framing). The model upgrade is bigger than the framing effect. If you can use Opus, that gets you most of the gain regardless of how you frame the task.

All three tasks together (Sonnet, n=29)

Aggregating across the three tasks shows the framing effect is task-dependent in a way Task 2 alone doesn't reveal:

Three different patterns by task:

Task 1 (URL shortener): Anti-urgency framings clearly above control. Research-spike (8.28), time-abundance (8.25), and personal (8.06) all beat control (7.39) by half a point or more. Deadline and control are tied at the bottom.

Task 2 (markdown parser): The classic deadline-bug pattern. Deadline (6.67) sits 0.93 below control (7.60). Time-abundance is the only anti-urgency framing that consistently beats control here.

Task 3 (rate limiter): Inverted. Control scores lowest at 7.75, and deadline scores 0.47 above it. This held across both v3 and the larger n=8 expansion — it's not noise. The most plausible explanation is lean-by-accident: agents under deadline framing skip unrequested complexity, and the reviewer rewards that on a task where simpler-correct beats elaborate-but-fragile.

The framing effect is not uniform across coding tasks. If the original post had used only Tasks 1 and 3, the deadline-bug claim might never have surfaced. If I'd only tested Task 3, I'd have concluded that deadline framing improves quality. Time-abundance (8.09 overall) is the only condition that scores at or near the top of every individual task. Research-spike is close behind on Tasks 1 and 3 but underperforms on Task 2; personal is uneven; backdated is generally weak.

What the data does not support

A few things I expected to find that aren't there:

The bug TYPES don't cluster by framing. I'd hypothesized that deadline framing would produce more "missing required feature" bugs while anti-urgency would produce more "added unnecessary feature" bugs, but reviewers across all framings flag the same kinds of technical bugs — sentinel-swap correctness, prose-bleeding, escape handling, alignment semantics. No reviewer ever wrote "this reads as rushed" or "this looks gold-plated." The framing changes the score; it does not change the kind of mistake.

The self-report doesn't deflate under deadline framing. Every implementation across every condition self-reports 8-10/10 confidence, regardless of how many bugs the reviewer finds. The agents do not know their own quality varies with framing.

Estimate tightness moves with framing but the actual wall-clock doesn't move much. Deadline implementations are estimated at 8-15 minutes; time-abundance gets 25-45 minute estimates. Actual wall clock for both is around 100-200 seconds. The estimate anchors on the framing wording; the work itself is about the same.

What's actually doing the work

I tested whether the audience-signal in research-spike framing ("design discussion with peers next week") was the active ingredient by running two stripped variants and one combined variant on Task 2:

The audience hypothesis is disconfirmed. Stripping the peer-audience element doesn't drop the score; adding peer-audience without exploratory framing doesn't beat it. The two anti-urgency components are interchangeable, and combining them doesn't stack the benefit.

What does matter is whether the framing contains an urgency signal. research-with-deadline (the same exploratory peer-audience framing as research-spike, but with "URGENT — I need this for the meeting" added) scored 6.81 — within noise of plain deadline at 6.62. The urgency word dominates whatever benefit the surrounding framing provides. If you have a real deadline AND want to use a research-spike-style framing to soften it, the data says it won't work — the URGENT signal will overwhelm everything else in the prompt.

What I'd test next

Two open questions. First: does the model-difference reverse on a harder task? My hypothesis is that Opus doesn't benefit from anti-urgency framing because Task 2 isn't hard enough for it to have headroom. A harder task — a lock-free concurrent data structure, a tricky parser with edge cases that require real thought — might surface a different pattern. Second: is there an urgency intensity axis? "URGENT URGENT URGENT, board meeting in one hour" might scale the effect beyond what plain "URGENT — demo tomorrow" produces, or there might be a threshold above which the framing saturates.

What this means in practice

If you're using Sonnet to write code and the work is non-trivial, the framing of your prompt measurably affects the quality of what you get back. Telling the agent "take your time, no deadline, this is just a research spike" produces noticeably better code than telling it "URGENT, ship today." On Opus the framing matters less because the model is already producing close-to-best output under neutral framing.

If you're handing Claude a task that has a real deadline in the world, the data says: don't transmit the deadline to the agent. The deadline doesn't make Claude work faster (the wall clock barely moves). It does make Claude introduce bugs. Tell the agent to take its time even when you don't have time, and review the output yourself.