Budget Caps: The One Setting That Makes Bots Safe
The scariest sentence in automated trading is "the bot has access to my wallet." The sentence that should replace it: "the bot has access to at most $20 of my wallet, per day, per hard-coded ceiling, no matter what any bug, config typo, or price spike says." That transformation is done entirely by caps — layered ones. Here's each layer, and the specific failure it exists to stop.
Why caps are the whole safety story
Every other safety feature in a buying bot — validation, previews, alerts — reduces the probability of a bad outcome. Caps are different in kind: they bound the size of any outcome, including the ones nobody predicted. Software fails in creative ways; a marketplace API returns nonsense, a currency conversion misfires, a loop runs twice. You cannot enumerate every bug in advance, but you can make every bug's worst case equal to one day's budget. That's why caps, not cleverness, are the foundation — the same philosophy behind kill switches and hard caps and the prohibitions in what a bot should never be allowed to do.
cs2stack layers three of them. Each layer catches a different failure, and each has a story.
Layer 1: the per-item max price
Every line in the config carries its own ceiling — "Fracture Case (max $0.60)" — and any morning the cheapest listing across venues exceeds it, that item is skipped and reported, not bought. This is the cap that protects you from the market: overnight spikes, thin order books where the best ask is silly, and hype days when a case reprices 40% before breakfast. A human buyer grumbles and often pays; the cap simply says no, in the voice you configured while calm. It also protects you from stale strategy — if a case runs far past what you once considered fair value, the skips pile up in your reports and force the healthy question of whether to raise the line or stop accumulating, which is its own decision covered in when to stop buying a case. Full treatment in max-price lines.
Layer 2: the per-day budget
The line everyone understands — "Budget: $20/day" — but the failure it prevents is subtler than overspending. A daily budget bounds allocation logic, the code that decides how the $20 splits across your items (cs2stack splits it equally across items — boring, fair, predictable). Allocation is exactly the kind of code where innocent-looking logic produces uninnocent purchases, and there's a live example from cs2stack's own development: when a new line was added to a config, a naive version of the allocator computed how many units the plan "should" have owned since its start date and tried to catch up — by buying 19 Gamma cases at once. The daily budget contained the blast radius while the logic got fixed properly, with fresh-start clocks so new items begin accumulating from zero — the design lesson written up in why new items start at zero.
That's the pattern worth internalizing: the bug was found, fixed, and would never recur — but the cap is what made the bug an anecdote instead of an incident. Every allocator has a worst day; the budget line decides what that day can cost.
Layer 3: the hard ceiling
Above whatever you configure sits a limit you can't configure: cs2stack will not spend more than $500 in a day, full stop, regardless of what any config file says. This layer exists for the failure modes the first two can't see — a corrupted config, a fat-fingered budget line ("$200/day" typed as "$2000/day"), or a compromise of the config itself. A cap you set in the same file an attacker or typo can edit is not a final defense; the hard ceiling lives in the system, not the settings. It's the difference between a speed limit sign and a governor on the engine.
Note what the hard cap is not: a target, or a suggestion that $500/day is sensible. Almost everyone runs far below it — the founder's public account runs at $20/day — and the ceiling's job is purely to make "catastrophic day" mean "annoying day" even if every other layer fails simultaneously.
How the layers behave together
| Layer | Protects against | Worst case if it's the only survivor |
|---|---|---|
| Per-item max price | Spikes, thin books, stale theses | You buy fairly-priced items you chose |
| Per-day budget | Allocation bugs, config drift | One day's budget, spent imperfectly |
| $500/day hard cap | Config typos, tampering, everything else | A bounded, survivable bad day |
Defense in depth is the point: each layer assumes the others might fail. And around the caps sit the softer controls that make failures visible early — DRY_RUN previews before any real money moves, name validation before any run, an append-only ledger so every cent is accounted for, and balance alerts so the system's view of your wallet never drifts far from reality.
Setting your own numbers
Three rules of thumb. First, the daily budget comes from your life, not from the market: it's the number you'd happily spend on any other hobby — the entertainment-money rule — and it should survive a 50% market drawdown without becoming a regret. Second, max prices come from recent trading ranges, not hopes — set them slightly above typical asks so normal days fill and abnormal days skip; if you set a ceiling below the trading range, you've just written an elaborate way to never buy the item. Third, revisit caps on a schedule — monthly, alongside your ledger review — and never mid-spike. A cap edited during a hype hour isn't a cap; it's FOMO with version control.
The deeper point is psychological as much as technical. Caps convert an open-ended relationship with a market into a bounded one. You know, to the dollar, the maximum any day can cost you — through bugs, spikes, typos, or your own worst impulses. That's what "boring in the good way" means, and in a market that has crashed on a patch note before, boring is the asset. It's also what makes handing execution to software — the premise of the whole one-config-file setup — a reasonable act instead of a leap of faith.