Move both actions together, take over on a new pick, show it in the panel

Three things, all the same underlying point: the picker panel is where the model
changes, so that is where the state of the model belongs.

Both buttons now say what is happening. _actions took a label for Classify and
hardcoded Evaluate's, so only one of the two ever reported the wait even though
they gate on the same weights; it now takes one busy label and applies it to
both, and hands each its own label back when ready.

Picking again mid-download takes over instead of being ignored. Gradio drops a
submission made while one is pending -- trigger_mode is "once" for everything
except .change, so the .then(warm) chain was silently discarding the new pick,
and the buttons would then unlock for a model nobody had selected. With
"multiple" and no concurrency limit the new pick starts at once, and warm records
what the session is waiting on: a load that finds itself superseded returns
without yielding, leaving the buttons to whoever is current. Keyed by
session_hash, so two visitors picking different models do not strand each
other's interface. The abandoned download still finishes in its thread, since a
blocking hf_hub_download cannot be interrupted, but it only fills the cache.

A status line next to the repo date carries Gradio's own progress animation via
show_progress_on, and then reports "Ready . N ms per call" -- an info that cannot
exist before the weights do, which is exactly why the component reads as loading
until it can. It measures a second inference, not the first: the first absorbs
torch's lazy init and read 138 ms where a real click costs tens, so reporting it
would have restated the bug this all started with.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -80,17 +80,35 @@ then the cases one by one, errors first.
 ## Clicking Classify never downloads
 
 Both action buttons start disabled, and the picked revision is fetched up front:
-on page load, on picking a model, and on picking a commit. While that runs,
-Classify reads *Downloading the model…* and is greyed out. So a click is only
-ever inference, and the `ms` reading next to the prediction is measured after the
-load — it is inference alone, not a download that happened to be first.
-
-Warming is wired so it runs once per pick. `model.change` updates the revision
-menu and *then* warms, so it reads the revision the switch just chose rather than
-the previous repo's commit; the revision menu warms on `.input`, which is
-user-only, so the programmatic update that `model.change` just made does not warm
-a second time. A revision that fails to load hands the buttons back and reports
-why, instead of leaving a dead interface.
+on page load, on picking a model, and on picking a commit. While that runs, both
+buttons read *Downloading the model…* and are greyed out — they wait on the same
+weights, so they move together. A status line in the picker panel says the same
+thing, and Gradio's own progress animation sits on it via `show_progress_on`, so
+the feedback appears where the change was made rather than down in a tab.
+
+That line then reports `Ready · N ms per call`, which is the point of putting it
+there: the number cannot exist until the weights do, so until then the component
+is simply loading. It comes from two inference calls at warm time — the first
+absorbs torch's lazy init, the second is the one measured — so it matches what a
+click will actually cost instead of reporting the init as if it were latency. For
+the same reason the `ms` beside a prediction is timed after `load()`: inference
+alone, not a download that happened to be first.
+
+Picking again mid-download takes over. Gradio would otherwise drop the new pick
+(`trigger_mode` defaults to `"once"` everywhere except `.change`) or queue it
+behind the running download (`concurrency_limit` defaults to 1), so both are set
+explicitly. `warm` then decides which pick still owns the buttons: it records what
+the session is waiting on and, if that changed while it was loading, returns
+without touching anything and leaves the newer pick in charge. The abandoned
+download does finish in its thread — a blocking `hf_hub_download` cannot be
+interrupted — but it only fills the cache, and nothing stale reaches the screen.
+
+Warming runs once per pick. `model.change` updates the revision menu and *then*
+warms, so it reads the revision the switch just chose rather than the previous
+repo's commit; the revision menu warms on `.input`, which is user-only, so the
+programmatic update `model.change` just made does not warm a second time. A
+revision that fails to load hands the buttons back and reports why, instead of
+leaving a dead interface.
 
 ⇧ Enter still submits while a model is loading — you can paste a transcript
 during the download, and an early keypress simply waits on the same load.

app/handlers.py

@@ -9,7 +9,18 @@ from . import evaluation
 from .config import display
 from .hub import model_repos, newest, revisions
 from .predictors import load
-from .text import CLASSIFY, EVALUATE, LOADING, NO_MODEL, SCORING, WARM_FAILED, WARMING, pushed_at
+from .text import (
+    CLASSIFY,
+    EVALUATE,
+    LOADING,
+    NO_MODEL,
+    SCORING,
+    WARM_FAILED,
+    WARMING,
+    pushed_at,
+    ready_text,
+    status_line,
+)
 from .turns import window
 
 EXAMPLES = json.loads((Path(__file__).parent / "examples.json").read_text(encoding="utf-8"))
@@ -29,24 +40,44 @@ def classify(repo: str, revision: str, transcript: str) -> tuple[dict[str, float
     return scores, text, f"`{sha[:7]}` · `{elapsed:.0f} ms`"
 
 
-def _actions(classify_label: str, ready: bool) -> tuple[gr.Button, gr.Button]:
-    return gr.Button(classify_label, interactive=ready), gr.Button(EVALUATE, interactive=ready)
+def _actions(ready: bool, busy: str = "") -> tuple[gr.Button, gr.Button]:
+    """Both actions at once: they wait on the same model, so they move together."""
+    return (
+        gr.Button(busy or CLASSIFY, interactive=ready),
+        gr.Button(busy or EVALUATE, interactive=ready),
+    )
+
 
+# What each session is waiting on, so a pick that got superseded lets go quietly.
+_awaited: dict[str, tuple[str, str]] = {}
 
-def warm(repo: str, revision: str):
-    """Fetch the picked revision up front, so Classify only ever runs inference."""
+
+def warm(repo: str, revision: str, request: gr.Request):
+    """Fetch the picked revision up front, so an action only ever runs inference."""
     if not repo:
-        yield _actions(CLASSIFY, ready=False)
+        yield (*_actions(ready=False), status_line(NO_MODEL))
         return
 
-    yield _actions(WARMING, ready=False)
+    pick = (repo, revision)
+    _awaited[request.session_hash] = pick
+    yield (*_actions(ready=False, busy=WARMING), status_line(WARMING))
+
     try:
-        load(repo, revision)
+        predictor, _ = load(repo, revision)
+        sample = [EXAMPLES[0]["text"]]
+        predictor(sample)  # the first call pays torch's lazy init; pay it here
+        started = time.perf_counter()
+        predictor(sample)  # so the reading matches what a click will cost
+        ms = (time.perf_counter() - started) * 1000
     except Exception as failure:
+        if _awaited.get(request.session_hash) != pick:
+            return
         # a bad revision must hand the buttons back, not dead-end the interface
-        yield _actions(CLASSIFY, ready=True)
+        yield (*_actions(ready=True), status_line(WARM_FAILED))
         raise gr.Error(f"{WARM_FAILED}: {failure}") from failure
-    yield _actions(CLASSIFY, ready=True)
+
+    if _awaited.get(request.session_hash) == pick:  # else a newer pick owns the buttons
+        yield (*_actions(ready=True), status_line(ready_text(ms)))
 
 
 def summary(report: evaluation.Report) -> str:

app/text.py

@@ -37,3 +37,13 @@ def pushed_at(when: datetime | None) -> str:
     if when is None:
         return ""
     return f"<sub>Repo last updated {stamp(when)}</sub>"
+
+
+def status_line(text: str) -> str:
+    """Line beside the repo date: what the picked model is doing."""
+    return f"<sub>{text}</sub>"
+
+
+def ready_text(ms: float) -> str:
+    """Only knowable once the weights are here, which is why it reads as loading."""
+    return f"Ready · {ms:.0f} ms per call"

app/ui.py

@@ -5,12 +5,21 @@ import gradio as gr
 from .config import REFRESH_SECONDS, display
 from .handlers import EXAMPLES, classify, evaluate, pick_revision, refresh, warm
 from .hub import model_repos, newest, revisions
-from .text import CLASSIFY, EVALUATE, HEADER, PLACEHOLDER, TRANSCRIPT_INFO, pushed_at
+from .text import (
+    CLASSIFY,
+    EVALUATE,
+    HEADER,
+    PLACEHOLDER,
+    TRANSCRIPT_INFO,
+    WARMING,
+    pushed_at,
+    status_line,
+)
 
 CMD_ENTER_JS = (Path(__file__).parent / "cmd_enter.js").read_text(encoding="utf-8")
 
 
-def selectors() -> tuple[gr.Dropdown, gr.Dropdown, gr.Button, gr.Markdown]:
+def selectors() -> tuple[gr.Dropdown, gr.Dropdown, gr.Button, gr.Markdown, gr.Markdown]:
     pushes = model_repos()
     repo = newest(pushes)
     revs = revisions(repo) if repo else []
@@ -23,7 +32,11 @@ def selectors() -> tuple[gr.Dropdown, gr.Dropdown, gr.Button, gr.Markdown]:
             scale=4,
         )
         reload_button = gr.Button("↻", scale=0, min_width=48)
-    return model, revision, reload_button, gr.Markdown(pushed_at(pushes[repo] if repo else None))
+    with gr.Row():
+        pushed = gr.Markdown(pushed_at(pushes[repo] if repo else None))
+        # Never empty, so Gradio's progress animation has something to sit on.
+        status = gr.Markdown(status_line(WARMING))
+    return model, revision, reload_button, pushed, status
 
 
 def classify_tab() -> tuple[gr.Textbox, gr.Button, list]:
@@ -81,7 +94,7 @@ def build() -> gr.Blocks:
     with gr.Blocks(title="Breakdown risk") as demo:
         gr.Markdown(HEADER)
 
-        model, revision, refresh_button, pushed = selectors()
+        model, revision, refresh_button, pushed, status = selectors()
         selection = [model, revision]
 
         with gr.Tab("Classify"):
@@ -90,19 +103,28 @@ def build() -> gr.Blocks:
         with gr.Tab("Evaluation"):
             evaluate_button, report, progress_target = evaluation_tab()
 
-        # Buttons start dead and the model is fetched up front, so a click is
-        # never a download. .input() is user-only, so the revision update that
-        # picking a model triggers does not warm a second time.
-        actions = [run, evaluate_button]
-        demo.load(warm, selection, actions, show_progress="hidden")
-        revision.input(warm, selection, actions, show_progress="hidden")
+        # Buttons start dead and the model is fetched up front, so a click is never
+        # a download. Every pick warms the same way: "multiple" and no concurrency
+        # limit because Gradio otherwise drops a pick made while one is pending
+        # ("once") or queues it behind that download; warm() itself decides which
+        # pick still owns the buttons. show_progress_on puts Gradio's own animation
+        # on the status line, up in the picker panel where the change was made.
+        warming = dict(
+            outputs=[run, evaluate_button, status],
+            show_progress="full",
+            show_progress_on=[status],
+            trigger_mode="multiple",
+            concurrency_limit=None,
+        )
+        demo.load(warm, selection, **warming)
+        # .input() is user-only: the revision update that picking a model triggers
+        # must not warm a second time.
+        revision.input(warm, selection, **warming)
 
         timer = gr.Timer(REFRESH_SECONDS)
         timer.tick(refresh, selection, [*selection, pushed], show_progress="hidden")
         refresh_button.click(refresh, selection, [*selection, pushed])
-        model.change(pick_revision, model, [revision, pushed]).then(
-            warm, selection, actions, show_progress="hidden"
-        )
+        model.change(pick_revision, model, [revision, pushed]).then(warm, selection, **warming)
         gr.on(
             [run.click, transcript.submit],
             classify,