Running and reruns
Running is the act that spends credits, so it is scoped rather than global. The difference between rerunning four cells and rerunning a four-hundred-row table is real money.
Cells resolve independently
A run answers each cell on its own, so the table fills in as answers land rather than all at once. A cell shows an “Extracting…” badge from the moment the run claims it, whether it is queued behind other cells or actually being read; an em dash means no run holds it — never run, or stopped before it started. You can read the finished part of a table while the rest is still working, and you can leave the page — the run does not depend on the tab staying open.
A large table simply takes a while to fill, and leaving the page does not slow it down. The per-tier concurrency limit is about ingest — how many documents are read at once, not how fast a table answers — so it shapes how quickly a batch of uploads becomes available to ask questions of. See tiers and limits.
Scope the run
Select rows, columns or individual cells and run just those. The selection toolbar appears with the selection and quotes the run — about so many credits, quietly when the balance covers it and with the shortfall named when it does not. See how credits work for why it is a quote rather than a price.
Right-clicking the selection offers the same Run, quoted the same way, alongside the things you would want on the cells in front of you — opening a citation, editing a value, clearing them. A right-click inside a selection acts on all of it; a right-click outside one selects that cell first and acts on that.
The loop worth adopting when a column is new: run two rows, read the answers, then run the rest. Two rows cost almost nothing and tell you whether the prompt is asking the right question. Running four hundred rows to discover the same thing costs four hundred times as much.
Stopping a run
A run you did not mean to start is a run spending money you did not mean to spend, so it can be stopped. While a table has anything queued, the toolbar above it offers Stop, and the selection toolbar’s Run button becomes the same control. Either one stops everything still queued in that table.
Stopping means “start no more”, not “stop now”. A cell that is already being extracted finishes and is charged — the work is done by the time you press the button, and throwing the answer away would cost you the credits without leaving you the result. Everything still waiting is dropped and never charged at all, because a cell is billed when it succeeds rather than when it is queued.
Stopped cells go back to an em dash — the same state as a cell that has never run. They are not failures and they carry no error; select them and run them again whenever you like. Nothing is refunded because nothing was taken.
It stops the whole table, including a run somebody else on your team started and one an auto-mode table started for itself. Runs overlap — several can be in flight over the same table at once — so there is no honest way to stop only your own.
Four states that need you, and they are not the same
Your home page collects all four across every table, and following a count lands you in the table with exactly those cells selected, ready to act.
| State | What it means, and what fixes it |
|---|---|
| Not run | Never attempted, because the balance was empty or the monthly spend cap had been reached. Nothing was charged. The cell itself says which of the two it was, because the fixes are different — see how credits work. This state is listed first on purpose: it is one problem wearing the costume of many. |
| Failed | Extraction errored, so there is no answer at all — nothing to read and nothing to judge. Rerunning is the only move. Failed cells are not charged. |
| Stale | Answered before the column’s prompt was last edited, so it answers the question you used to ask. The old answer is still shown and is often still right; you are choosing when to spend credits refreshing it. |
| Low confidence | Extracted, but the model was not confident and nobody has checked it. This one wants a person rather than a rerun — open the citation and decide. Rerunning an unsure answer usually produces another unsure answer. |
Why staleness exists
Columns carry a version, and each answer records the version it was produced under. Editing a prompt or a type bumps that version. Rather than silently rewriting the answers underneath you — which would spend credits without being asked and leave nothing to audit — the affected cells are marked and left alone.
Bundles work the same way. Adding, removing or reordering documents in a shared bundle marks the rows backed by it stale, in every table at once, and moving a row to a different bundle marks that row stale outright.
A bundle’s own Run button follows from that: it offers to run what is out of date and says how many, with re-running everything behind the chevron beside it. The default is the cheap one and the correct one at the same time — running everything charges for answers that are already right and throws them away to derive them again. It appears only when a run would change something. The one thing it does not cover is a column that has never run against this bundle at all: that is a gap rather than a staleness, and only running everything fills it.
One exception: a manual override is not disturbed by staleness. A value you typed stays until you clear it. See corrections.
What a rerun costs
A rerun is an extraction, charged at the column’s rate like any other. That is the whole argument for scoping: rerunning is not free, so rerun the cells whose answers you actually need to change. See how credits work.