AetherSwap and the automation of Steam wallet balance conversion

What the tool actually automates

The project description calls it a fully automatic, zero-code-configuration Steam low-price balance assistant, with a modern visual web console, item selection driven by a mathematical model, and unattended trading from purchase to listing.

The chain is the thing to understand. The README describes a flow of selection, ordering, intake, listing and Steam Guard confirmation, with the claim that 99% of the process runs without human intervention. In a desktop environment the login and cookie extraction happen through an embedded browser, while a headless Linux server automatically degrades to a manual cookie flow. Once an identity_secret is bound, the second confirmation on listing an item is signed automatically by the program.

That is a substantial amount of automation over a marketplace, and the economics of it are not what the word arbitrage suggests. The project's own positioning note is the most useful paragraph in the README. It says the aim is to lower the barrier to converting balance for beginners and save time for experienced users, and then states plainly that this is not a dedicated arbitrage tool and not a magic risk-free way to get cheap balance. An item bought automatically will, after a seven day or multi-day trading cooldown, tend toward the balance price you expected, but this is not guaranteed, and the actual discount ratio after the cooldown can rise or fall. If your goal is to obtain balance quickly, this tool is not for you.

So the correct mental model is a slow, unattended conversion with market risk, not a money printer. The interface supports that reading: a global dashboard for run state, market boards and system settings, with no JSON editing required.

Selection by coefficient of variation and trend fit

The selection logic is where the claimed mathematics lives, and the README names three pieces.

The first is the coefficient of variation, or CV, which quantifies the amplitude of price movement and automatically excludes high-risk items whose prices swing violently. The second is the trend fit, R squared, which fits a linear trend to historical prices in order to identify items that are in persistent decline or whose movement is disordered, which in both cases are bad candidates to hold through a cooldown. The third is reference price calculation, which uses the depth of the Steam sell queue and historical transaction data to pick a listing price dynamically rather than simply posting the lowest possible price.

That reference price point matters more than it first appears. Underpricing to sell instantly means you capture the discount and nothing else, while pricing against the actual queue depth is what makes the seven day wait worth it. It is the difference between converting balance at a loss and converting it at the rate the market is offering.

Alongside the core flow there are two features that have nothing to do with trading. One is a Steam store discount scraper, which pulls currently discounted games in bulk and sorts them by discount depth, user review rating and historical low price, aimed at people who have just converted balance and want somewhere to spend it. The other is a share card generator: right-clicking a game card produces a 1920 by 1080 image of that deal.

The trading side keeps full records as well. Every transaction is stored permanently, with purchase cost, listing price, final sale amount, the actual balance obtained and the combined discount ratio, all shown as charts in the data panel. Whether that history is a genuine analytical asset or a very detailed log of your own losses depends on the market.

The console, the strategy centre, and who decides what

The configuration split is unusual and worth understanding, because it is the design decision that makes the tool extensible.

Trading parameters no longer sit in the settings page. The settings page keeps global configuration for accounts, notifications, proxies, refresh and system behaviour. Everything about what to buy, how to buy, when to sell and how to price lives in a separate Strategy Centre in the left navigation, which has three workspaces.

The purchase strategy decides how candidate items are filtered, how Buff and Steam prices are validated, how historical stability and purchase caps are enforced, and finally whether the item enters the Buff lock-and-pay flow. The sale strategy decides how inventory items are filtered, what the cap on same-name listings is, how the Steam price is set, how trend waiting works, what profit ratio protection applies, and whether the item is listed automatically. The module management workspace shows the built-in modules and any user-imported modules, and lets you inspect which data fields a declarative module can read, which comparison operators it can use, and which run stage it belongs to.

There is a distinction between system presets and custom strategies. The module structure of a system preset is read-only, so the default flow can always be recovered, while module parameters can be edited directly.

Read together, that is a plugin architecture for trading decisions. It also means the tool's behaviour is partly defined by modules you can inspect and edit, and a user-imported module is code you are choosing to run inside an unattended trading system. That deserves more scrutiny than the README gives it.

Running it locally: run.py, two modes, one port

The install path is short. You clone the repository and enter the directory:

git clone https://github.com/VexedWilosn/AetherSwap.git
cd AetherSwap

Then you install the requirements. There are two requirements files, one for desktop or local runs and one for a headless Linux server, the second chosen to avoid installing pywebview:

pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

pip install -r requirements-server.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

Playwright needs a browser, and the README gives both variants:

python -m playwright install chromium

python -m playwright install --with-deps chromium

Finally, the program starts with:

python run.py

After that, a web console opens and the quick start card on the home page walks you through configuration. The setup is described as taking about three minutes: fill in the phone token secret, add a Steam account and verify it, then start the task.

The runtime has two modes and it picks one for you. With a desktop environment it enters desktop mode, binds 127.0.0.1:28472 and tries to open a local window or browser. On a headless Linux box or in a service process it enters server mode, binds 0.0.0.0:28472 and expects an external browser. The port can be changed with environment variables:

set AETHERSWAP_HOST=0.0.0.0
set AETHERSWAP_PORT=28472

And there is a consent gate. The first non-interactive run has to confirm the disclaimer, or the environment can be set to skip the prompt:

set AETHERSWAP_AGREE_DISCLAIMER=1

One troubleshooting note is worth keeping. If startup reports that it cannot import the name Sentinel from typing_extensions, the local typing_extensions is too old, and the fix is to upgrade it or reinstall the requirements.

Docker deployment, uid 1000, and a panel you should not expose

The Docker path exists so a headless Linux server needs no manual Playwright system dependencies, and the compose file is readable. The image is built from a Playwright Python base image for Jammy, installs the server requirements, installs Chromium with dependencies, and then drops to a non-root user:

FROM mcr.azure.cn/playwright/python:v1.49.0-jammy

WORKDIR /app

COPY requirements-server.txt .
RUN pip install --no-cache-dir -r requirements-server.txt \
    && python -m playwright install --with-deps chromium

COPY . .

RUN mkdir -p /app/config /app/log \
    && chown -R pwuser:pwuser /app

USER pwuser

EXPOSE 28472

The container listens on 28472 and the host port is remappable through an environment variable:

AETHERSWAP_HOST_PORT=28472

The compose file mounts the config and log directories as volumes, so data survives a container rebuild, and it sets a healthcheck that polls the runtime API on 127.0.0.1:28472 every 30 seconds with a 10 second timeout and 3 retries after a 40 second start period. The container runs as uid 1000, and the README says to make sure the host config and log directories are writable by that uid.

The security instruction is the most important line in the deployment section, and it is easy to skim past. The README strongly recommends configuring an Nginx reverse proxy and access authentication, and not exposing the admin panel directly to the public internet. That is a correct instruction, and it should be treated as a requirement rather than a suggestion. The panel holds Steam credentials, shared_secret and identity_secret values, and the ability to sign confirmations for listings and to spend money. Anyone who can reach it can act as you on the marketplace.

The panel also includes a one-click factory reset that clears proxies, tokens, database and logs, which is a sensible way to wipe a machine before migrating it.

The dependency list and what it tells you

The runtime requirements are worth reading, because they describe what the tool actually does rather than what it claims to do.

numpy>=1.20.0
playwright>=1.40.0
beautifulsoup4>=4.12.0
requests>=2.28.0
urllib3>=2.0.0
qrcode[pil]>=7.0.0
fastapi>=0.100.0
uvicorn>=0.22.0
pydantic>=2.0.0
typing_extensions>=4.15.0
pywebview>=4.0.0
sqlmodel>=0.0.14
steampy>=0.8.0
Pillow>=10.0.0

steampy is the Steam trading library, which is where the marketplace calls live. Playwright and BeautifulSoup are for the browser automation that handles login, cookie extraction and the store discount scraping. pywebview is the embedded browser window used in desktop mode, which is why the server requirements file exists as an alternative. FastAPI, uvicorn, pydantic and sqlmodel are the web console and its database layer, and numpy is the arithmetic behind the coefficient of variation and the trend fit.

The repository layout matches that description, with app/, buff/, steam/, steamdt/, flags/, analysis/, web/, utils/, config/, tests/ and output_cards/ directories at the top level, alongside run.py, Dockerfile and docker-compose.yml.

The legal and operational position is where to be careful. The project is licensed GPL-3.0, which matters if you intend to modify it and run it as a service for others. It is also a beta: the README badge reads version v0.1.0-beta, the repository has no GitHub releases, and the last push was on 2026-09-19. There is also the question the project does not address, which is how automated buying and listing of marketplace items sits with the rules of the marketplace itself. The README includes a disclaimer section and a contribution invitation, but it does not discuss the platform's terms, so anyone running this unattended should look at that question themselves before letting it trade.

Editorial conclusion

Adopt AetherSwap if you already accept a multi-day cycle on discounted Steam items and want the selection, listing and confirmation steps handled by a self-hosted service with a browser console. Do not adopt it for a short-term balance top-up, because the project itself says the seven day cooldown makes that unsuitable, and the price after the cooldown can move either way. Verify first that your Steam account and network can reach the community without a proxy, that you have read what the tool does with your shared_secret and identity_secret, and that the console is never exposed to the public internet without a reverse proxy and authentication.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. VexedWilosn/AetherSwap on GitHub