# KitX is a three-layer plugin platform that connects functions across your devices > KitX is a C# project where plugins written in different languages are loaded by per-language loaders and driven through a dashboard, so a function on one machine can call a function on another. It is AGPL-3.0 licensed with a separate business licence file, and the last push was on 2026-09-15. **Crequency/KitX** — An all-purpose toolbox app that connect everything. - Repository: https://github.com/Crequency/KitX - Website: https://kitx.apps.crequency.com - Stars: 1,158 · Forks: 44 - Language: C# - License: AGPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/crequency-kitx ## A plugin market where the function is the unit of sharing KitX describes itself as an all-purpose toolbox app that connects everything, and as an open, shared, connected and free tools platform. The vision statement puts it plainly: the KitX Project is going to build a world where everything is connected. The unit of sharing is the plugin, and the plugins are not required to be written in the same language as the app. The README describes developers uploading plugins they wrote in their preferred languages and frameworks to a plugins market, where users download and combine the ones they like. Every plugin contains atomized, platform independent functions, and KitX connects those functions to each other. The worked example in the README shows what that means concretely. KitX is running on the user's devices. The user presses Ctrl + Alt + A, which has been assigned to a Cast remote screenshot function from a Screenshot plugin. That function asks KitX for a remote device and suspends, waiting for a response. The user selects DESKTOP-Bedroom, and KitX returns the selection. The function then asks KitX to call the Cast screenshot function from the Screenshot plugin on that device, and the remote returns a screenshot which is displayed on the current device by a local plugin. Read that sequence carefully, because it is the product. The keyboard shortcut is handled by a plugin, the device picker is handled by the app, and the remote execution is handled by a second plugin on another machine. A plugin is not a form or a panel, it is a function you can call, and the app is the thing that routes between them. ## Plugin, Loader, Dashboard is the whole architecture The README draws the architecture as a three-layer design in a plain text diagram: ```plaintext Plugin <-> Loader \ \ Plugin <-> Loader <-> Dashboard <-> User / Plugin <-> Loader / ``` Each language or framework has a corresponding Loader, and the Loader is what makes a plugin interoperable with the rest of the system. Loaders communicate with the Dashboard through a Socket, reporting the situation and passing commands. The Dashboard is the part the user actually interacts with, and the user is on the right of the diagram. The third party is responsible for referring to the documentation to implement the interface that a plugin should implement. How the different frameworks of each language are implemented, and which loaders are chosen to implement them, differ. That is the plugin SDK contract, and it is why the repository ships a KitX SDK directory alongside the code. The design decision worth noting is that every layer is replaceable. The README says each of the three-layer designs can be replaced, that any layer can be customised, and that a third-party solution can be used instead. It also says that in this way, plug-ins on other devices in the LAN can be connected to the current device, so LAN interconnection can be achieved. The flexibility is the point, and the cost is that nothing is standardised beyond the SDK. ## The platform matrix tells you where it runs The requirements table in the README is a support matrix with an unusual amount of detail, and it reads across architectures rather than just listing operating systems. Windows 10 and 11 are supported on x86 in both x32 and x64 and on arm in arm and arm64. Linux is supported on x64 and on arm and arm64, with risc-v and mips marked as unsupported, and loongarch32 and loongarch64 present but marked as ToDo. MacOS is supported on x64 and arm64, with the other columns crossed out. Android is listed as Android 5.0 or newer, with a minimum of 21, compiled against 33 and targeting 33, on x64, armeabi-v7a and arm64-v8a. iOS 12.0 or newer is listed for arm64 only. A Raspberry Pi row is present at the bottom of the table, though the README does not show its contents. The architecture coverage tells you something about the implementation. A toolkit that ships x32, x64, arm, arm64, armeabi-v7a and arm64-v8a builds, and that is working towards loongarch, is a codebase with a cross-compilation matrix behind it rather than a single desktop application. The repository topics list matches: android, avalonia, avaloniaui, desktop, dotnet, flutter, flutter-apps, flutter-web, ios, linux, macos, mobile, wasm and web all appear. That set of topics suggests a mix of UI technologies inside one project, with Avalonia for the desktop shell and Flutter for some of the mobile and web surfaces, and the wasm entry points at the WebAssembly target for the web build. ## Three build pipelines, a solution file and a workspace per language The build story in the repository matches the three-layer design. The README badges show three separate GitHub Actions workflows: build.yml labelled Build Universal, build-loaders.yml labelled Build Loaders, and build-plugins.yml labelled Build Plugins. Universal, loaders and plugins are three separate build targets, which matches the architecture rather than contradicting it. The top level of the repository is organised as a.NET solution. There is KitX.sln, a newer KitX.slnx, a KitX.code-workspace for editor workspaces, and KitX.sln.DotSettings carrying the shared IDE settings. The code sits in named directories with spaces in their names, KitX Clients/, KitX Docs, KitX SDK and KitX Standard, alongside a.gitlab/ directory, a.cheese/ directory, a commit-template.txt for commit message conventions, a nuget.config and a ChangeLog.md. The C# formatting is handled with CSharpier, configured through the.csharpierrc.yaml file, and the primary language of the repository is listed as C#. The.gitmodules file indicates that at least some part of the tree, most likely the loaders or the SDK for other languages, comes from another repository. The business licence is a separate file. The repository ships both LICENSE, which the licence badge points at, and a BUSINESS-LICENSE file, and the topic metadata lists kitx-loaders and kitx-plugins as separate concerns, which is consistent with the idea that the loaders and the plugins are developed on their own schedules even though they live in the same tree. ## Where the platform is weakest The gap between the vision and the shipped artefacts is wide here, and the release history is the evidence. The newest tagged releases are v3.23.04.6488 from 2023-03-12, v3.22.04.6287 from 2022-10-02 and v3.22.04.6235 from 2022-08-11. Nothing has been tagged since March 2023, even though the last push was on 2026-09-15 and the repository is not archived. So development continues on main, but there is no named release that captures it, and the version numbering scheme itself, a three-part version with a four-part build number, has not been exercised by a release in three and a half years. The README is also written in a way that admits incompleteness. The tablet and desktop screenshots are commented out in the README source, and the text describes what the project is going to build rather than what it does. The Android support row is precise, down to the exact minimum, compile and target versions, which is good documentation practice, but it is precise about a platform matrix rather than about a workflow. A second weakness is architectural rather than temporal. Because plugins are written in whatever language their author prefers and connected through socket-based loaders, a plugin that depends on a native library, a specific runtime, or a permission on the target device will not work everywhere. The README does not document a plugin manifest format, a capability declaration or a sandboxing model, and those are precisely the mechanisms a plugin ecosystem needs to be safe. The layering that makes KitX flexible also means the pieces that normally enforce safety in a single application are the parts the documentation leaves open. ## Licensing and the question of what you are building on KitX is licensed under AGPL-3.0, and the repository contains a second file called BUSINESS-LICENSE. The README does not summarise the terms of either, so the practical position depends on reading both files. That combination is a recognised pattern for a project that wants to keep open source use open while offering a separate path for commercial deployment, and it is the first thing to check if you plan to embed KitX in a product. AGPL-3.0 in particular reaches beyond the binary: it is the licence chosen for network use cases, which fits an app whose plugins talk to each other over a LAN and whose dashboard talks to remote devices. The important thing is that the two files are not interchangeable, and the README does not say which applies to your situation. The docs split the same way. There is an English documentation site at kitx.docs.crequency.com/en/ and a Simplified Chinese one at kitx.docs.catrol.cn, which is a different domain from the app's own site at kitx.apps.crequency.com. The English documentation being the one linked from the README, with the Chinese version on a separate domain, suggests the project runs more than one documentation site, and readers of either should check whether the two are in step. The community infrastructure is conventional: GitHub Discussions and a commit activity badge. The repository also carries a ChangeLog.md, which given the absence of tagged releases since 2023 is likely the most useful record of what has actually changed. ## Conclusion KitX suits a developer who wants to write one function in their preferred language and have it callable from a phone, a desktop and a browser across a LAN, and it does not suit a user looking for a finished toolbox, since the newest tagged release is from 2023 and the app is still described in the future tense. Before adopting it, read the BUSINESS-LICENSE file next to the AGPL-3.0 licence, because the repository ships two and the practical terms depend on how you use it. Verify first that a loader exists for the language and framework you plan to write in, since the README ties each loader to a specific language and the interoperability is the whole design. ## FAQ ### What is KitX? KitX is an open, shared plugin platform described as an all-purpose toolbox app that connects everything. Developers upload plugins written in their preferred languages and frameworks to a plugins market, and users download and combine the functions they want. ### How does the KitX plugin and loader architecture work? Each language or framework has a corresponding Loader, and Loaders communicate with the Dashboard through a Socket, reporting the situation and passing commands. The README says each of the three layers can be replaced or customised, and that plug-ins on other devices in the LAN can be connected to the current device. ### Which platforms does KitX support? The requirements table lists Windows 10 and 11 on x86 and arm, Linux on x64 and arm, MacOS on x64 and arm64, Android 5.0 or newer with a minimum of 21, and iOS 12.0 or newer on arm64. A Raspberry Pi row is also present, and loongarch is marked as ToDo on Linux. ### What licence is KitX released under? The project is licensed under AGPL-3.0, and the repository also contains a separate BUSINESS-LICENSE file. The README does not summarise the terms of either, so both need to be read directly. ### How is KitX built? Three GitHub Actions workflows build it: build.yml for the universal build, build-loaders.yml for the loaders and build-plugins.yml for the plugins. The C# solution is KitX.sln, with KitX SDK, KitX Standard and KitX Clients directories, and formatting handled by CSharpier. ## Sources - [Crequency/KitX on GitHub](https://github.com/Crequency/KitX) - [License: AGPL-3.0](https://github.com/Crequency/KitX/blob/main/LICENSE) - [Project website](https://kitx.apps.crequency.com) - [README](https://github.com/Crequency/KitX/blob/main/README.md) - [Releases](https://github.com/Crequency/KitX/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crequency-kitx