Using a tool
Locking a card
Unlocked, a card fires once and closes. Locked, it stays open and every run lands in its own slot in a collecting frame.
Press Run on an unlocked card and it fires once, collapses to a pill, drops its result and closes. That is right for a one-shot and wrong for the way most work actually goes, which is several quick attempts in a row. Click the padlock and the card stays. ## What locking changes - The card **stays open and idle** after each run, with your prompt and settings still in it, ready for the next press - Results stop replacing each other. Each run lands in **its own slot** - The slots collect into a **frame** that grids them as they arrive - A short cooldown sits between presses, so a fast double-click cannot fire twice Fire six runs at a locked card and you end with a tidy grid of six, not six overlapping images you now have to arrange. ## The two loops it is built for **Same prompt, different model.** Lock, then swap the pill between presses. You end with one prompt read several ways, side by side, which is how you pick an engine for a specific job rather than in the abstract. **Same model, different prompt.** Lock, then edit one clause between presses. The grid becomes a record of what each change did, and because the card never closed you never retyped the parts you kept. :::tip[Lock before the first run, not after] The collecting frame starts when the session starts. Locking after two runs collects from there on and leaves the first two where they landed. ::: ## Unlocking ends the session Click the padlock again and the card goes back to closing after its next run. The frame you collected stays on the board as an ordinary frame. It stops auto-gridding, so you can rearrange inside it, and it keeps everything it gathered. Lock again and a **fresh** frame starts. That is deliberate: a session is a line of enquiry, and the boundary between two of them is worth keeping. :::note[Locking is per-card and not shared] The lock is a property of your card in your session. It is not synced to teammates and it does not persist as a board setting, so a colleague opening the board sees the results rather than the lock. ::: ## Cards that lock themselves Two cases turn lock on without you asking. A tool can ship locked by default, when it only makes sense as a series. More often you will meet it through [variables](/docs/using-plnty/using-a-tool/variables-and-batch-runs/). Binding a `{ }` variable in a prompt puts the card into batch mode, which is lock mode driven programmatically: one press, N runs, all of them landing in the same collecting grid.Press Run on an unlocked card and it fires once, collapses to a pill, drops its result and closes. That is right for a one-shot and wrong for the way most work actually goes, which is several quick attempts in a row.
Click the padlock and the card stays.
What locking changes
Section titled “What locking changes”- The card stays open and idle after each run, with your prompt and settings still in it, ready for the next press
- Results stop replacing each other. Each run lands in its own slot
- The slots collect into a frame that grids them as they arrive
- A short cooldown sits between presses, so a fast double-click cannot fire twice
Fire six runs at a locked card and you end with a tidy grid of six, not six overlapping images you now have to arrange.
The two loops it is built for
Section titled “The two loops it is built for”Same prompt, different model. Lock, then swap the pill between presses. You end with one prompt read several ways, side by side, which is how you pick an engine for a specific job rather than in the abstract.
Same model, different prompt. Lock, then edit one clause between presses. The grid becomes a record of what each change did, and because the card never closed you never retyped the parts you kept.
Unlocking ends the session
Section titled “Unlocking ends the session”Click the padlock again and the card goes back to closing after its next run.
The frame you collected stays on the board as an ordinary frame. It stops auto-gridding, so you can rearrange inside it, and it keeps everything it gathered.
Lock again and a fresh frame starts. That is deliberate: a session is a line of enquiry, and the boundary between two of them is worth keeping.
Cards that lock themselves
Section titled “Cards that lock themselves”Two cases turn lock on without you asking.
A tool can ship locked by default, when it only makes sense as a series.
More often you will meet it through
variables. Binding a { }
variable in a prompt puts the card into batch mode, which is lock mode driven
programmatically: one press, N runs, all of them landing in the same collecting grid.