StarRailAssistant: driving Honkai Star Rail's daily routine through image recognition

What the tool does and how it refuses to work

StarRailAssistant is an automation assistant for Honkai Star Rail, described as an image-recognition based program that handles the daily routine from launching the game to exiting it. The feature list walks the whole loop.

Starting the game is covered, with the game path selected and the account and password entered for you, and support adapted for the Chinese server. Clearing stamina lets you choose the stage, the number of attempts and the order, with automatic selection of both based on your progression goals. Collecting rewards covers daily training, nameless honour, assist rewards, redemption code rewards, assignment rewards, the Trailblaze weekly rewards and mail. Levelling in the simulated universe stops automatically at the weekly point cap and claims the point rewards. The currency war mode supports standard and overclock play, with a note that the highest difficulty is not guaranteed to be winnable, and can farm opening stages against any investment environment, investment strategy and boss name or trait. Automatic story runs with a skip option. Multi-account switching is supported. Exiting can quit the assistant too, or shut the computer down. A cloud version of the game is also supported so the assistant can run in the background.

The disclaimer is the most important section of the README, and it is unusually direct. The software is an external tool intended to automate the gameplay of Honkai Star Rail, designed to interact only through the existing user interface and to comply with relevant laws and regulations. It is not intended to damage game balance or provide any unfair advantage, and it does not modify any game files or game code in any way.

Then it quotes the publisher's fair play declaration, which prohibits the use of cheats, accelerators, scripts or other third-party tools that damage game fairness, and states that violations lead to confiscating gains, freezing accounts and permanent bans.

The project does not hide the tension. It presents itself as open source and free, for learning and exchange only, and reserves the final right to interpret the project. It also notes that if you find a merchant charging for the use of this software, the problems and consequences are not the project's.

That last paragraph is a practical warning about how such tools get used commercially, which is the real risk for anyone running it on an account they care about.

The stack: a Python core, a .NET 10 frontend, and an image recognition pipeline

The package metadata describes the composition. The Python side needs Python 3.12, and the classifiers call the operating system Microsoft Windows and the development status Beta.

The runtime dependencies explain the approach. opencv-python is the computer vision layer, and rapidocr with onnxruntime is text recognition, so the assistant reads text on screen rather than matching fixed pixel patterns alone. pillow handles image handling, psutil watches the game process, pyscreeze handles the Windows single-instance behaviour, rich and loguru format the console output, selenium is the browser automation layer for the web parts, cmd2 provides the command line interface, and pydantic validates the settings and task configuration objects.

There is also a full optional group, installed with the extras suffix, and the entries are Windows-specific by marker: plyer, pynput, pyautogui, pyperclip, pywin32 and pygetwindow. Those are the input and window manipulation libraries, and the fact that they are all marked for Windows only tells you the automation is designed for a Windows desktop rather than being portable.

The command line entry point is exposed as sra-cli, and the version is derived dynamically from a constant in the source rather than being written in the metadata, so there is a single place to bump it.

The published package includes the localisation resources as package data, with both .toml and .json files, and the build backend is setuptools with a build requirement of setuptools 68 or newer and wheel.

Two frontends for one core: the desktop app and the server-hosted WebUI

The repository layout shows the split. SRACore/ is the Python core, SRAFrontend/ holds the .NET solution, extensions/ holds optional modes, and there are directories for scripts, resources, setup, tasks and tests, plus main.py at the root and a package.json for the frontend tooling.

The package.json scripts show how the two languages are joined. Running the Python side alone is python main.py. Running the desktop frontend on its own is a dotnet run inside the SRAFrontend.Desktop project directory. The production build publishes the .NET solution for win-x64 and then runs a Python packaging script, so the shipped artefact is produced by a Python step after the .NET compile.

The two frontend variants are the .NET desktop build and a server build, and the README explains what each needs at runtime. A build containing StarRailAssistant_DesktopDLC needs the .NET desktop runtime 10.0, and one containing StarRailAssistant_ServerDLC needs the ASP.NET Core runtime 10.0. The web interface needs no separate download, because the WebUI is embedded in the full package that includes the server, and starting the server serves it.

That is the interesting engineering decision. A Python automation tool that needs to survive a crash, or be driven from a phone on another network, wants a server, and a .NET desktop shell wants a native window. Rather than pick one, the project ships both over the same Python core, with the ASP.NET Core variant giving you a remote web UI and the desktop variant giving you a local window.

The localisation is generated rather than hand-maintained in two places, because there is a script that regenerates the .NET resource file from the Python source of truth, and the same pattern appears for the settings models: a script generates the C# settings and task configuration models and the matching Python models, so the two languages cannot drift.

Screen resolution and the two rules that break automation

The README has a short notices section with two requirements, and both of them are consequences of how image recognition works.

The first is resolution. If your screen resolution is greater than 1080p, you must run the game in 1920x1080 windowed mode, and if your resolution is exactly 1080p, you must run it in 1920x1080 full screen mode, otherwise recognition errors can appear.

That is a precise and slightly unusual pair of instructions, and it tells you the tool matches against a known layout. Recognition needs the interface to be in a predictable place, and the interface's position relative to the screen depends on the window size and mode. The rule is effectively that the game viewport must be exactly 1920 by 1080 pixels of content, and the difference between windowed and full screen is what happens to the surrounding area.

The second is the input rule: do not use the keyboard or mouse while a task is running.

Both rules exist because the tool drives the machine rather than talking to the game. It moves the mouse and presses keys based on what it sees, so a second input source is indistinguishable from the automation itself. Any of your own clicking can move the cursor mid-sequence, and the next click lands somewhere else.

That is also the practical reason this kind of tool cannot be run alongside anything else, and why the multi-account and cloud modes are so valuable. If the assistant is running on a machine you are working on, the two will fight over the mouse.

Extensions, and the currency war mode built on top of them

The extensions/ directory holds the optional capability modules, and the README describes one of them in detail.

The CurrencyWarsPlus extension, CurrencyWarsPlus, provides stage lineups, economic operation and flow recovery, with the developer credited as YukkiSSYB. The README says the usage instructions, the updates categorised by major change, general change and bug fix, and the test results are in the extension's own README under extensions/cw_plus.

The division of responsibility is clear from that description. The core knows how to drive the game interface; the extension knows the rules of a particular game mode. A mode that needs a specific team composition, a specific economic strategy and the ability to resume after an interruption is a large body of domain logic that does not belong in the generic automation layer.

The currency war entries in the main feature list match that. Standard and overclock play are automated, with the honest caveat that the highest difficulty is not necessarily winnable, and the opening-stage farming supports any investment environment, any investment strategy, and boss names and traits as parameters.

That last point is worth pausing on, because it reveals how the tool works at its most detailed level. Rather than hard-coding a sequence of clicks, the automation is told what kind of situation it is in, such as which boss is ahead and which trait is active, and works out the sequence itself. That is a much more robust design than fixed click paths, and it is also why a mode-specific extension needs its own configuration surface and its own tests.

Limits: version fragility, the terms of service and what the release cadence says

The limits are worth stating plainly, and the project is unusually honest about the biggest one.

The first is that image-based automation is fragile in a way that API-based automation is not. Any UI change, any new event panel, any shift in the position of a button breaks recognition, and the breakage looks like the tool misbehaving rather than like a version mismatch. The release cadence reflects how much maintenance this demands: v2.24.1 on 2026-10-18, v2.24.0 on 2026-10-11 and v2.24.0-beta.2 on 2026-10-06, with the last push to the repository on 2026-10-20. That is a release every week or two, which is what keeping up with a live game costs.

The second is the terms of service, which the README itself surfaces by quoting the fair play declaration banning scripts and third-party tools, with penalties that include freezing and permanently banning accounts. The project's position is that it interacts only through the normal interface and changes nothing about the game. Whether that satisfies the publisher's rules is a judgement the publisher makes, not the project, and the README's own framing of who bears the consequences is blunt.

The third is that this is a Windows program with Python 3.12 required, so it does not run on macOS or Linux, and the desktop automation libraries are Windows-only by design.

The fourth is the single-purpose nature of it. It does exactly one thing, automating one game's daily routine, and the multi-account and cloud support are about running that one thing at scale rather than about general task automation.

The fifth is the commercial-use question the README raises itself, about merchants charging for the service. A tool like this has obvious commercial appeal and the project is explicit that it disclaims responsibility for what happens if somebody uses it that way.

This tool against an in-game auto-battle feature and against writing your own automation

Two comparisons make the choice clearer.

The first is against the in-game automated battle or idle feature that the game itself ships. Those are supported, they are safe by definition, and they cover the boring part of the routine without any risk to the account. The difference in approach is that the in-game feature only automates what the publisher decided to automate, while an external tool can walk the whole loop including the parts with one-off rewards that a publisher might not script, such as the mail and redemption code collection, and the parts where you want a specific choice made for you, such as which stage to farm based on your progression goals.

The second comparison is against writing your own automation, which is what a lot of people in this space eventually do. The difference in approach is that the hard part is not the clicking, it is the recognition and the recovery. A script that works until the next UI update needs a rewrite, and a script that fails halfway leaves the account in a state you have to recover by hand. The maintained value here is the recognition templates and the flow recovery logic, which are the parts that have to be updated every time the game changes.

The honest framing is that this is a specific, maintained piece of automation for one game, with the maintenance burden of following a live product and with the account risk that the publisher's rules describe. If the daily routine costs you a few minutes and you enjoy doing it, the trade is not obviously worth it. If you run several accounts and the routine takes an hour of clicking, the arithmetic is different.

Editorial conclusion

Adopt StarRailAssistant if you play Honkai Star Rail on Windows and want the daily loop automated, and you accept that image-based automation breaks whenever the game's interface changes. Do not adopt it if your account sits under a platform that forbids third-party tools, since the README quotes the publisher's fair play declaration banning scripts and other third-party tools. Verify first that your display is 1920x1080, that you leave the mouse and keyboard alone while a task runs, and that you have the .NET 10 runtime the build variant you downloaded requires.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Shasnow/StarRailAssistant on GitHub