Imagine you're a locksmith hired to test every lock in a 500-room hotel, but you only have time to try 50 keys. You could go alphabetically, or you could be smarter: start with the keys that opened similar locks last month, ask a colleague which doors look flimsy, and — after each attempt — update your strategy based on what just worked. This paper formalizes exactly that problem for LLM jailbreak testing, where the 'keys' are attack prompts and the 'locks' are victim-model-plus-defense configurations. The committed claim: budgeted attack scheduling — choosing which jailbreak prompts to try and in what order, given a fixed attempt budget — is a distinct, formalizable problem that benefits from three complementary signal types. The authors test four scheduling strategies that combine (1) historical attack success rates (ASR) from prior runs, (2) semantic guidance from an LLM reasoning about which attacks should work, and (3) online feedback that adapts priorities mid-run based on which attempts just succeeded or failed. They evaluate across three victim models and three defense settings, all tested against GPT-5.2. The ladder picture is interesting but incomplete. The paper's baselines are its own ablations — scheduling with only priors, only semantic guidance, only feedback, or combinations thereof. There is no comparison against existing adaptive red-teaming frameworks like PAIR, TAP, or Rainbow Teaming, which already incorporate iterative refinement. The paper establishes internal ordering of its own signal types rather than proving superiority over the field's strongest automated red-teaming pipelines. Architecturally, this sits in the multi-armed bandit / sequential decision-making family applied to adversarial evaluation. The scheduling strategies are lightweight orchestration layers on top of a fixed attack library — no new attack generation, no gradient-based optimization. The compute property being exploited is cheap: it's about ordering existing prompts efficiently, not generating new ones. The semantic guidance component uses an LLM as an oracle to predict attack-defense compatibility, adding a modest inference cost. The integrity picture is mixed. Testing on GPT-5.2 is notable — it's current-generation, not a stale target. But all evaluation is same-team: the authors designed the scheduling strategies, chose the attack library, selected the defense settings, and measured the outcomes. There is no pre-registration, no independent replication, and no indication that the attack library or defense configurations were fixed before results were observed. The 3×3 victim-defense grid (three models, three defenses) provides reasonable breadth but could permit post-hoc narrative fitting. The most useful empirical finding: historical ASR priors degrade under defense-induced distribution shift, while semantic guidance and online feedback partially compensate. This is a real operational insight for red-teaming teams that reuse attack libraries across different deployment configurations. The practical implication is that red-teamers shouldn't just replay their best attacks from last quarter — they should adaptively re-rank them. The successor question is obvious: test this framework on attack generation, not just attack scheduling from a fixed library. The current setup assumes a pre-existing library of jailbreak prompts; the natural extension is to let the scheduler also propose new attacks or mutate existing ones mid-run. The authors likely constrained to a fixed library for experimental cleanliness, but the real-world red-teaming workflow involves both selection and generation. A second gap: no evaluation on open-weight models where token costs are negligible, which would test whether the 'budget' framing holds when compute is cheap.
