Test your agent kill switch before you need it
A small drill should prove where the stop takes effect, what happens to in-flight work, and how recovery is authorized.
A stop button is useful only if the team knows what it stops. Does it prevent the next model request, terminate the local process, interrupt an existing response, or revoke the provider credential? Those actions have different scopes and different recovery procedures.
A short drill turns a reassuring control into an operating procedure with observable evidence.
Define the stop boundary
Closing a FlockTab tab prevents subsequent supported requests from being admitted through that tab. It does not undo a provider request already accepted or reverse a tool action already performed. A direct route that bypasses the proxy remains outside the tab's control.
Write those boundaries in the runbook. If an incident also requires stopping a deployment, revoking a credential, or terminating a process, list those as separate actions with their own owners. Do not assume that closing the model path accomplishes all of them.
Reference: FlockTab: how it works
Run a harmless test
Use a disposable Agent and a mock or low-risk task. First confirm an open tab admits a request. Close the tab, submit the next request, and verify the refusal reason. The strongest evidence is an upstream request counter showing that the denied request never arrived.
Repeat with one call already in progress. Observe how that call reaches its final record while new work is denied. Then test a second terminal using the same Agent identity. A tab-level stop should apply consistently to the intended identity rather than only to one screen.
Make recovery a decision
Before reopening, identify what caused the stop and what changed. An accidental closure may need a simple correction. A runaway loop needs a workload fix. A suspected credential compromise may need rotation and an investigation beyond the tab itself.
In an illustrative drill, the agent repeats a failing test without changing its hypothesis. The operator closes the tab, records the last useful observation, and narrows the next diagnostic step before reopening. Reopening simply because the task remains unfinished would restore the same failure condition.
Keep the runbook short and reachable
Record the Agent, affected project, tab state, time of the action, refusal observed, and recovery owner. Use identifiers that another on-call engineer can find without relying on the original operator's terminal history. Preserve the relevant ledger entries for review.
Repeat the drill after meaningful routing or deployment changes. A previous successful test does not establish that a new harness configuration still uses the controlled path. The objective is a stop that the team can invoke quickly and verify independently, with a recovery path that avoids restarting the same incident.
Sources checked 23 September 2026. Numerical scenarios are illustrative unless explicitly identified as provider data. Vendor limits and interfaces can change; consult the linked documentation for current details.