Slay the Spire: the update that split the mods

Most version breaks in this series come from outside the game's own intentions — a DLC, an engine-runtime CVE, a studio handover. Slay the Spire's is different and, in a way, more poignant: the developers themselves shipped a free v2.0 update (and a follow-up 2.2) that modernized the game years into its life — and in doing so changed the internals that the modding libraries hook into, breaking a large part of the classic mod catalog at once. Community compatibility patches appeared, but they only fix the basic cases; the deep mods, especially the custom characters — entirely new playable classes with their own cards and mechanics, the crown jewels of STS modding — largely stayed behind on the version they were built for. Add the arrival of Slay the Spire 2 (a separate game, now in early access) reframing the original as "the classic one," and the reason to pin a build is concrete: not to relive 2019, but to keep a character collection that still works.

01Pre-2.0 or 2.0

The decision is a single fork. Stay on 2.0 (current) if you play vanilla or only the mods that have updated across the break — it's the supported, maintained game. Pin pre-2.0 if your modlist is anchored to a custom character or a deep mod that never crossed, which describes a real slice of the community. There's no shame in either; the mod scene simply has two homes now, and the compatibility patches that bridge them are explicit about fixing "relatively basic issues" only. Decide by checking your essential mods' pages for a stated game version — if they say pre-2.0 (or list a ModTheSpire/BaseMod pairing from that era), that's your build.

02Getting a pre-2.0 build

Slay the Spire is app 646570. Some past versions sit in Steam's Betas dropdown (Properties → Betas) — check there first, it's the no-tooling path. For a specific pre-2.0 build the dropdown doesn't carry, it's the date-matching route: find the pre-2.0 era on the game's update history, then take the matching manifest for the content depot from SteamDB's app 646570 depot page and pull it:

I'm not hardcoding a manifest ID here on purpose: pre-2.0 covers a span of builds, and the right one depends on exactly which mod era you're matching — read it off SteamDB for your target date rather than trusting a number copied from a forum that may point at a different build than you need. The game is tiny (about a gigabyte), so keeping a pinned pre-2.0 copy beside your current install costs nothing. Then pin it: Properties → Updates → "Only update this game when I launch it", so Steam can't quietly move you onto 2.0 and undo the whole exercise — and for a side-by-side copy in its own folder, that worry disappears entirely.

03ModTheSpire + BaseMod — the two-layer loader

STS modding stands on two required layers, and both are version-locked: ModTheSpire (the mod loader that adds the "Play with Mods" launch path and its mod-select popup) and BaseMod (the modding API and dev console that the actual mods call into). A pinned pre-2.0 game needs the era-correct ModTheSpire and BaseMod, not today's — their GitHub releases are versioned, and pairing a current loader with an old game (or vice versa) is the usual crash. The mistake I made first was grabbing the latest loader out of habit and wondering why nothing launched; match the loader to the build's era and it just works. The sequence on a pinned build:

1. Install the era-matched ModTheSpire and BaseMod into the pinned game folder (the community installers and the mods' own pages state the pairing).
2. Add your custom characters and content mods alongside.
3. Launch via Steam's "Play with Mods" option (or the loader's executable directly for a side-by-side copy), then tick BaseMod and your mods in the ModTheSpire window.

The rule is the series' refrain in deckbuilder form: game version, matched ModTheSpire + BaseMod, then the mods built for that pairing — one era, all the way down. It's the "stack below the stack" idea again; here the stack is two libraries and the payoff is a playable class. Another beloved indie with the same shape is Hollow Knight, whose Modding API ships a separate build per game patch — pin the game and you pin the API to match.

04Saves, unlocks and the daily

Roguelikes travel light: a Slay the Spire save is one in-progress run plus your unlock and score data, all under the game's user-data folder — far less fragile than the hundred-hour worlds elsewhere in this series. Two small cautions still apply. Back up that user-data folder before hopping versions, since a 2.0-touched profile may carry data a pre-2.0 build reads oddly; and keep modded, pinned play to its own profile or a side-by-side copy if you also chase the Daily Climb or leaderboard scores — competitive integrity there assumes the current, unmodded game, so don't mix a modded old build into runs you mean to count. Vanilla pre-2.0 for the feel, modded pre-2.0 for the characters, current 2.0 for the daily: three lanes, kept separate, is the tidy setup.

05Status in 2026

Slay the Spire is a gentle case on the status spectrum. The catalog is small and the relevant break is recent, so pre-2.0 manifests sit on the friendly side of the weather; some versions are on an official Betas shelf; and the mod community, though split by 2.0, actively maintains both homes with compatibility patches and version-tagged releases. The honest notes are the standing ones — the Betas shelf is the developer's to curate, manifests answer at Valve's pleasure, and the deep classic mods will likely never cross to 2.0. Which makes the move clear for anyone whose climb depends on a mod-built character: pin the pre-2.0 build, pair it with its era's ModTheSpire and BaseMod, and archive the folder. A modernization update is a kindness to the game and a deadline for its mods; mind both.