SysBot.NET turns a Switch console into a remotely driven bot

A client for the sys-botbase protocol

SysBot.NET is described as a sys-botbase client for remote control automation of Nintendo Switch consoles, and the first thing to understand is the division of labour it implies. The underlying protocol work lives in sys-botbase, a separate project by olliz0r, and this repository is the client layer built on top of it. The SysBot.Base component is described as a base logic library to be built upon in game-specific projects, and it contains a synchronous and asynchronous Bot connection class to interact with sys-botbase. That pairing of sync and async connection classes is the detail that matters for an adopter, because a bot that has to run unattended while a human also wants to drive it interactively needs both. The driving force behind the development is described plainly as automated bots for Nintendo Switch Pokemon games, and an example implementation is provided in the repository to demonstrate what the framework is capable of, with the wiki carrying the details on the supported Pokemon features.

A solution of libraries, not a single application

The repository is a Visual Studio solution with a directory per project, and the naming makes the layering obvious. SysBot.Base/ is the reusable core, SysBot.Pokemon/ is a class library using SysBot.Base to hold the logic related to creating and running Sword and Shield bots, and SysBot.Pokemon.WinForms/ is a simple GUI launcher for adding, starting and stopping those bots, with configuration done in-app and saved to a local json file. SysBot.Pokemon.Discord/, SysBot.Pokemon.Twitch/ and SysBot.Pokemon.YouTube/ are the remote interfaces, and SysBot.Pokemon.ConsoleApp/ and SysBot.Pokemon.Z3/ sit alongside them, with SysBot.Tests/ holding the unit tests whose stated purpose is ensuring the logic behaves as intended. Directory.Build.props sits at the root for shared build settings, the solution file is SysBot.NET.slnx, and azure-pipelines.yml holds the CI definition. The design is worth noting because it is the shape you would build if you were writing this yourself: the base connection and the game logic are separated from the launcher and from each remote surface, so a new front end is a new project rather than a change to the core.

Discord does the work, Twitch and YouTube announce it

The three remote interfaces have different jobs, and the README describes each one by what credentials it needs. The Discord interface is for remotely interacting with the WinForms GUI, and it takes a discord login token along with the Roles that are allowed to interact with the bots, and it provides commands to manage and join the distribution queue. The Twitch interface is for remotely announcing when the distribution starts, and it takes a Twitch login token, username and channel for login. The YouTube interface does the same announcing job on YouTube.com and takes a YouTube login ClientID, ClientSecret and ChannelID. The distribution queue is the interesting part, because it is the scheduling layer that decides which bot runs which task, and a Discord command is how a human joins that queue remotely. The dependencies come from NuGet, with Discord.Net for the Discord side, TwitchLib for Twitch and StreamingClientLibrary for the YouTube side, so a project that only needs one interface does not pull in the others.

PKHeX and the template generator do the game-side work

The repository does not implement the game data handling itself. The Pokemon API logic is provided by PKHeX, and template generation is provided by Auto-Legality Mod, with the current template generation using the Auto-Legality Mod fork by santacrab2 rather than the upstream architdate project. That dependency chain explains the shape of the repository, since the hard part of working with a Switch game is the save and party data model, and PKHeX already models it, so this project is about orchestration. The fact that the template generation points at a fork is a maintenance fact rather than an implementation detail, because a template generator has to match the game data format, and the format changes with the game. There is also a note in the repository pointing to a file called SysBot.Pokemon.Z3/, and a console application project, which suggests the framework is also used for a different, non-Pokemon game, which is consistent with SysBot.Base being described as the piece to build on for game-specific projects.

The disclaimer is the most useful paragraph in the README

The project states plainly that SysBot.NET performs online trading and raid hosting in a manner that is unlike real human behavior, that no human will be doing these continuously without end, and that abnormal behavior can be detected, tracked and penalized at any time by the game developer, with the instruction to use the program at your own risk. That paragraph is worth reading before any of the architecture. It is not a disclaimer about warranty, it is a statement about detection, and it changes how you should evaluate the design. A bot that trades or hosts raids continuously produces a behavioural signature, and the README is telling you that the signature is the risk rather than pretending the automation is invisible. The same applies to the scope of the thing. This is a framework for game automation with remote control, not a general purpose device automation tool, and the home page for the project points to the Project Pokemon file distribution rather than to a developer platform.

Licence, support channel and the shape of the project

The licence situation has two layers, and the README points at both. The badge in the header reads AGPLv3, and the licence section says to refer to the License.md file for details on licensing, so the repository carries an AGPL-3.0 grant and the specifics sit in that file. That matters if you intend to run a hosted instance for other people, because the AGPL reaches networked use rather than stopping at distribution. The build system reflects a .NET shop, with a .slnx solution, Directory.Build.props, an .editorconfig and .gitattributes for the source hygiene, and azure-pipelines.yml for continuous integration. Support runs through Discord, with the README asking people to join for help setting up their own instance of SysBot.NET, and adding the note that if the repository has been forked you should seek support from the fork owner instead. The release history shows a single tag, 1.0.0 with the title Initial Release from 2020-02-16, while the last push to the repository was on 2026-09-08, so the code keeps moving without the version tags keeping up.

Where SysBot.NET is the wrong tool

Three limits, and they are the same limits the disclaimer hints at. The first is that the whole project sits inside a game publisher's terms of service, and the README's own words are that abnormal behaviour can be detected, tracked and penalised at any time. A framework that makes continuous unattended behaviour cheap and easy is also a framework that makes account bans cheap and easy, and no amount of engineering changes that. The second is that the game-specific logic is a sample rather than a product, since SysBot.Pokemon demonstrates the pattern for Sword and Shield and the actual work for any other title is yours to write against a game that may change its data format without notice, which is why the template generator is pinned to a fork. The third is the version story, with a single release tag from 2020 while the code has been pushed to as recently as 2026-09-08, so a fork has to track master rather than a tagged release. The alternative worth naming is the underlying protocol library itself, sys-botbase, which you can talk to directly if you need one console and one script, and the other end of the scale is a game modification tool used by hand, which is what PKHeX is for and which avoids the continuous behaviour problem entirely.

Editorial conclusion

Adopt SysBot.NET if you are building scheduled bots for Nintendo Switch games and you need the remote control surface, since the Discord, Twitch and YouTube front ends and the WinForms launcher are the parts you would otherwise write yourself. Skip it if you want to interact with a single console by hand, because PKHeX on its own does that without a bot framework. Before you run anything, read the disclaimer in the README, since the project states that its trading and raid hosting looks nothing like human behaviour and that this can be detected and penalised at any time, and note the licence arrangement, with the code under AGPL-3.0 and the details in the License.md file.

Frequently asked questions

Official sources

1. kwsch/SysBot.NET on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases