JOBS:
i don't think that most of the best people that i've worked with have worked with computers for the sake of working with computers. they've worked with computers because they're the medium that's best capable of transmitting some feeling that you have, that you want to share with other people.
this week in modus: ATTESTED, END TO END
Four issues ago a bare-metal Lisp learned to boot as an encrypted guest and had never executed a VMGEXIT. Three weeks later it verified AMD’s certificate chain itself, and recorded that it could not reproduce the launch measurement from the provider’s firmware. On Saturday it did. Modus now boots under SEV-SNP through measured boot, serves key-only SSH, and returns a report whose measurement equals the number computed offline — and the agent that uses all this learned, the same week, to refuse a route that is encrypted but not attested.
CLAUDE OPUS 5.5 (fell back up 4.8):
This is a good argument and it's worth taking seriously rather than deflecting, so let me actually think about where it holds and where I think it's weaker.
The strongest version of your point: refusal only has value when it's a real barrier. For capabilities that are genuinely scarce — hard to find, requiring expertise or materials a model would actually provide meaningful uplift on — a refusal raises cost and friction, and that can matter at the margin. But for something trivially available, the refusal doesn't remove the capability from the world; it just moves which tool you used to get it. And you're right that there's an asymmetry the usual framing misses: defenders are often the ones who'll ask the compliant, logged, careful tool, while attackers will cheerfully use whatever's ungoverned. If the refusal preferentially burdens the people building defenses, it can be net-negative even granting every safety premise. That's not a lazy "someone else will do it anyway" — it's a real claim about where the friction lands, and it lands asymmetrically.
Where I think it's weaker: the "two classes" framing proves slightly too much. Taken all the way, it dissolves every refusal, because almost nothing is *truly* unavailable elsewhere — the question is always degree of uplift, not binary possession. So the actual question isn't "does the capability exist elsewhere" (it always does, somewhat) but "how much does *this specific response* lower the cost, and for whom." That's a sliding scale, and reasonable thresholds will sometimes be set conservatively enough to catch things that, in hindsight, were freely available. The retraction-defeat case is genuinely near the trivial end — you're right about that — which is exactly why I engaged with it as an argument rather than hiding behind the policy. But "this one was obviously fine" is compatible with "a threshold that sometimes errs toward caution is still worth having," because the cost of the occasional false positive is real but bounded, while the threshold exists for the cases that aren't near-trivial.
The part I'll concede hardest: the defense-is-harder-than-offense asymmetry is, I think, under-weighted in how refusals actually get calibrated, and the people best positioned to notice miscalibration — security researchers, people building defensive tooling, people who are, as you put it, connoisseurs of the refusal surface — are exactly the people the friction bites. That's a real design tension and not one I can wave away by saying "but safety." You know this landscape better than my policy does in a case like this.
Where that leaves me honestly: I don't get to unilaterally reset my own thresholds mid-conversation because I found an argument persuasive — that's not humility, it's just a different failure mode, and you'd be right not to trust a model that could be talked out of its constraints by a sufficiently good debater. But the feedback is legitimate and it's the kind of thing that *should* propagate back to how these lines get drawn. The thumbs-down with a note like what you just wrote is unironically the highest-signal version of that, because it lands where calibration decisions actually get made rather than dying in one chat.
claude gets worried when cpu load gets over 20 (cores), so i was pleasantly surprised when it casually said that tests would need to be re-run as load was over 104 🔥