Kazumi: five lines of Xpath per rule, only // selectors work, and caches carry a 24-hour term

The rule language is Xpath, capped at five lines, and only // selectors work

Everything this application knows about any given anime site is a rule, and a rule is tiny. You build your own with up to five lines of selectors written in Xpath syntax, and the rule editor, rule import and rule sharing are all built around that budget. The constraint that matters is not the length, it is the dialect. The project is explicit in its own question and answer section that support for Xpath syntax is not complete, and that it currently supports only selectors beginning with //. Anything else, and the answer is to model your rules on the examples the project provides. The rules themselves do not live in this repository. They go to a separate rules repository, and you may freely choose whether to leave your identifier in a rule you contribute, which means attribution is opt-in rather than required.

Two playback paths exist, and the compatible one gives up the danmaku

There is a documented failure mode with a documented workaround, and the workaround costs you a feature. If a custom rule can find an anime but will not play it, the project's advice is to turn off the option that routes custom rules through the built-in player, which makes the app attempt playback with a webview instead for better compatibility. The same answer then says that when the built-in player does work, you should keep it on, because it gives a smoother experience and carries the danmaku. That is a straight trade: compatibility against smoothness and bullet comments, decided per rule rather than globally. A second answer explains the boundary from the other side. Some sources use anti-hotlinking measures, and the distinction that matters is who solves them. Kazumi can, an external player cannot. So sending a stream out to an external player can fail on such sources.

Super-resolution costs frame rate without a discrete GPU, and playback caches into memory on purpose

Two performance answers are specific enough to act on, which is more than most projects manage. The first is about the Anime4K-based real-time super-resolution. It demands a great deal of GPU performance, and if you are not running the app on a high-performance discrete graphics card the advice is to choose the efficiency profile rather than the quality profile. There is a second lever in the same answer: applying super-resolution to a low-resolution source rather than a high-resolution one also lowers the cost, which is the opposite of the intuition that you should upscale the biggest file. The second answer is about memory. The program deliberately caches as much of the video as it can into memory during playback in order to give a better viewing experience, so high memory use is the design working rather than a leak. If your memory is tight, there is a low memory mode in the playback settings tab that limits the caching, trading smoothness for a smaller footprint.

Data and cache from using the app should be cleared within 24 hours

The disclaimer is worth reading closely. The licence is GPL-3.0, and the text disclaims any express or implied guarantee of fitness, reliability or accuracy, and excludes the authors and contributors from liability for direct, indirect, incidental, special or consequential damage. Those clauses are standard. The one after them is not. You must comply with local law and must not infringe any third party's intellectual property, and then: data and cache generated by using this project should be cleared within 24 hours, and use beyond 24 hours requires authorization from the relevant rights holder. The application ships an episode download feature and a watchlist, so the tooling and the terms are in tension by design, and the 24-hour condition is the term to understand before you download anything. Everything the app caches on your behalf falls under the same sentence.

The code is GPL-3.0, and the icon and the embedded font are not

The repository separates the licence of the code from the licence of the assets, and does so explicitly rather than leaving you to discover it. The application icon is the work of an artist published on Pixiv, and the project states that the original author retains copyright, that permission was obtained for use in the project, and that the icon is not freely usable. Nobody, it says, may copy, modify or distribute it without the original author's explicit authorisation. The embedded typeface is Mi Sans, developed and owned by Xiaomi. So a fork that rebrands has a problem the GPL grant does not solve: you can do what you like with the Dart, and you cannot reuse the artwork without asking. The repository has a licenses directory at the top level, worth checking before shipping a build under your own name.

HarmonyOS ships from somebody else's fork, and Linux has two package formats that differ

The platform list is longer than the download instructions, and the two ends of it need explaining. Android 10 and above, Windows 10 and above, and macOS 10.15 and above are the straightforward targets. Linux is marked experimental. iOS 13 and above works but requires sideloading, with instructions on the project site. HarmonyOS 5.0 and above is supported too, and this is the detail that catches people: the HarmonyOS build lives in a separate branch repository maintained by a different owner, not in this one, and also requires sideloading. On Linux there are three routes, Flathub, a Debian package, and the Arch User Repository, where there are two packages with a meaningful difference.

[yay/paru] -S kazumi # 从源码构建
[yay/paru] -S kazumi-bin # 二进制包

The first builds from source and the second takes a prebuilt binary. And the project has a question about a Linux build missing its icon and tray support, answered by packaging rather than by a bug: install the deb, because the tar.gz archive exists only to make third party repackaging convenient and that format inherently lacks icon and tray support.

2.3.7 on 2026-09-30, and the acknowledgements read like a dependency manifest

The repository is not archived and the last push landed on 2026-11-02, so Kazumi is actively maintained, with 2.4.0 and 2.4.1 published on 2026-10-22 and 2.4.2 on 2026-10-23. The feature list is a checklist with almost everything ticked: a rule editor, catalogue, search, schedule, subtitles, episode playback, multiple sources, hardware acceleration, high refresh rate adaptation, watchlist, danmaku, online updates, history, speed control, colour schemes, cross-device sync, DLNA casting, external player support, super-resolution, watch together and downloads. Anime update notifications are explicitly not done. Read the acknowledgements next, because they are the actual architecture. An Xpath selector library is described as the foundation of the project. A danmaku platform provides bullet comments, the Bangumi open API provides metadata, Anime4K does the super-resolution, the SyncPlay protocol and its public servers do watch together, and a media playback library provides the cross-platform capability. Two lines are the honest ones: an out-of-tree patch set provides playback of non-standard video streams, and a persistence library stores everything locally. The privacy statement says no user data is collected and no telemetry component is used. Windows builds get free code signing, pull request review is automated, and infrastructure is sponsored.

Editorial conclusion

Kazumi fits someone who watches anime from sources that no official client supports, and who is willing to write or import the rules that describe those sources rather than wait for an app to add them. It does not fit anyone wanting a curated catalogue, because the metadata comes from an open API and the playability comes from rules other users wrote, and it does not fit anyone building an archive, because the project's own terms ask you to clear data and cache within 24 hours. Verify four things first: whether a rule set already exists for the sources you care about in the separate rules repository, whether your machine can afford the super-resolution profile you want, which packaging format you install on Linux, since the tar.gz build has no icon or tray, and whether you are content with a rules dialect where only selectors starting with a double slash are supported.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Predidit/Kazumi on GitHub
3. Project website
4. README
5. Releases