Set three numbers before an AI-assisted code review begins: a monthly program ceiling, a maximum cost per assessment, and a reservation for verification and reporting. Then decide what scope is useful inside those limits. Count model input and output, retries, retrieval and compute, human review time, and any follow-up validation. A budget that pays for discovery but cannot check the resulting claims buys an alert queue rather than a security decision. If the allowance is small, explicitly review selected attack surfaces and report the rest as unreviewed.
The answer changes with repository size, model and region, number of independent passes, and the amount of human review required. Provider prices and quotas change, so use current official pricing for your chosen route instead of copying a dollar figure from a planning article. For example, Amazon Bedrock pricing varies by model, provider, modality and service tier. Cost planning is also a source-handling decision: a logging or routing choice can change where sensitive prompts go.
Decide what a unit of work means
“One scan” is too vague to price. Define an assessment as a pinned repository revision, selected components, method, model route, deadline and result. A narrow review of an authorization flow and a full monorepo review are different units even if both end in a report. Record the eligible file and line counts, excluded areas, whether the run is first-time or incremental, and which human checks it includes. That denominator lets you compare cost with useful reviewed scope rather than with a vendor's advertised number of “scans.”
Split cost into four buckets:
| Bucket | Include | Common omission |
|---|---|---|
| Source preparation | Authorized acquisition, parsing/indexing, temporary compute and storage | Treating model tokens as the whole bill |
| Discovery | Context retrieval, input/output tokens, tool calls and bounded follow-up searches | Counting only the first prompt |
| Verification and report | Independent check, counterevidence search, writing and quality review | Spending the entire cap on candidates |
| People and follow-up | Analyst triage, developer clarification, authorized validation and reassessment | Calling an inexpensive model run an inexpensive security program |
For token-priced calls, estimate a worst-case reservation before dispatch: (maximum input tokens × input rate) + (maximum output tokens × output rate), using the provider's billing units. Add paid tools or model features, the compute ceiling and retry policy. For parallel calls, reserve the sum of their maximum authorized costs through an atomic admission operation. Two workers must not both read the same remaining balance and each spend it. Apply the same rule to the shared monthly allowance, including concurrent assessments. If an attempt's billing state is unknown, do not immediately recycle its reservation and launch the same work again. Set a maximum number of child calls and a wall-clock deadline so one complex path cannot quietly consume a month's allowance.
A filled planning example
Illustrative budget, not a provider quote or observed result: Riverbank Software plans 40 targeted assessments each month across 20 repositories. The security leader can fund at most $750 in variable platform spend for this pilot, with analyst time budgeted separately. A pilot estimate puts the model ceiling at $12 per assessment and bounded non-model compute at $3 per assessment. The 40 planned runs can spend at most 40 × ($12 + $3) = $600. The remaining $150 can fund up to ten separately approved continuation runs at the same $15 cap if a run stops with a material question unresolved; it does not raise any individual run's cap.
Within each $12 model ceiling, Riverbank allocates $4 to discovery, $5 to independent verification and counterevidence, and $3 to final explanation or an unresolved-status report. These are invented allocation limits, not expected prices. If discovery spends $4 without a useful candidate, the run can still produce a truthful coverage note. If a candidate appears at the last moment, the verification reserve remains available. If verification finds a missing service outside scope, the run stops at “inconclusive” and asks for a linked continuation rather than silently charging more.
Riverbank's decision sheet is compact enough to use at admission:
| Decision | Riverbank pilot rule | Evidence to keep |
|---|---|---|
| Scope | Two named high-risk flows per repository at a pinned revision | Components, exclusions and revision |
| Per-run cap | $15 variable spend including model and compute | Reservations, actual spend and unsettled attempts |
| Quality reserve | $5 of model ceiling for verification, $3 for explanation | Candidate disposition and reviewer record |
| Stop | No new paid work at cap or deadline | Partial report and remaining work |
| Continuation | Security lead approves a new bounded run from the $150 reserve, with its own $15 cap | New scope, ceiling and relationship to old run |
The numbers make the tradeoff visible. Forty targeted assessments do not equal complete review of 20 repositories. The team must say what was examined and avoid describing untouched components as clean. No finding count or detection rate is promised by the budget.
Enforce the ceiling at admission, not only on an invoice
Cloud billing alerts are useful oversight but may arrive after spending occurs. AWS Budgets documentation says usage can exceed a threshold before notification because billing and alerts are delayed. An assessment needs its own admission rule: before each paid attempt, confirm that the remaining reserved amount covers the largest permitted input and output, plus the call's other bounded charges. A job that cannot afford its verification stage should stop opening new investigations. Track application and SDK retries under that admission rule so a timeout cannot trigger an unreserved additional attempt. A local idempotency record can prevent duplicate job admission; provider-side retry and charging behavior still need separate checks.
After each attempt, record actual provider, model, route, region, input/output usage, call purpose, retry state and amount settled. Compare that ledger with the provider bill. Bedrock runtime metrics expose invocation and token measures; use them to reconcile, not as a substitute for per-assessment authorization. Be careful with observability: Bedrock model invocation logging can capture request and response content when enabled. A source-sensitive program should approve log fields, destination and retention before enabling it. A cheap analysis that copies private source into broad logs is not a good bargain.
Walk a timeout through the reservation ledger
Within Riverbank's $12 model cap, discovery has settled at $3.20. Verification attempt V1 reserves $2.00 but times out with billing unknown. The $3.00 report reserve remains protected. The illustrative admission arithmetic is:
model cap $12.00
settled discovery $3.20
unsettled V1 reservation $2.00
protected explanation reserve $3.00
uncommitted amount $3.80
A retry needing a $2.00 reservation can fit the total ceiling, but the controller must also respect the $5 verification allocation: V1 plus the retry reserves $4.00. If the retry's maximum were $4.00, it would fail both the remaining total and verification-stage limits. A timeout does not create free budget.
If V1 later settles at $1.40, release only the unused $0.60. If it settles at zero with reliable provider evidence, release the full $2.00. If its state remains unknown, keep the reservation until the reconciliation policy resolves it. A local idempotency record prevents accidental duplicate admission; it does not guarantee that a provider will deduplicate a paid invocation. Check the actual API's semantics before retrying.
At the deadline, an unresolved candidate can receive a concise deterministic partial-status record even if no further model call is admitted. The job should never need to exceed its cap merely to explain that it stopped. An approved continuation is a new bounded unit drawing from the separate monthly reserve, not an invisible extension of V1.
Add the human bill before calling the pilot inexpensive
Suppose the 40 planned assessments require an illustrative 30 minutes of analyst work each. That is 20 hours. At an assumed internal planning rate of $100 per hour, analyst time is $2,000. Combined with the $600 variable platform ceiling, the planned-work estimate is $2,600, before any separately budgeted developer repair or runtime validation. The $150 platform continuation reserve remains separate and unused in this calculation.
These are invented planning inputs, not market wages, provider prices or a measured ROI. Their purpose is to expose the cost that a $12 model figure hides. If the same pilot instead produces many unresolved cross-service claims, the human effort may rise even when token spend stays within cap.
Compare two possible improvements. Better retrieval that prevents repeated source searches could reduce model cost. Better evidence packets that cut avoidable developer clarification could reduce the much larger human burden. Measure both against the actual baseline; fewer alerts alone can also mean missed scope.
The end-of-pilot record should include every assessment actually admitted against the plan of 40, including partial and no-finding runs. If fewer were admitted, explain the shortfall instead of treating the plan as completed work. Preserve reviewed scope, candidate outcomes, analyst time and follow-up. A severe supported issue deserves individual attention; an average cost per finding should not flatten the business decision. AWS Budgets remains financial oversight, while the application admission ledger enforces these per-work limits.
Decide which unfinished work deserves a continuation
Riverbank's continuation reserve should fund a specific remaining decision. A request that says “the scan needs more time” does not establish that another bounded run will help. Ask what artifact or review step was missing, whether it is now available, and what conclusion the continuation could change. If the policy service is still unavailable, repeating the same source-only search is unlikely to settle that boundary.
A useful synthetic continuation request identifies the original run, the unreviewed refund-policy function, the newly supplied service revision, and the remaining verification question. It carries its own $15 platform ceiling and named analyst allocation. The original run remains partial. Its settled spend and evidence stay intact, while the new run adds a separately attributable result.
Prioritize these requests by the decision they unblock. A narrow question affecting an imminent high-impact release may deserve the next slot. An open-ended search for additional low-impact candidates may wait for the regular cycle. This is a program choice for the security lead; the model should not decide that its own unfinished reasoning deserves more money.
At month end, compare continuation requests with actual results. Were they caused by inadequate initial scope, unavailable source, confusing policy, or an unexpectedly complex path? A pattern of missing deployment records suggests improving those records. A pattern of overloaded assessments suggests selecting smaller initial questions. Neither problem is necessarily solved by raising the per-run cap.
Also separate unused capacity from completed assurance. If the pilot spends less because only twenty of forty assessments were admitted, the underspend is not an efficiency gain. If all forty finish their stated questions using less than their ceilings, the result is more promising, but the assessment quality and human effort still determine whether the program delivered value.
For the next review cycle, fill the five-row Riverbank sheet with your actual unit of work and current price route, then run a small bounded pilot. Use the AI scanner false-positive evaluation to judge alert quality, and the scan-limits template to tell engineers what the purchased assessment covered.