"Flywheel only supports Sodium 0.6.0-beta.2" when you have neither mod installed

The error

You are on Minecraft 1.20.1 with Forge. You install Rubidium and Oculus for performance and shaders. The game refuses to start, and the loader reports something close to this:

Mod ID: 'sodium', Requested by: 'flywheel', Expected range: '[0.6.0-beta.2,)', Actual version: '0.5.3'

Two mod names, neither of which you downloaded. Players report it in exactly those words: one asks why Flywheel wants Sodium when they definitely do not have Flywheel installed, another says the game demands Sodium beta 2 while they have neither Flywheel nor Create.

Nothing here is a bug. Two ordinary packaging mechanisms are stacked, and each one hides one of the two names.

Mechanism one: a mod can register under another mod's id

Rubidium is a Forge port of Sodium. Plenty of Forge mods want to detect Sodium and adjust their rendering, and they check for it by mod id. So Rubidium claims that id on purpose. Open rubidium-mc1.20.1-0.7.1a.jar and read META-INF/mods.toml, and after the entry for Rubidium itself there is a second one:

[[mods]]
modId = "sodium"
version = "0.5.3"
displayName = "Sodium"

That is the 0.5.3 in your error, sitting in a file you can open yourself. Real Sodium was never involved. Sodium is a Fabric mod, and there is no Forge build of it for 1.20.1. The loader simply believes a mod called sodium at version 0.5.3 is installed, because Rubidium told it so.

This is a common pattern in the Forge port ecosystem, not a Rubidium quirk. Oculus does the same thing with the iris id, for the same reason.

Mechanism two: a mod can ship inside another mod

Flywheel is not something most people install. It is bundled inside Create. Forge supports nested jars, and Create carries its libraries in its own download. In Create 6.0.8 for 1.20.1, the bundled copy sits at:

create-1.20.1-6.0.8.jar
    !/META-INF/jarjar/flywheel-forge-1.20.1-1.0.5.jar

The loader unpacks it and loads it as a normal mod, so it can request dependencies and appear in errors, while never showing up as a file you chose to download. If you have Create, or any pack containing Create, you have Flywheel.

Why an optional dependency still stops the game

Read Flywheel's own mods.toml from that nested jar and the last block is this:

[[dependencies.flywheel]]
modId = "sodium"
mandatory = false
versionRange = "[0.6.0-beta.2,)"
side = "CLIENT"

This is the part that surprises people. In Forge, mandatory = false means the mod does not need to be present. It does not mean the version is unchecked. If nothing claims the sodium id, the check is skipped and everything starts. If something does claim it, the range is enforced.

So Flywheel is not asking for Sodium. It is saying that if Sodium is present, it must be 0.6.0-beta.2 or newer, because that is where the rendering hooks it uses live. Rubidium answers that question with 0.5.3, and the loader stops. Installing Rubidium converted a check that would have been skipped into one that fails.

The version it wants does not exist. When this was reported on Sodium's tracker, Sodium's developer jellysquid3 closed it as an external issue with the plain answer: other mods are specifying dependencies on non-existent versions of Sodium, Sodium cannot fix that, and there is no Sodium 0.6.0 or newer for 1.20.1.

The fix

Delete Rubidium. Install Embeddium.

Both Flywheel maintainers gave that answer in one line each. Jozufozu, on a report titled with the user's own confusion about not having Flywheel and being on Forge, replied "switch rubidium for embeddium". IThundxr said "use embeddium instead of rubidium" on a second report, then repeated it when the thread filled up with people hitting the same wall.

Embeddium is a fork of Rubidium, so you lose nothing. It works because of what it does not declare. Embeddium 0.3.31 registers embeddium, plus a stub rubidium entry so mods that look for Rubidium still find it. It never claims sodium. With nothing holding that id, Flywheel's version range stops applying, and its other optional dependency, embeddium at [0.3.25,), is satisfied directly.

Delete the Rubidium jar rather than leaving it beside Embeddium. Embeddium's stub uses the rubidium id, so keeping both means two jars claiming one id, which is its own crash.

One follow on catch: Embeddium declares an optional dependency on Oculus with the range (1.6.15,), strictly newer than 1.6.15. If you swap in Embeddium and immediately get a new error naming Oculus, that range is why, and the fix is a newer Oculus rather than an older one. That mod's dependency metadata has its own problem, covered in the linked guide below.

Reading the error afterwards

Once both mechanisms are visible, the message says what it means. flywheel is the copy bundled inside Create. sodium is Rubidium wearing Sodium's name. 0.6.0-beta.2 is a version that was never released for 1.20.1. 0.5.3 is a number typed into Rubidium's metadata file.

The lesson generalises past this one crash. A mod id in an error is not a filename. It is a claim some jar made about itself, and that jar may be nested inside another download, or may be a port borrowing the name of the thing it replaces. When an error names something you never installed, open jars and read mods.toml rather than searching your mods folder for a file that was never going to be there.