Dry Runs: Rehearsing With Real Prices and Fake Money
Pilots don't learn a new approach with passengers on board; they fly it in the simulator first. A bot that spends your money deserves the same courtesy. A dry run is the simulator: the full buying logic, live market prices, real venue comparison — and a wallet made of cardboard.
What a dry run actually is
A dry run (or preview run) executes every step of an automated purchase except the last one. The bot reads your config, validates your item list, fetches live listings from each marketplace, converts currencies, applies your max-price caps and budget caps, allocates the day's spend, picks the cheapest venue per item — and then, instead of calling the purchase API, it writes down what it would have bought and for exactly how much.
The crucial property: everything upstream of the final call is real. Real prices, real availability, real FX rates, real allocation math. A dry run that uses mocked or stale data tests nothing — it's a screenshot of your hopes. The value comes precisely from running your untested config against today's actual market and seeing the honest result, with zero dollars at risk.
Why "default off" is the wrong default
Most tools treat simulation as an opt-in flag you might remember to pass. For software that spends money unattended, that's backwards. The safer semantic — the one cs2stack uses — is DRY_RUN by default: the bot previews unless you explicitly arm it to spend. New setup? Previews until told otherwise. Fresh config edit? The cautious path is the lazy path.
This inversion matters because of how config mistakes actually happen: not in careful initial setups, but in Tuesday-night edits. You add a line, fix a typo, bump a budget — and a mistyped item name or a misplaced decimal goes live at 6 a.m. while you sleep. Default-off simulation means the failure mode of forgetfulness is "nothing was spent," not "the wrong thing was bought." It's the same philosophy as the rest of safety engineering for buying bots: design so the cheap mistake is the one that happens.
What a preview catches
Real examples of the class of bug a dry run surfaces before money moves:
- Items that don't exist. A cs2stack user once configured a "Gamma 3 Case" — a plausible name for an item Valve never made. Name validation against live markets flagged it in preview instead of silently buying nothing (or worse, something fuzzy-matched). The full story is in verify before you buy.
- Allocation surprises. An early allocator bug tried to retroactively "catch up" a newly added line — 19 cases in one morning to backfill days the line hadn't existed. The preview made the intent visible before it became a purchase; the fix (new items start their clock at zero) is covered in no retroactive catch-up.
- Cap interactions. Your per-item ceiling is below every current listing, so the item would be skipped daily. Better to learn that from a preview than from a week of confusing buy reports.
- Budget math. Three plans sharing one wallet can sum to more than you intended. The dry run prints the total; you check it against the number in your head.
Preview on every change: config as code
The pattern gets genuinely powerful when previews are triggered automatically by change. cs2stack keeps config in a git repository, so editing your plan means pushing a commit — and every push triggers a dry run whose output you review like a diff. Propose, preview, then promote. Software engineers will recognize this as CI for money: the same discipline that keeps bad code out of production, applied to keeping bad purchases out of your ledger.
Treated this way, a dry run is an acceptance test. The question isn't "does the code run?" but "does this config express what I actually meant?" Only a human can answer that, and the preview is the evidence they answer it with. It's the operational half of the principle that automation doesn't pick winners — the machine executes; you decide, and the dry run is where the decision gets checked.
Reading a preview like you mean it
A dry run only protects you if you actually read it, and reading it well takes about ninety seconds. Check three things: the item lines (right names, right quantities, prices near what you expect — the format mirrors a real buy report, so the habit transfers); the total (within your daily cap, and sane against the $500 hard cap that should make any runaway config arithmetically impossible); and the skips (anything the bot declined, and whether the stated reason matches your intent). If all three pass for a couple of simulated days, arm it.
One honest limitation: a dry run validates logic, not strategy. It proves the bot will buy what you specified at prices you allowed — it says nothing about whether those cases are worth stacking. That judgment lives in choosing what to buy, and no simulator can make it for you. Rehearse the mechanics with fake money; own the thesis with real conviction. If you're just getting started with automated buys, run the simulator for a few days first — cardboard wallets are free.