Static Analysis Tool-Call Cost: When More Agent Checks Save Money

Why a Cheap Check Has a Cost Curve

Static analysis feels free because a compiler or linter does not charge by token, yet every agent-triggered check consumes wall time, compute, context, and another reasoning loop. The goal is not to maximize diagnostics. It is to run the smallest check that prevents a more expensive failure at the right moment. A useful budget distinguishes local analyzer cost from model repair cost and downstream CI or reviewer cost.

Start with one logical edit unit: implementation, related interface, and nearest test. Record analysis duration, output size, new model input, repair output, and the probability that the check catches a problem. Then record what happens when the check is skipped: build failure, rerun, queue delay, human interruption, or escaped defect. The expected avoided cost determines whether the tool call is economical.

Calculate the Break-Even Probability

Use a simple inequality. Run the check when check cost plus expected repair cost is lower than probability of an uncaught error multiplied by downstream failure cost. Include CI minutes and elapsed queue time, not only API tokens. If an incremental type check costs two cents of compute and agent time but prevents a five-dollar failure more than once in 250 edits, it already breaks even.

Use ranges rather than false precision. Failure cost varies between a fast local rerun and a reviewer discovering the issue hours later. Estimate low, expected, and high cases for each task class. Security-sensitive or deployment code can justify checks with a lower catch probability because the consequence is larger. Generated documentation may use a much lighter policy.

Choose Incremental and Full Gates

Incremental checks give fast feedback while the relevant code remains in context. Run them after a coherent batch of edits, not after every keystroke. Target changed packages, files, or projects when dependency graphs permit. Return concise diagnostics with stable codes and locations. Repeated banners, stack traces, and duplicate errors inflate model context without improving repair.

A full required gate still belongs before completion because incremental selection can miss consumers and configuration. Make the final command deterministic and store its exact result. If a known warning is accepted, document the owner and reason rather than teaching the agent to ignore an entire category. Incremental checks optimize the path; the complete gate defines the acceptance contract.

Route Diagnostics Intelligently

Classify messages before returning them to the model. Syntax, missing import, and type mismatch errors usually support an immediate repair. Environment failures, unavailable services, or missing credentials require a different response. Retrying identical code against a broken tool wastes money. Group root causes so one missing dependency does not generate dozens of independent repair attempts.

Escalate only the failing portion when possible. A budget model may handle formatting and imports while a stronger model examines a subtle generic constraint. Preserve the analyzer evidence through the handoff. Do not ask the premium model to reread the entire repository unless the local diagnosis is insufficient. The handoff should shrink uncertainty, not reset the task.

Track Validation Efficiency

Measure checks per accepted change, diagnostics caught, repair success on first attempt, output tokens per diagnostic, CI failures after local success, and time spent waiting. Segment by language, repository, analyzer, and task. A high check count may be appropriate for Rust refactoring but wasteful for a small Markdown change. One organization-wide threshold will distort both.

Review policies after analyzer upgrades, model changes, or a shift in task mix. Remove checks that duplicate later gates without catching unique failures, and add targeted rules for recurring escapes. Static analysis becomes a cost lever when every call has a defined position and outcome. The best loop produces enough early evidence to avoid rework while keeping the model focused on errors it can actually fix.

Design a Diagnostic Output Budget

Create a decision record for every diagnostic invocation returned to the model. Capture file and configuration hashes, analyzer version, root-cause ordering, bytes returned, repeated messages suppressed, cache decision, repair attempt, and downstream gate outcome. Store the record with the accepted artifact rather than only in a temporary model transcript. This evidence lets engineering reproduce an outcome, finance explain the bill, and reviewers distinguish a real improvement from a lucky run. It also makes exceptions visible instead of allowing them to become undocumented defaults across future sessions.

The main failure to avoid is that unbounded compiler output evicts useful context while silent truncation hides the first actionable error. Define an owner, a measurable threshold, and an expiry date for the decision. review output ceilings and cache invalidation after tool or repository changes. When evidence falls outside the approved range, stop expansion, preserve state, and investigate before buying more attempts. This operating discipline converts a one-time technique into a bounded policy that can remain economical as models, tools, teams, and repositories evolve.