July 2026
RedMirror now caches its analysis by content. Re-scan a codebase after a change and you only pay for the parts that actually changed. Everything else is served from cache, instantly, for no tokens. In our tests, re-scanning a real subsystem after some edits dropped the review-pass tokens by about 90% and the total scan cost by about 40%, with byte-identical findings. This post is about the mechanism, and why it's harder for an AI scanner to do soundly than it looks.
A rule-based linter is cheap per file, so re-running it is cheap. An LLM-based review is the opposite: the model pass is the expensive part, and most AI review tools re-run it over your whole repository on every scan. Fix one file in a 50,000-line codebase and you pay to re-analyze 50,000 lines. In CI, where you scan on every push, that bill compounds quickly, and it never goes down, no matter how small the change.
Deterministic static analyzers solved this years ago with incremental analysis: hash a file, skip it if it hasn't changed. The reason AI scanners mostly don't is that two things get in the way.
The unit is fuzzy. What do you even cache: the file, or the whole repo? A change in one place shifts line numbers everywhere below it, and a scan doesn't obviously decompose into stable pieces you can address independently.
The output feels risky to reuse. Model output is non-deterministic, so caching an answer raises the fear that it will be stale, or wrong the next time the code is looked at.
The naive fixes are unsound and quietly dangerous for a security tool:
For a scanner, "probably still valid" is not good enough. A cache that can ever return an analysis of code that no longer exists is a cache that can hide a real bug.
RedMirror breaks its review into small, function-aligned units, and keys each one by a hash of the exact input the model sees: the code in that unit, plus the model and the prompt version behind it. The key is a fingerprint of the analysis.
A re-scan recomputes those keys. A unit whose bytes are unchanged produces the same key, so RedMirror replays its prior result and skips the model call entirely. A unit that changed produces a different key and gets a fresh, full analysis.
The property that makes this safe for a security tool: a cache hit can only happen when the code is byte-identical. Freshness is guaranteed by the key, not by a timestamp and not by an expiry. Changed code cannot produce a matching key, so it can never be served a stale result. That's the difference between "probably still valid" and "provably the same input."
It also dissolves the non-determinism worry. We aren't gambling that a model will repeat itself; we're storing one valid analysis of an exact sequence of bytes and declining to pay to ask the identical question twice. Identical input deserves the identical answer.
The savings scale with how little changed. Here's a real re-scan of a subsystem where nothing had changed since the previous run:
# first scan: a cold cache, full price this scan cost $1.83 # re-scan of the same code review cache: 66/66 tile(s) reused (no tokens) this scan cost $1.09 (same 20 findings)
Change a couple of files and only those units miss; everything else stays free. Caching is per-file independent: editing one file never invalidates another. Change everything, and you pay full price, exactly as you would have anyway. You are never charged twice to analyze the same code, and never charged less to analyze code that changed.
The cache never stores your source. It holds only the result of an analysis, addressed by a hash, in a content-addressed store at the edge, with a short expiry. We still keep no copy of your repository. That policy hasn't moved. And because retrieving an entry requires computing its key from the identical code, an entry can only ever be returned to someone who already holds that exact source.
Run redmirror scan ./repo, change a file, run it again, and watch the cost drop to the diff. Check the price first with redmirror estimate, free and local.