A sandbox refresh budget follows from three numbers: promotion steps per change, changes per month, and how many steps a sandbox absorbs before it drifts. In the illustrative example below, 40 AI-drafted changes a month produce 166 promotion steps and about 2.5 refreshes. At 80 changes the same method gives about 5, which a 29-day minimum between full copy refreshes cannot serve.
All figures here are round numbers chosen for illustration. Replace them with your own before anyone signs a budget.
What counts as a promotion step?
A promotion step is one deployment or validation run of a single change into one distinct environment. Drafting is not a step. The pull request opening is not a step. The run that proves the change in a given environment is.
That definition matters because AI raises the number of drafts, not the number of environments. Each draft still has to cross every stage the pipeline defines, and each crossing consumes sandbox state.
How many promotion steps does one AI-drafted change take?
In a linear PR-gated flow with a dev, an integration and a UAT stage, one change takes four steps when nothing fails.
| Step | Environment | Touches a sandbox |
|---|---|---|
| 1. Validation run on the pull request | Dev or validation sandbox | Yes |
| 2. Deploy after review | Integration sandbox | Yes |
| 3. Deploy for acceptance | UAT sandbox | Yes |
| 4. Deploy after human approval | Production | No |
Three of the four steps land in a sandbox. Production is the fourth and last, and it waits for a person. Only the sandbox steps feed the refresh count, since production is never refreshed.
Worked example: from steps to a sandbox refresh budget
Inputs, stated as assumptions: 40 AI-drafted changes a month; 15% fail validation once and rerun, which is 6 reruns; each sandbox is refreshed after absorbing 50 steps, a drift threshold the team picks, not a Salesforce figure.
Operation, stage by stage:
- Dev or validation sandbox: 40 first runs plus 6 reruns is 46 steps, or 0.92 refreshes.
- Integration sandbox: 40 steps, or 0.80 refreshes.
- UAT sandbox: 40 steps, or 0.80 refreshes.
- Production: 40 steps, no refresh.
Result: 166 promotion steps in total, 126 of them in sandboxes, and 2.52 refreshes a month. The sandbox refresh budget for this team is roughly 2.5 refreshes monthly across three sandboxes. Spread evenly, that is no sandbox refreshed more than once a month.
How does AI change volume move the sandbox refresh budget?
Doubling volume to 80 changes, with the same 15% rerun rate, gives 12 reruns. The stages then see 92, 80 and 80 steps, which is 1.84 + 1.60 + 1.60 = 5.04 refreshes a month.
The UAT sandbox now needs a refresh about every 19 days (30 divided by 1.6). If that sandbox is a full copy, the documented 29-day minimum between refreshes blocks the schedule. The conclusion shifts from "buy more refreshes" to "raise the drift threshold, split UAT, or batch changes". The rerun rate is the quiet lever: at 30% instead of 15%, the 40-change month adds 6 more steps to the dev stage and 0.12 refreshes.
Two things would change this conclusion. A post-copy automation that restores config cheaply raises the drift threshold. A pipeline with more stages multiplies every row of the table above.
Which stages need which sandbox type?
The step count says how often, not how big. Validation runs need metadata parity, so a lighter sandbox often serves the dev stage. UAT is where data volume matters, so it is the stage most likely to need a partial or full copy. What each type costs sits in your org contract, not in any public figure, so read that line before pricing the refreshes.
Does the tool change the arithmetic?
The step count is the same whatever tool runs the flow. What differs is the second variable in the total cost: seats, environments or neither.
FlowSprite AI fits the table above directly. An AI client such as Claude or Cursor drafts the change over MCP, FlowSprite lands it as a pull request in the customer's own private repository, tests it in a sandbox first, and waits for a human to approve before deploying. Pricing is flat and public: professional at EUR 99 a month for 10 users and 6 Salesforce connections with unlimited changes under fair use, enterprise at EUR 199 a month for 25 users and 20 connections. Because changes are not metered, doubling from 40 to 80 moves the refresh line in the budget and leaves the licence line alone.
Hutte publishes seat pricing from EUR 75 per user per month (core) to EUR 150 (growth), read on 2026-09-29 at hutte.io. As arithmetic, not a quote, 10 users on the core plan is EUR 750 a month. Salto's pricing page, read the same day, does not state a figure, and the competitor notes describe its environment-size pricing as opaque. A budget cannot be summed from a price that is not published.
Gearset's homepage cites a 99% deployment success rate. The page does not give the sample or window in the captured text, so it cannot replace the rerun rate you measure yourself.
What habit keeps the forecast honest?
Log every validation rerun as its own step, from the first month. The 15% rerun rate above is an assumption, and it is the figure most likely to be wrong in either direction. After one quarter of logged steps, replace each assumption with a measured one and rerun the three lines of arithmetic. A budget built on counted steps can be corrected. One built on a guess about "AI volume" can only be defended.