Effort modes

myrqen low
myrqen high
myrqen xhigh
myrqen ultra
myrqen auto        # resolve from the project's size, surface, and risk

Higher effort means more depth, never fewer rules. The safety policy and the authorization gates are identical at every level.

The profiles

Exact values from packages/policy/src/effort.ts:

	`low`	`high`	`xhigh`	`ultra`
Reasoning passes	1	2	3	4
Validation passes	1	2	3	4
Max parallel investigations	2	4	6	8
Wall-clock budget	8 min	25 min	50 min	110 min
False-positive challenge pass	no	yes	yes	yes
Identity matrix depth	1	2	3	3
Breadth	focused	broad	broad	comprehensive

low — fast developer signal

A rapid repository map, high-signal source, configuration, secret, and dependency checks, a focused local runtime smoke test where one is available, validation of obvious high-impact candidates, and minimal exploratory branching.

high — the serious default

Broader route, authentication, and data-flow analysis; targeted runtime validation; access-control identity comparisons; deeper validation and deduplication; remediation context.

xhigh — pre-release depth

Multiple reasoning and validation passes, wider business-logic and cross-route analysis, more identity and state combinations, and stronger independent confirmation before an important hypothesis is closed.

ultra — maximum practical local depth

Comprehensive source and runtime surface mapping, repeated validation and alternative-path analysis, a broad local test matrix, an extra false-positive challenge pass, and detailed coverage and limitations.ultra must still terminate. The wall-clock budget is what makes that a guarantee rather than an intention, and progress is shown rather than silently looped.

How `auto` resolves

auto scores the project’s risk and surface, then maps the score to a profile. Signals and their weight:

Signal	Score
Authentication implementation detected	+2
Role or privilege separation detected	+2
Payment or billing integration detected	+2
Database access layer detected	+1
File upload or download surface detected	+1
Server-side outbound requests detected	+1
One or more external origins referenced by project configuration	+1
60 or more routes mapped	+2 (20–59 routes: +1)
900 or more source files	+2 (250–899 files: +1)

The mapping:

Score	Resolves to
9 or more	`ultra`
6 to 8	`xhigh`
2 to 5	`high`
0 to 1	`low`

Both values are recorded — requested: "auto" and the resolved profile — so results stay comparable across runs. The rationale is a list of plain sentences you can read back:

{
  "requested": "auto",
  "resolved": "xhigh",
  "rationale": [
    "auto resolved to \"xhigh\" (risk/surface score 7).",
    "Authentication implementation detected.",
    "Role or privilege separation detected.",
    "Database access layer detected.",
    "34 routes or endpoints mapped.",
    "No local runtime was reachable, so dynamic validation depth is reduced for this run."
  ]
}

Three conditions are appended to the rationale as honest caveats rather than being silently absorbed:

no local runtime was reachable, so dynamic validation depth is reduced,
fewer than two test identities are configured, so object-ownership comparisons may be limited,
isolated runtime checks are unavailable on this machine.

What effort does not do

It does not change what is authorized. assertEffortDoesNotWeakenSafety exists precisely so this cannot drift.
It is not a token budget. Token usage is reported with provenance (exact, estimated, unavailable), never allocated.
It does not make the scan omniscient. ultra is deeper, and the report still states what was not assessed.

Getting started

Core concepts

Guides

Reference

Troubleshooting

The profiles

How `auto` resolves

What effort does not do

​The profiles

​How auto resolves

​What effort does not do

The profiles

How `auto` resolves

What effort does not do