Running Multiple Investment Plans From One Config
Real accumulation strategies are rarely one strategy. You want steady daily buys of liquid cases and one expensive discontinued case per week — two different cadences, two different budgets, two different theses. The naive way to combine them is a mess. The right way is plans: independent budgets that share a bot but never share money.
Why one budget can't serve two theses
Imagine you throw everything into a single $25/day pot: five cheap liquid cases plus one older case that trades around a hundred dollars. An equal-split allocator does what you told it to: divides the budget six ways. Now the expensive case receives about $4 a day and takes most of a month to accumulate one fill — while its allocation sits idle, hoarded, distorting every daily report. Meanwhile, if the allocator isn't disciplined about per-item shares, the expensive case does the opposite: one fill devours several days of budget and your liquid-case DCA goes dark until the pot recovers.
Neither behavior is a bug. They're both the inevitable result of forcing one budget to express two different intentions:
- "Spend about this much per day, spread across these items" — a rate. Right for cheap, liquid cases where smoothness of entry is the whole point.
- "Acquire about this many per week, whatever the price does" — a quantity. Right for expensive items where one unit is the sensible position size, and a daily drip is just bookkeeping theater.
Rates and quantities don't average. They need to live in separate containers.
The plan model
The clean design — the one cs2stack uses — treats the config file as a sequence of plans. A budget line opens a plan; the item lines under it belong to that plan; the next budget line opens the next plan. Each plan gets its own daily allowance, its own allocation across its own items, its own accounting in the ledger. Quantity-based standing orders ("buy 1 per week") live outside the DCA splits entirely — they don't take a share of anyone's daily budget, they just count their own fills in the log and act when a period comes up short.
Concretely, the founder's live setup — the one publicly documented in the $20/day experiment — is two plans in one file:
| Plan | Type | Contents | Behavior |
|---|---|---|---|
| Daily DCA | $20/day budget | ~5 liquid cases | Equal split, unspent carries, max-price lines per item |
| Weekly anchor | Standing order | 1× CS:GO Weapon Case | Buys one per week (~$110–120 per the ledger), independent of the daily pot |
The two plans never touch. A spike in the weekly case's price can't crowd out Tuesday's liquid-case buys; a bad week for cheap cases can't starve the weekly order. Every ledger line is tagged with its plan, so "how is the anchor position doing?" and "what's my liquid-case cost basis?" stay separately answerable — which matters enormously once you're computing cost basis or reviewing performance honestly.
Zero interference is the actual feature
The phrase to hold onto is independent failure domains. Plans isolate more than budgets:
- Price shocks. When one plan's items reprice violently — say an update hits older cases hard — only that plan's behavior changes. The other keeps its cadence, which is exactly the discipline buying through a correction requires.
- Config edits. Adding a case to plan A doesn't dilute plan B's per-item shares. In a single-pot design, every list edit silently re-slices everyone's allocation — a subtle way to churn your own strategy without noticing.
- Review decisions. Plans map to theses, so you can kill one thesis cleanly. Decide the weekly anchor was a mistake? Delete three lines. Your daily DCA never knows it happened. Compare that to untangling one shared pot's history to figure out which case to stop buying.
There's a psychological version of the same benefit. A single number — "$25/day on skins" — invites constant renegotiation with yourself. Two labeled intentions — "$20/day on liquid cases, one weekly anchor" — are commitments specific enough to keep, and specific enough to evaluate on their own terms months later. That's the same reasoning behind tiered structures like a case ladder, where each price tier plays a distinct role.
Guardrails still apply across plans
Independence has one deliberate exception: global safety limits. Per-plan budgets bound each strategy, but the bot should also enforce an overall ceiling — cs2stack hard-caps total daily spending at $500 regardless of how many plans a config declares, on the theory that no configuration mistake should be able to scale into a disaster. Plans multiply intentions; they must not multiply worst cases. The layering — per-item max-price lines, per-plan budgets, one global hard cap — is standard defense in depth.
When to add a second plan (and when not to)
Good reasons: your list has developed a price outlier (anything where one unit exceeds several days of budget belongs in a standing order, not a split); you're running genuinely different time horizons; or you want a small experimental sleeve — new case types, an actives-vs-classics tilt — whose results you can read separately before scaling it.
Bad reason: plan sprawl as a substitute for conviction. Six micro-plans of $3 each isn't diversification, it's indecision with extra bookkeeping — and on small budgets it splinters your buys below the point where fills even land daily. Most people are best served by exactly the founder's shape: one boring daily plan doing the heavy lifting, at most one standing order for an anchor item, everything visible in one daily report. Start there; earn the third plan.
The quiet win of multi-plan budgets is that your config file starts to read like your actual strategy, one intention per block — and the bot executes each intention exactly as written, without letting them fight. The strategy stays yours. The separation is what the software is for.