`model` ranks the configurations the gate refuses, and says nothing

[vyncint]

Reproduce

$ launchbound model reduce-flip --cc 8.6
reduce-flip — ESTIMATED ranking (analytical model, cc 8.6; not a measurement):
  model quality: UNCALIBRATED for this kernel (...)
  estimated c1-92b90888689ed588  block_x=128 tile=128  cost 8.533  (occupancy 1.00, ...)
  estimated c1-d81a3ce7670f5122  block_x=128 tile=256  cost 8.533
  estimated c1-d544011c98ae52d1  block_x=128 tile=512  cost 8.533
  estimated c1-9508965d4f9be218  block_x=256 tile=256  cost 8.533
  estimated c1-f3bb7396890c8747  block_x=256 tile=512  cost 8.533
  ...

Now the gate, same kernel, same --cc:

$ launchbound prune reduce-flip --cc 8.6
  x c1-92b90888689ed588  block_x=128 tile=128
      REFUSED RC001 at src/lib.rs:33:13: divergence source `warp_id()` splits a
      128-thread block (4 warps) at a block-wide barrier; safe only at one warp
  x c1-d81a3ce7670f5122  block_x=128 tile=256   REFUSED RC001 ...
  x c1-d544011c98ae52d1  block_x=128 tile=512   REFUSED RC001 ...
  => 3 clean, 0 with caveats, 8 refused, 0 tool errors

The model's top five are all refused. Its first recommendation, block_x=128 tile=128, is a configuration that hangs. The three configurations the gate admits are the model's last three, at 9× the estimated cost.

model's output says nothing about this, and model --help does not mention the gate.

Why this one matters more than it looks

The README's promise is the product:

launchbound ... finds the fastest configuration, and never hands you one that is convergence-unsafe.

an autotuner without a convergence gate will hand you a faster kernel that hangs

model is a documented top-level subcommand, and on the corpus kernel chosen to demonstrate the flip it does precisely the thing the tool exists to prevent. reduce-flip is labelled [known-flip] in the corpus — it is the worked example.

tune --backend model gets this right, and shows what right looks like:

$ launchbound tune reduce-flip --backend model --cc 8.6
  estimated c1-9b9fe33407467e5e  block_x=32 tile=128  cost 76.800
  estimated c1-412245568e2c119a  block_x=32 tile=256  cost 76.800
  estimated c1-3ab9e5140cdd71b0  block_x=32 tile=512  cost 76.800
  (8 candidates refused by the gate; run `launchbound prune` for details)

Same model, same numbers, the gate applied — and it says how many it refused.

The counter-argument, and why it does not hold

model is honest about the other axis: ESTIMATED, not a measurement, UNCALIBRATED. Someone could argue it is a raw cost model and safety is tune's job.

But nothing in the output or the help says so, the two commands are siblings in --help, and the failure is silent and asymmetric: an over-optimistic estimate costs you a slower kernel, while an unsafe configuration costs you a hang. A tool that carefully labels the cheap mistake and says nothing about the expensive one has its warnings the wrong way round.

Fix — one of

1. Gate it, like tune does. Rank the admitted set, report the refused count. Costs model its "NO GPU, no reconverge" property, which is real: model is currently the only command that needs neither.
2. Rank everything, mark the refused. Keep the property, annotate each row (x / refused RC001) and add a line: 5 of the top 5 are refused by the gate — run launchbound prune. This seems the better fit: the model's ranking of unsafe configurations is interesting (it is exactly why the tool exists), and hiding it loses that.
3. Say it in prose — cheapest, weakest, and still leaves the top of the list looking like a recommendation.

Whichever, model --help should name the relationship to the gate.

Done when

launchbound model on reduce-flip cannot be read as recommending a configuration launchbound prune refuses.