Enthusiastically seconded.
SteamCMD is already halfway there - but lacks the functionality to be a viable replacement.
I would love to be able to access my game collection without the need for Valve's GUI client, and the huge list of undesirable dependencies that comes with (32-bit libraries, x.org. and so on)
IMO a headless version also provides a failsafe for anyone who is experiencing issues with their steam GUI and allows third party launchers to be less intrusive when interacting with the steam API.
Microsoft is getting a lot of flak for imposing features their customers don't want. Copilot is a good example.
Valve isn't all that much better in that regard.
Microsoft is getting a lot of flak for imposing features their customers don't want. Copilot is a good example.
Valve isn't all that much better in that regard.
Seems like a strange and irrelevant tangent, no?
Over the years, the original use case for a Steam console interface has aged in unexpected ways. With the upcoming launch of the new Steam Machine hardware, it’s clear that Valve is continuing to invest in open, flexible, Linux‑based gaming experiences. That said, I believe there is still a strong argument for expanding the Steam CLI or even better, introducing a structured, public-facing API that mirrors Steam client functionality.
Below are several detailed points outlining why this could be valuable for both the community and Valve.
The existing CLI tooling is useful, but it has not evolved at the same pace as the rest of the Steam ecosystem. Many workflows that developers, power users, and tinkerers would like to automate remain inaccessible or require fragile workarounds.
With the Steam Machine and Steam Deck ecosystems growing, the demand for robust automation and integration tools will only increase. A modernized CLI or an API would empower:
The community is already building these things, but often without official support, documentation, or stable interfaces.
Expanding the CLI would require engineering time from Valve, and it’s understandable that this may not be a high‑ROI task. Even though Valve is financially healthy, not every improvement is equally lucrative.
This is why a different model might make more sense:
a paid, officially supported Steam Client API.
Instead of expanding the CLI for free, Valve could introduce a subscription‑based API that exposes the same functionality the Steam client already uses internally. This would:
A paid model is common today and would not be unusual for developers or hobbyists.
Valve could enforce reasonable eligibility criteria, similar to the Steam Deck Verified program or existing account security policies. For example:
This would discourage spam, abuse, and botting while keeping the barrier low enough for legitimate users.
A tiered model could scale with usage:
| Tier | Intended Users | Approx. Price | Notes |
|---|---|---|---|
| Individual | Hobbyists, tinkerers | ~$10+/year | Low‑volume API usage |
| Professional | Tool developers, modders | ~$100+/year | Higher limits, more endpoints |
| Enterprise | Cloud gaming, large platforms | $1000+/year | High throughput, commercial use |
Valve could adjust these numbers as needed, but the general idea is to create a sustainable ecosystem.
Gabe Newell has repeatedly emphasized that piracy is a service problem, not a user problem. A locked‑down Steam client with no official automation or integration paths can unintentionally push users toward alternative platforms that offer more flexibility.
For example, if Steam remains closed while GOG continues to offer DRM‑free installers, users may increasingly choose GOG simply because it allows them to build their own lightweight “home‑client” setups tailored to their needs.
A public API would strengthen Steam’s position by making it the most flexible and developer‑friendly ecosystem, not just the biggest storefront.
A public API would:
This aligns with Valve’s long‑standing philosophy of empowering users, supporting open platforms, and improving service quality.
A modern, officially supported API, possibly with a paid access model, would open up a wide range of possibilities for developers, enthusiasts, and the broader Steam ecosystem. It would reduce friction, encourage innovation, and ultimately benefit Valve by strengthening the platform’s flexibility and appeal.
I genuinely believe this would be a win for everyone involved.
Microsoft is getting a lot of flak for imposing features their customers don't want. Copilot is a good example.
Valve isn't all that much better in that regard.Seems like a strange and irrelevant tangent, no?
Not at all.
The only service I require from Steam is being able to buy, download, update and play games.
I have no need for chat, community, forums, recording, big picture mode, collector's cards, point shops, profile pimping, any of that stuff. I do not want or need to be reminded which publisher is having a sale, or dozens of 'SteamWebHelper' processes consuming my resources.
I'm sure you see the relevance better now?
I have no need for chat, community, forums, recording, big picture mode, collector's cards, point shops, profile pimping, any of that stuff. I do not want or need to be reminded which publisher is having a sale, or dozens of 'SteamWebHelper' processes consuming my resources.
I'm sure you see the relevance better now?
A few points here;
First; Steam is not tailor made for you, so naturally it is going to ship some features other users may find more useful. I'm sure a huge swath of users would find no benefit to a CLI tool at all.
Second, the SteamWebHelper process is literally the entire Steam UI. That includes the library view. That includes the download view. That includes everything. So short of wanting some sort of CLI-only Steam...you're always going to have SteamWebHelper.
Finally, the relevance is still not there. We're discussing an addition, an enhancement. Not our ideal Steam client, or the ideal game launcher.
No need to 'thumbs down' my comments, dude. I'm aware I could stand to have a little more diplomacy, but then again it is hard to remain diplomatic if you are going to employ strawman tactics to dismiss my points.
I'll grant you it is hard to argue that splitting up the Steam client into a CLI-driven backend and an optional UI frontend is something the large majority of Steam users isn't going to care for (or understand what the benefits are) - as long as they get to play their Counterstrikes or what have you, they're happy. They're not tinkerers who like to take a peek under the hood to see how things actually work.
Being the pesky, argumentative, peek-taking kind, I observe the Steam client being very bloated and hugely inefficient, wasting gigabytes of memory and CPU cycles - by just sitting idle in the background.
Using pmap to check Steam's memory usage, the main process reports 1017944Kb of RAM used; that is nearly one whole gigabyte. This is just the main process, multitude of steamwebhelper processes not included. I see it also sees fit to consume about 10% of one of my cores, doing absolutely nothing (from the users' perspective).
Are you going to try and argue with that, mr. 'thumbs down'? With today's RAM prices?
That's not even getting into the fact that it requires creaky old technology such as the deprecated X.org. XWayland is a tool that was supposed to help make the transition to Wayland less painful, yet here we are, with Valve continuing to rely on it, probably for years to come. So, I need to have the entire x.org stack installed - just to use a program that launches other processes.
I would like to play the games I paid a lot of money for, please. Without Valve getting to waste gigabytes of my hard disk space and consuming gigabytes of my RAM.
Thank you.
Steam uses CEF. They use CEF because they need to display a web browser in their app. The place to complain about them using CEF is on the issue specifically pertaining to that, #11638. There's considerable problems that would come from forking the UI into two halves, one half being non-CEF and the other being CEF. That main steam process will exist with or without the CEF Steam Web Helper.
As for Steam itself, on my system the steam process uses 378MB. Are you sure pmap is reporting actual memory usage? Because afaik pmap will report swapped as well as real memory. This is by design, and makes sure RAM is optimally utilized, but can provide a pessimistic view of a process's memory usage. The only memory usage we should truly care a ton about is the resident set.
I'm simply pointing out that this is an issue on a headless mode and enhanced CLI for the client. Broadening the discussion to topics like Microsoft's Windows, AI, and Valve adding features "their customers don't want." is simply leaving the scope of this issue, and seems unduly hostile and negative.
Steam still uses XWayland because certain key CEF functionality is still missing under wayland. See the latest discussions in #4924. On the other hand however, the big screen interface is entirely Wayland. As far as I can tell, it's also still CEF.
You can play your games. Valve is not "wasting" your RAM or disk space. Even a CLI program would need to use some memory and disk space.
I don't know why you're becoming so hostile, and I hope we can come back around to peaceful discussion. I too would like a headless mode and a CLI. I too want a leaner Steam client. We don't need to insult Valve and Microsoft to get those things. We don't need to downplay the usefulness of other features for this suggested one to be worthy of consideration. Valve supports their users in ways no other company ever would. Let's lend them some grace and kindness in reciprocation of that.
The perception of any hostility is entirely yours. Seems like the points I'm making cannot be interpreted without it.
But we do have common ground, and a shared interest in keeping the discussion on point and mutually civil.
Yes, Valve deserves their fair share of kudos for putting their weight behind making gaming on Linux being taken seriously.
(For the sake of remaining on-topic, I'll withold my more cynical views on that subject).
That alone is definitely worth being grateful for.
In regards to a headless client: Steam actually regressed in that regard. The client used to take a command line argument which would start it in minimal mode without any HTML rendering features. They took that option away, which tells me they are invested in making users run all the bells and whistles - probably more so in Valve's interest than their users. Can't know for sure, since it's not open source.
In regards to wasting my disk space. My steam installation folder takes up 20.8Gb, and that's just the bare program - not taking into account any of it's many dependencies (such as the 32-bit libraries). My installed games, compatibility tools, and game compat data are installed elsewhere, mind. The appcache folder is about 400Mb.
Just to put things into perspective, consider this:
These are screenshots of a gaming frontend I'm working on (which is part of a whole desktop environment). It imports local PC games, your Steam library, MAME, RetroArch, you name it. It displays trailer videos, handles reviews, and can be controlled through voice, among many other features.
It takes up 449.3 whole kilobytes of disk space. Actually, including all the plugins it uses to interface with all the gaming platforms, a little over a megabyte.
So yes, Steam is absolutely wasting tons of my disk space. It is incredibly bloated.
And let's not even get into Steam's unwillingness to properly integrate into the host platform.
Steam stopped allowing launch via VGUI because it had gone unsupported. It's naturally not a good idea to continue allowing people to use an unsupported feature as an official option.
Your steam install folder also include compatibility tools, such as proton. It is the majority of the install. It has 32-bit libraries because 32-bit games still exist.
I'm glad your project is coming along well, I hope the best for you.
Your program is doing a lot less, no offense, so naturally it will consume less resources. I can make a shell script that consumes less than any of these and only launches Half Life 2. Is it somehow less wasteful?
You're using very negative language for no real purpose. Bloated is a loaded word that implies the increased resource usage is from features the majority of users don't want or use, but in reality these are things people use and want, by and large.
It doesn't include Proton, I have the proton-ge-custom-bin package which installs it under /usr/share/steam/compatibilitytools.d. I don't have any other Proton versions installed and no compatibilitytools.d folder under Steam either.
For sure the Steam client has functionality my client doesn't, but over 20Gb's worth?...
Most of that functionality is provided by the web backend anyway - not code that's in the actual client.
If you'll forgive my cynicism one last time, Steam is a closed source application used by millions who happily hand over their personal details and other data worth fortunes to some - so how do we know half the code in your client isn't there to strictly serve Valve's bottom line (or, tin foil hat moment, the interest of third parties)?
There is nothing we can do to know - except take your word for it.
There's not much left for me to add without repeating myself, so I will cease commenting further.
It's the only activity this issue is going to see for a very long time, if any. Of course I would love to be proven wrong.
Sooo, we're a bunch of weeks further now.
I'm curious, how did the developer meeting go? In testing phase yet?
When are we going to be able to play our games without requiring your awful software?
Days? Weeks?
Sooo, we're a bunch of weeks further now.
I'm curious, how did the developer meeting go? In testing phase yet?
When are we going to be able to play our games without requiring your awful software?
Days? Weeks?
Let's not unnecessarily bump issues.
You don't get to decide it's unnecessary.
What we ask from you takes 2 days - 3, tops.
And that is you update steamcmd to run any game.
It can probably be done in an afternoon.
So, how far along are you?
You'd rather have we'd just go away and stop being a problem, right?
So Valve, yet another month passed - where is our headless, dependency-free client?
You're this cool company run by the savior of gaming, right? Who wants to do the right thing and embrace open source and such?
I'm almost sure there are legal grounds here to sue you over this, in my country anyway.
I want to be able to use the products I bought - but I do not give you permission to impose your horribly coded and very bloated closed source platform slop on my system. I'd love to get rid of it please.
Just adding my two cents on this:
The thing is that there are valid reasons to want to have a system running purely on wayland with no XWayland compatibility layer at all.
I have an environment set up like this, and I was disappointed that in the end I just can't run Steam games in my favourite DE without configuring it in a way I don't want to.
Right now, this is impossible with Steam because the steamworks API requires the client, and the client requries X11. If we had this functionality separated into a daemon or just a headless mode for the Steam Client, achieving this would've probably been very easy, but right now it can't be done at all because it's all tied up on a monolithic client that requires outdated functionality that's unrelated to actually running the game or using the API.
In general in Linux we like having functionality separated and modular, especially when it brings in heavy dependencies like this that may not match specific setups. And doing things the proper way leads to a more robust, broadly compatible, and sustainable stack in the long term.
Frankly, I don't think it's likely for there to be a business case for a paid API, but also it's just not very sane to think that forcing the steam client webview to be running is a major driver of revenue for Valve (especially since it's immediately hidden/minimized state, and even when not, it's likely defaulting to the Library page and not the Store). More likely it's just a case of the client being monolithic and a lot of functionality being added to it because it was the most convenient at the time to ship quickly / make distribution cross-platform easier, and now it would take a refactoring effort to separate things out.
But if you want to improve the experience in Linux? I´d be glad if you did this, and you'd get a more maintainable codebase in the process.
Nothing extracted yet.
Enable a fully supported headless Steam client on Linux with an integrated command-line tool (either extending SteamCMD or as a new
steamctl). This will eliminate brittle workarounds, streamline deployments, and unlock both common and novel gaming scenarios, from a home-lab streaming to custom szenarios like consoles.1. SteamCMD Today and Its Shortcomings
SteamCMD is Valve’s official console client for installing and updating dedicated game servers on Windows, macOS, and Linux. It supports anonymous or credentialed login,
app_update <app_id>for downloads, and simple scripting for server provisioning.Why SteamCMD does not meet my needs:
To serve headless gaming and console-style hardware, SteamCMD would need deep extensions,so providing an integrated CLI in the Steam client makes more sense than packing features onto a server-only tool.
2. Core Requirements for a Headless Steam CLI
Command-Line Tool
steamctlNative Headless Rendering Support (optional)
Authentication & Security
3. Expanded Use Cases
Home-Lab Streaming:
Spin up one or multiple Linux servers that stream games directly to Steam Link, Moonlight, or custom clients without a full desktop or GPU-equipped host.
CI/QC Pipelines:
Automate game build, installation, update, and test runs on containerized or cloud CI workers.
Event & LAN Hosting:
Rapidly deploy disposable game servers at LAN parties, eSports arenas, or pop-up gaming cafés with simple scripts.
Fleet Management:
Mass-install updates and monitor servers across hundreds of nodes in datacenters or home networks with one CLI.
And my own UseCase: A Cartridge-Based Console for a nostalgic, tactile gaming experience:
Drawing inspiration from the YouTube video “I Missed VHS… So I Made My Own” by @TheStockPot-AU, this concept marries physical media nostalgia with modern game delivery. Imagine a slim Linux distribution that boots straight into a PS2-style launcher shell, with no desktop clutter...
Hardware & Software Foundations
Insertion Workflow
All NFC and UI work, of course, stays with the device maker. While Valve’s role is simply to provide a reliable headless client and CLI that support installation, updates, configuration, and launch operations.
4. Suggested Implementation Path
--headlessflag to the Steam daemon, disabling GUI dependencies.5. Ecosystem Impact & Platform Comparison
An official headless mode and powerful CLI will attract hardware makers, DIY enthusiasts, LAN cafés, game centers, and DevOps teams, driving Steam adoption into new markets. Unlike Microsoft’s Windows-centric offerings, Valve empowers open Linux environments and creative use cases, making Steam the undisputed platform for both consumers and enterprise game deployments.
By formalizing headless operation and CLI control, Valve can empower users to build everything from single-board computer streamers to cartridge-driven consoles, cementing Steam as the universal backbone of gaming hardware and services.