In Streamlit, how do you stop every widget change from rerunning the whole script?

## The problem Streamlit re-executes the whole script on every widget interaction. For a page whose body is a couple of charts over a cached DataFrame that is fine — a rerun costs milliseconds. It stops being fine when the script issues a warehouse query, calls a paid API, or trains something, and the user is typing in a text box. Each keystroke is an interaction, so each keystroke is a full script run. There are four levers, and they are not alternatives so much as layers. ## 1. Make the rerun cheap: caching Before trying to suppress reruns, remove their cost. Wrapping the query in `st.cache_data` means the rerun still happens but the expensive call does not. This is the default answer and solves most cases; the other levers exist for the work that genuinely cannot be cached, such as a mutation, a paid call with side effects, or a computation whose inputs change every time. ## 2. Batch the inputs: st.form ```python with st.form("filters"): region = st.selectbox("region", REGIONS) start = st.date_input("from") minimum = st.number_input("min value", 0) submitted = st.form_submit_button("apply") if submitted: run_query(region, start, minimum) ``` Widgets inside a form do not send their changes to the server as they are edited. The user fills in all three, presses **apply**, and exactly one rerun happens, with all three values updated together. That also fixes a subtler problem: without a form, a user editing three filters causes three reruns, two of which query a half-specified state. Constraints worth remembering: the only button allowed inside a form is `st.form_submit_button`, and widgets inside a form cannot take `on_change` / `on_click` callbacks (the submit button itself can take `on_click`). A form needs a unique key. And a form does not make the *submit* cheap — it makes the intermediate states free. ## 3. Narrow the rerun: fragments A fragment is a function decorated with `@st.fragment`. Widgets inside it trigger a rerun of that function alone; the rest of the script does not re-execute. ```python @st.fragment def detail_panel(df): row = st.selectbox("row", df.index) st.write(df.loc[row]) data = load_expensive() # not re-run when the selectbox changes detail_panel(data) ``` This is the tool for an expensive page with one chatty interactive corner. The mental model shifts slightly — the fragment reruns in isolation, so it sees session state but does not rebuild the surrounding page — and you can still force a full rerun from inside it when you need the page to catch up. Fragments arrived as `st.experimental_fragment` and were later promoted to `st.fragment`, so check what your pinned version exposes; a fragment can also be given a periodic refresh interval, which is the idiomatic way to build a live-updating tile without polling the whole script. ## 4. Gate the work: buttons plus session state Some work should simply not happen unless asked for: ```python if st.button("run backfill"): st.session_state["backfill_requested"] = True if st.session_state.get("backfill_requested"): do_backfill() ``` Remember that `st.button` is `True` only on the run its click triggered, which is why the decision is recorded in session state rather than acted on inline. ## Choosing between them Ask what the rerun costs and what the user is doing. Expensive but pure and repeatable? Cache it. Several inputs that only make sense together? Form. One noisy widget on an otherwise heavy page? Fragment. Something with side effects or a long runtime? Button plus session state, and ideally push the work to a queue so a thread is not held. In a real app you will use three of the four at once, and an interviewer asking this question is usually checking that you know a rerun is the default and that suppressing it is a deliberate design act.