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 that has not run yet shows an em dash; one in flight shows an “Extracting…” badge. 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.
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.
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.
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.