What a scan actually costs, and how to control it
Scan depth, reasoning level, flow budgets and per-stage model selection are the four knobs that decide what a Parlix run costs. Here's how to set them.
An agentic scan has a genuinely variable cost, and a tool that hides that from you is setting you up for an unpleasant invoice. Parlix exposes the knobs instead. This is a practical guide to which ones matter.
The four knobs
Flow budget
The single biggest lever. Flow extraction typically finds far more paths than are worth
auditing, ranked by how likely they are to matter. max_flows caps how many proceed.
Cost scales close to linearly with this number. A budget of 50 on a mid-sized service covers the paths that matter for a per-branch check; the nightly run is where you lift it.
Scan depth and reasoning level
Depth controls how far the audit stage will chase indirect flows — through helper layers, dependency-injected services, and across module boundaries. Reasoning level controls how much deliberation each stage is allowed per flow.
Raising either finds subtler bugs. Raising both at once on a large repository is the most common way to be surprised by a bill.
Per-stage model selection
Not every stage needs the same model. In practice the split that works:
| Stage | What it needs |
|---|---|
| Flow extraction | Breadth and speed — a fast model is fine |
| Stack inspection | Runs once per codebase; worth a strong model |
| Security audit | The judgement-heavy stage; spend here |
| Validation | Cheap filtering, high volume |
| Search | Strong reasoning on a much smaller set |
| Verification | Strongest model you’re willing to pay for |
| Chaining | Runs on a handful of findings; cost is negligible |
The pattern: spend where the input set is already small and the judgement is hard.
Parallelism
max_parallel_flows trades wall-clock for burst cost. It doesn’t change what a scan costs
in total, only how fast you get there — useful when a scan gates a merge, irrelevant
overnight.
Caching is free money
Parlix caches by codebase hash, and separately per stage. Re-running against an unchanged tree costs nothing. More usefully, the expensive early stages — extraction and stack inspection — survive across scans of the same codebase, so iterating on audit settings is much cheaper than the first run suggested.
The cache-ignore flags exist for when you’ve changed something the hash can’t see. Reach for them deliberately, not by default.
Two profiles that work
Per-branch (fast, cheap, runs often)
- Modest flow budget, standard depth and reasoning
- Fast models on extraction and validation
- Higher parallelism, since something is waiting on it
- Severity filter set to hide the low tier
Nightly (deep, slower, runs once)
- Flow budget several times higher, chaining enabled
- Strongest models on audit, search and verification
- Lower parallelism, nothing is blocked
- No severity filter — you want the full picture
Start there, then move one knob at a time. Changing three at once tells you the cost went up without telling you which change bought you anything.
Curious what Parlix finds in your code?
Point it at one repository and we'll walk you through every verified finding.
Book a demo