Scan control and performance

Set sensible budgets, follow progress and understand scan states.

Performance settings

Workflow	Controls in the launch dialog	Initial values
Local Active	Concurrency, Requests per second	10, 10
Local Passive	Threads, Passive Concurrency	10, 10
Local Smart	Threads, Passive Concurrency, Active Concurrency, Requests per second	10 each
Local AI	Threads, AI Analysis Concurrency, Active Concurrency, Requests per second	10, 5, 10, 10
Server Scanner	Concurrency, Requests per second, per-server/overall scope	10, 10; per-server scope initially

For local Active, concurrency is 1–1000 and RPS is 0–1,000,000; zero means unlimited. Worker counts are derived automatically. The removal of the separate Threads control applies to this Active dialog, not to every live/passive/AI setting.

A limit, not a speed guarantee

An RPS setting is a ceiling, not a throughput promise. With concurrency 5 and one-second responses, throughput cannot reach 100 RPS. Increasing concurrency consumes more sockets, memory and target capacity. Start with a small profile set and increase only after measuring responses and errors.

Server's MCP accepts zero as unlimited RPS. The current REST configuration parser only applies positive requestPerSecond overrides, so use a positive explicit RPS from the extension/REST when a predictable limit matters. See API configuration.

States

Display	Meaning
Waiting / Queued	Work has not started executing yet.
Running	Execution is in progress.
Paused	New work is held; an already in-flight request may still complete.
Reconnecting	Pro is recovering contact with the owning server.
Finished	Execution ended. Check warnings and failed-request counters.
Incomplete	Local work stopped after completing some requests but before normal completion.
Failed	Local work could not complete any requests before an error/timeout; Server also uses failed for its failure paths.
Cancelled	Work was cancelled. Existing findings are not automatically deleted.

A missing Collaborator prerequisite does not change the displayed terminal state to “Finished (incomplete)”. It still affects coverage and must be considered when interpreting results.

Pause, resume and cancel

Use per-entry controls or the intended batch controls. Pause preserves queued work; resume continues it in the same running process. For Server scans, Pro sends control requests to the server that owns each scan ID. A connection error can delay confirmation: verify the resulting state rather than assuming a click reached the server.

A cancelled scan cannot be resumed. Removing a row or clearing a display is not a substitute for confirming cancellation. Server restart does not resume active work from history.

Progress and duration

The request total can change as execution becomes known, particularly for conditional steps and extra baseline/control work. Compare finished, successful and failed request counts when available. Terminal remote scans include an end time, including scans learned about after reconnection.

Local paused time is excluded from its active timeout accounting. Current local lifecycle classification uses whether any requests completed, not a “95% complete” threshold.

Reducing laptop load

Use remote servers for active HTTP execution, lower local concurrency, select narrower tags and avoid retaining every verbose request unnecessarily. Poll compact MCP progress and request finding evidence selectively. More servers increase aggregate capacity; select Overall limits when you need a fixed combined budget.