Performance for agentic work

Fast checks keep agent work moving.

Assura keeps deterministic repository checks fast enough to run during the edit loop, not only at commit time. Every tracked cold project beats native LS-Lint, and a persistent Assura session widens the gap when checks repeat.

See the measured comparison Inspect regression cases

Current checked cohort 8 / 8 measured

Cold CLI 1.62x faster aggregate

Repeated checks 21.59x Assura session vs rerun native LS-Lint CLI

8 project shapes Equivalent naming and structure policy

Assura release CLI LS-Lint native CLI

Cold: 5 process-to-process samples. Warm: 5 persistent-session samples.

The measured takeaway

Faster than native LS-Lint in all eight cold comparisons.

The speed comparison isolates the policy surface both tools share. Assura-only checks such as file contents, Markdown, references, and agent repair guidance are reported separately.

Option Best at Agent-loop tradeoff

Assura Fast repository-wide structure, content, and policy signals Persistent sessions, bounded output, and repair guidance for early feedback

LS-Lint Fast file and directory naming rules One-shot filesystem checks; no content rules or rule-specific agent repair guidance

Language linters Deep checks inside code for one language or runtime Essential later layer, but not one language-agnostic project signal

Custom scripts and hooks Project-specific checks and delivery gates Performance and output vary; hooks often arrive after a larger batch of work

Only native LS-Lint is included in the numeric benchmark. Other options are shown for workflow context, not as measured speed claims.

Quality policy use case

A package contract agents cannot quietly drift from.

A fully featured Assura policy captures the project practices an agent should preserve. LS-Lint covers the naming subset; the comparison below shows the remaining gap.

Agentic monorepo policy

One contract for every package.

The package tree is required while apps remain optional. Every workspace that exists receives the same guidance, manifest, naming, size, and directory-health policy.

Quality policy example

Expected shape

Broad defaults, exact project contracts.

Project rootAlways checked

AGENTS.md, README.md, and workspace files required
Selected policy is visible and project-owned
Dot directories and generated output are bounded

packages/*/Every package

AGENTS.md and package.json required
Recursive defaults cover nested source and docs
Line and child-count thresholds stay advisory
Exact declarations refine closed wildcard rules

$workspace and $skill rebase the repeated hierarchy, while ./**/ applies one compact health layer to every authored directory.

Configuration comparison

Drag or switch to compare what each config can express.

LS-Lint Assura

AssuraReusable project contract

rules:

# Progressive-disclosure entrypoints.

agent-entrypoint:

max_lines: 160

severity: low

message: See docs/agent-guidance.md.

skill-entrypoint:

max_lines: 500

markdown:

require_frontmatter: true

message: See docs/agent-guidance.md#skills.

# Shared non-blocking directory health.

folder-health:

limit_children: 10

severity: low

message: See docs/structure.md.

# Closed-directory building blocks.

closed-entry:

exists: 0

message: See docs/agent-guidance.md#layout.

closed:

./*/: $closed-entry

./*: $closed-entry

# Repeated directory contracts.

skill:

./: $closed

./{agents,assets,references,scripts}/:

./: exists:0-1

inherit: false

SKILL.md: exists:1 | $skill-entrypoint

workspace:

AGENTS.md: exists:1 | $agent-entrypoint

package.json: exists:1

structure:

# Directories, as shown by an IDE explorer.

.agents/:

./: exists:0-1 | $closed

skills/:

./: exists:0-1

./*/: kebab-case | $skill

./*: $closed-entry

apps/:

./: exists:0-1

./*/: $workspace

packages/:

./*/: $workspace

# Required root files, alphabetically.

AGENTS.md: exists:1 | $agent-entrypoint

package.json: exists:1

pnpm-{lock,workspace}.yaml: exists:1

README.md: exists:1

turbo.json: exists:1

# Direct root dot directories.

./.*/: kebab-case | exists:0-10

# Defaults inside every directory, including root.

./**/:

./: $folder-health

./*/: kebab-case

.{md,js,jsx,ts,tsx}: max_lines:500 | severity:low

.md: kebab-case | exact:AGENTS | exact:README

.{js,jsx,ts,tsx}: kebab-case

exclude: ["**/{node_modules,.next,.turbo,dist,coverage}/**"]

Added by Assura Project-owned rulesRequired and optional pathsReusable hierarchyScoped naming

Performance regression suite Measured fixtures stay separate from the use case.

These generated projects isolate pruning, matcher scale, and configuration lookup against equivalent LS-Lint work.

5-1,501 files per fixture 2-801 directories 1-801 effective rules 5 timed samples

Filesystem pruning

Generated-heavy project

Assura 3.77x

project/

src / index-file.ts
generated / 384 files ignored
coverage / 384 files ignored
52 directories in fixture

LS-Lint source excerpt; converted Assura policy measured

ignore:
  - .assura/**
  - generated/**
  - coverage/**
ls:
  .dir: kebab-case
  .ts: kebab-case

Checked: 2 files
Ignored: 769 files
Shape: 52 dirs
Policy: 2 rules

Why this case is tracked

Proves large generated and coverage areas are excluded before they turn a small source check into unnecessary filesystem work.

Assura cold: 1.50 ms
LS-Lint cold: 5.65 ms
Assura warm: 0.13 ms

High file count

Multipart extension scale

Assura 2.76x

project/

src
file-0000 ... file-1499
*.a.b.c.d.e.f.g.h.i.j.k.js
one kebab-case naming policy

LS-Lint source excerpt; converted Assura policy measured

ignore:
  - .assura
ls:
  .a.b.c.d.e.f.g.h.i.j.k.js: kebabcase

Checked: 1,501 files
Ignored: 1 files
Shape: 2 dirs
Policy: 1 rules

Why this case is tracked

Guards the matcher against repeated work when one multipart extension is applied across 1,500 source files.

Assura cold: 3.70 ms
LS-Lint cold: 10.2 ms
Assura warm: 0.09 ms

High configuration count

Configured scope scale

Assura 1.28x

project/

pkg-0000 ... pkg-0799
file-name.js in every scope
one explicit rule per scope
root directory naming rule

LS-Lint source excerpt; converted Assura policy measured

ignore:
  - .assura
ls:
  .dir: kebab-case
  pkg-0000:
    .js: kebab-case
  # ... 798 equivalent scopes ...
  pkg-0799:
    .js: kebab-case

Checked: 801 files
Ignored: 1 files
Shape: 801 dirs
Policy: 801 rules

Why this case is tracked

Guards config loading and scope lookup when a monorepo declares 800 explicit package policies.

Assura cold: 15.0 ms
LS-Lint cold: 19.1 ms
Assura warm: 1.14 ms

Why latency matters

Parallel waiting adds up. Late refactors cost more.

A check that feels small in one terminal repeats across every agent, worktree, and edit loop. Fast local signals reduce interruption without turning every early warning into a hard gate.

Parallel loops

Keep feedback off the critical path.

When several agents edit at once, repeated startup and full-tree scans compete for CPU, filesystem access, and wall-clock time.

Deterministic first pass

Use rules before another model turn.

Repository policy can answer structural questions locally, reserving agent context and reasoning for work that needs judgment.

Earlier correction

Warn while the patch is still small.

Assura can surface drift during the loop and reserve blocking behavior for rules explicitly configured as commit or CI gates.

This benchmark measures elapsed runtime. CPU utilization, disk I/O, agent memory or token use, and avoided rework are product rationale for keeping checks fast, not measured outcomes in this report.

The complete comparison cohort

Eight shapes. Every result visible.

Smaller startup-sensitive projects and broader realistic trees remain alongside the four focused regression cases.

View all eight project measurements

Project Measured shape Cold comparison Warm Assura session

Small libraryRust package

5 files · 4 dirs6 rules · 2 ignored

Assura 1.75 msLS-Lint 2.30 ms · 1.32x

0.14 mspersistent Assura session

Web appFrontend app

5 files · 4 dirs7 rules · 2 ignored

Assura 2.01 msLS-Lint 2.55 ms · 1.27x

0.13 mspersistent Assura session

Package monorepoTwo packages

7 files · 10 dirs10 rules · 3 ignored

Assura 1.87 msLS-Lint 2.52 ms · 1.35x

0.16 mspersistent Assura session

Strict monorepo policyApps + packages

39 files · 38 dirs38 rules · 10 ignored

Assura 2.73 msLS-Lint 4.05 ms · 1.48x

0.35 mspersistent Assura session

Rule-heavy projectMany file types

192 files · 9 dirs38 rules · 2 ignored

Assura 2.38 msLS-Lint 3.70 ms · 1.55x

0.17 mspersistent Assura session

Generated-heavy projectLarge ignored areas

2 files · 52 dirs2 rules · 769 ignored

Assura 1.50 msLS-Lint 5.65 ms · 3.77x

0.13 mspersistent Assura session

Multipart extension scale1,500 source files

1,501 files · 2 dirs1 rules · 1 ignored

Assura 3.70 msLS-Lint 10.2 ms · 2.76x

0.09 mspersistent Assura session

Configured scope scale800 package scopes

801 files · 801 dirs801 rules · 1 ignored

Assura 15.0 msLS-Lint 19.1 ms · 1.28x

1.14 mspersistent Assura session

Benchmark boundary

The speed claim covers the rules both tools share.

Each cold row runs the same generated project with an LS-Lint policy migrated into Assura. The aggregate uses all eight accepted fixtures shown above.

Included in the cold comparisonNaming · ignores · scopes · extensions

Both release CLIs run process to process, including startup, config loading, traversal, validation, and exit.

Not counted against LS-LintLine limits · content · references · repair guidance

These Assura-only capabilities have no native LS-Lint equivalent and are measured separately.

Separate warm resultPersistent Assura session

Repeated checks avoid paying the full process startup cost on every agent turn.

Inspect every test case Read the full report