Millennium: a modding framework for Steam Client themes and plugins

What Millennium changes in the Steam Client

Steam ships a closed client with no supported extension point. Millennium exists to create one. The README describes it as an "open-source modding framework for creating and managing Steam Client themes and plugins", and the repository topics list patcher, plugins-api, skins and reverse-engineering. That combination tells you what kind of project this is: it modifies the running client rather than sitting beside it.

The audience is narrow and specific. Someone who wants a different look for the Steam library, or who wants to add behaviour the client does not expose, is the target user. Someone who wants a supported Valve-sanctioned extension mechanism is not, because Valve does not publish one. The README also states that the framework blocks Steam analytics and crash reporting out of the box and has no built-in telemetry, which is a stated design choice rather than a side effect.

The project is MIT licensed and written primarily in C++. It supports Windows and Linux. There is no macOS entry in the README's platform line.

How the patcher, plugin API and CSS editor fit together

The repository layout is informative. The top level contains src/, packages/, starlight/, thirdparty/, scripts/, tests/ and a CMakeLists.txt with a CMakePresets.json. The presence of packages/ and starlight/ alongside a C++ source tree suggests the framework is not a single binary: there is a native component and a frontend layer, and the localization manager path in the README (src/typescript/frontend/utils/localization-manager.ts) confirms that part of the user interface is written in TypeScript.

The mechanism, as far as the documentation describes it, is a patch applied to the Steam Client. Once patched, Millennium loads themes and plugins into the client process. Themes are CSS with a live-edit editor built in, according to the README's feature list. Plugins get what the README calls "full control over Steam", which is a broad claim and worth reading as an API-surface statement rather than a guarantee.

The part I would flag is that the documentation does not describe how the patch is reverted, and the README does not document rollback. For a tool that modifies another vendor's client, that is the single most important thing to know before running it, and it is absent. Treat the patch as something you understand before you apply it, not after.

Installing Millennium and loading a first theme

The README does not inline the install steps. It points to a dedicated page: "Installing Millennium is only a few steps. See here for a more detailed guide", with the link going to docs.steambrew.app under users/getting-started/installation. Follow that page for your platform, since the Windows and Linux paths differ.

If you prefer not to use the installer, two community-maintained packages exist, and the README is explicit that SteamClientHomebrew only maintains select derivatives while the rest are community maintained. The README links discussion threads for them rather than giving a package name or a command, so read those threads before installing:

# NixOS: see the linked discussion thread
# https://github.com/SteamClientHomebrew/Millennium/discussions/832

# Arch Linux (AUR): see the linked discussion thread
# https://github.com/SteamClientHomebrew/Millennium/discussions/833

After installation, the README's screenshot shows a Millennium settings page inside the Steam Client, which is where themes and plugins are managed.

If you want to build from source instead, the README defers to a separate file rather than repeating the steps:

# build instructions for your platform
# see .github/docs/BUILDING.md

That file is the only build reference the README gives, and it is platform-specific. Once the framework is loaded, adding a theme means writing CSS against Steam's DOM through the built-in editor, and adding a plugin means targeting the plugin API the framework exposes. The README does not include a plugin skeleton, so the API reference on docs.steambrew.app is where you would start.

Beta releases and the cost of tracking them

The newest releases listed are v3.5.0-beta.1, v3.5.0-beta.2 and v3.5.0-beta.3, published on 2026-08-18 and 2026-09-12. There is no stable release in that list. Anyone adopting Millennium today is adopting a beta, and the version numbering tells you the maintainers are still iterating on the 3.5 line rather than freezing it.

The README's feature list claims the project is "maintained very actively, most widespread bugs are fixed in hours". The last push to the repository was on 2026-09-19, which is consistent with a fast-moving codebase, but a push cadence is not the same as a support commitment. There is a Discord linked from the README, and that is where support appears to happen.

Upgrade cost is the real question. A framework that patches a client depends on that client's internals. When Steam updates, the patch has to be reapplied or adjusted, and a plugin that reaches into client behaviour can break without warning. The README does not describe a compatibility policy for Steam updates, and it does not describe what happens to installed themes and plugins when the framework itself is upgraded. If you are running this on a machine you rely on for anything else, that gap matters.

Localization is community-maintained, with the gaps that implies

Millennium supports locales, and the README sets a hard boundary on which ones: "Only languages officially supported by the Steam can be added", pointing at Valve's full platform supported language list. A new locale is built from src/locales/english.json, named after the API language code from that list, and registered by appending it to the localizationFiles array in src/typescript/frontend/utils/localization-manager.ts.

The maintenance model is stated plainly: SteamClientHomebrew maintains only the English locales, and "if any changes are made to the english locales that wreck another language, contributors are responsible for updating them". That is a deliberate trade-off. It keeps the core team's workload bounded and pushes translation upkeep onto whoever cares about a given language. The practical consequence is that a non-English locale can drift out of date after an English string changes, and nothing in the framework forces it back into sync. The README includes a coverage chart per language, which is the only way to see how far behind a given locale is.

When a plain CSS theme loader is the better choice

Millennium is not the only way to restyle Steam. A CSS-only theme loader that injects a stylesheet without patching client behaviour covers the cosmetic case with a smaller surface area. The difference in approach is the point: Millennium patches the client and exposes a plugin API, so it can do things a stylesheet cannot, and it also takes on risk a stylesheet does not. If your goal is a recolored library and nothing more, the plugin API is dead weight and the patcher is unnecessary exposure.

The second alternative is doing nothing and using Steam's own options. That is not a joke answer. Steam's built-in settings cover some of what people reach for third-party tools to change, and a supported setting cannot break on the next client update. Millennium earns its place when you want something Steam does not offer and you accept that you are depending on a third-party patch to keep offering it.

Within the plugin ecosystem, the relevant comparison is between plugins rather than frameworks: a plugin that only manipulates CSS is far less likely to break on a Steam update than one that hooks client functions. The README's promise of "full control over Steam" describes the ceiling, not the typical plugin.

Licence, packaging and what to verify before you commit

Millennium is MIT licensed, and the LICENSE.md file sits at the repository root. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. It does not grant rights to Valve's client code, and nothing in the licence changes the fact that you are modifying software you do not own. That is a factual boundary, not legal advice; if you are deploying this in a managed environment, the question of whether patching the Steam Client is acceptable there is yours to answer.

The packaging situation deserves a second look. The README lists NixOS and Arch Linux (AUR) as external repositories and states that SteamClientHomebrew "only maintains select derivatives, all other repositories and maintained by the community". External packages can lag the upstream beta line. If you install through a distribution package, check which version it tracks before reporting a bug, because the maintainers of the framework are not the maintainers of that package.

On the build side, Windows code signing is sponsored: the README credits free code signing from SignPath.io with a certificate from SignPath Foundation. That matters if you are deciding whether to run a downloaded binary, since an unsigned patcher is a harder sell than a signed one.

Editorial conclusion

Adopt Millennium if you are comfortable running a beta on top of the Steam Client and you want CSS-level control over its interface or a plugin API to build against. Do not adopt it if you need a stable, signed release channel on a machine you cannot reimage, or if you only want a cosmetic skin, since a plain CSS theme loader is less invasive. Before installing, verify which release channel you are pulling from (the newest releases listed are v3.5.0-beta.3), confirm whether your distribution is covered by the community packages for NixOS or Arch, and check whether the plugin you depend on has been updated against the current plugin API.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SteamClientHomebrew/Millennium on GitHub