BLTH: a userscript that automates Bilibili Live daily tasks from a control panel

A control panel bolted onto the live room player

BLTH is a browser userscript for bilibili.com, published on GreasyFork and on GitHub releases, and it is aimed squarely at individual Bilibili users rather than at developers building on the site. Its job is to take the repetitive daily chores of a live room, watching, interaction, and the small actions that come with them, and run them on a schedule without the user clicking through them every day.

The interface is a control panel rendered to the left of the live video. It is toggled by a blue button with white text above the video, or by the keyboard shortcut alt+b. The panel has a collapsible sidebar, and each feature carries a small circled blue i icon that opens detailed information about that feature. That amount of in-product explanation is unusual for a userscript and suggests the author expects a general audience rather than people who read source code before clicking.

Each feature also shows a status marker on the right. A check mark means the task completed, and hovering over it turns it into a refresh icon so the task can be run again. A cross means the task failed in a way that made it impossible to complete. A rotating loading icon means the task is running now, and no icon at all means the feature shows no task status, is switched off, or is waiting for its next run. The project is written in TypeScript and released under the MIT licence, and the last push to the repository was on 2026-10-11 with v7.3.8 released the same day.

The task cycle runs from 00:05 to 00:05, not from midnight

The scheduling detail is the one most users would otherwise learn the hard way. Most of the daily tasks have a task period running from 00:05 at night to 00:05 the next night, so once 00:05 passes a new round begins automatically. The offset from midnight is small but deliberate, and it means a task set up at 23:50 on one day and checked at 00:10 the next belongs to two different cycles.

Second behaviour worth knowing is that daily task features only take effect on the first live room page when several are open, which exists to stop the same task running twice. Experience improvements and element removal features are the exception and always take effect regardless of which page is focused. The checkmark that means a task completed carries the same intent: the script wants one execution per cycle per account, not one per tab.

Taken together, these two rules describe a design that assumes a single attentive user with a browser open on a live room. It also means the script is not built for a farm of accounts or a scheduled server workload, and there is nothing in the documentation that suggests otherwise.

Refreshing the page interrupts a running task, and only one module can resume

If you enable a feature and want it to run immediately, the documentation says to refresh the page. It also warns that refreshing interrupts the task that is currently running, and that whether the next run continues from the previous progress depends on the individual module implementation. At present only the live-watching module supports resuming from where it stopped.

That caveat is the kind of detail that decides whether a script feels dependable. A user with a dozen modules enabled will eventually refresh at the wrong moment and lose a partially completed task, and only one of those modules will pick up where it left off. The project does not attempt to hide this: the documentation recommends reading each feature's description carefully on first use and then completing all feature configuration in one sitting, which is a workaround rather than a fix.

The second half of the answer is to check the console. Open the browser developer tools with ctrl+shift+i or F12, switch to the Console tab, and look for lines that start with BLTH, which are the script's own logs. The documentation is candid that some of these logs only make sense to advanced users, and it recommends using the Filter box and the ctrl+f search to narrow them down. No other debugging surface is offered.

Installing the script through Tampermonkey, Violentmonkey, or a release link

The install path is a userscript manager rather than a package manager. The documented environment requirements are Chrome, Edge, Firefox, Safari or Opera, plus Tampermonkey or Violentmonkey as the script manager. Before installing, the documentation asks you to read the end user licence agreement in the repository, which is a sign that the project treats its own licence terms as part of the install flow rather than an afterthought.

Three distribution sources are offered, and the difference between them is worth understanding. The GitHub min build is the recommended one: it comes from GitHub, the code is minified, and it is the fastest to run, and future updates arrive from GitHub. The GitHub non-min build is identical except that the code is not minified, and after an update it becomes minified anyway. GreasyFork is the third option, and if you arrived from GreasyFork you are told to ignore the other links and use the install button there.

For the developer path, the repository is a Vue 3 project with an npm script set that is unusually complete. The scripts cover the whole loop:

"dev": "vite",
"build-minify": "run-s \"build-only {@}\" minify --",
"build-only": "vite build",
"type-check": "vue-tsc --build",
"lint:script": "eslint . --fix --cache",
"lint:style": "stylelint src/**/*.{css,less,scss,vue} --fix",
"format": "prettier --write --experimental-cli src/",
"minify": "node scripts/minifyUserscript.js"

The build is a composed pipeline, running type-check alongside a build-minify step that chains build-only and minify, and minify is a node script that processes the built userscript. The other targets are conventional: type-check runs vue-tsc, lint runs eslint and stylelint with fix enabled, and format runs prettier over src/.

Vue, Pinia and element-plus behind a userscript build

The dependency list explains how a fairly rich panel ends up inside a single user script. Vue 3.5 provides the reactive UI, Pinia 4 holds the state, element-plus supplies the component widgets, and vue-draggable-plus makes the panel rearrangeable. vite-plugin-monkey is the piece that turns a normal web app into a userscript, and Vite 8 does the bundling. On the platform side, ajax-hook 3.0.3 is what lets the script intercept and modify the site's own XHR traffic, and crypto-js handles the signing that Bilibili's request APIs require. luxon manages the date and time logic that the 00:05 cycle depends on, and hotkeys-js is what binds alt+b and the other shortcuts.

The build is written in TypeScript with a strict-looking split of tsconfig files for the app and the node tooling, and there is an eslint flat config, a stylelint config, and a prettier config. There is also a script that converts SVG files into Vue components, an svgo step, and a separate script for minifying the userscript output. The project credits the open source projects it builds on, including Vue, vite-plugin-monkey, element-plus, pinia, lodash, luxon, hotkeys-js, crypto-js, ajax-hook, TampermonkeyJS, transform, Inkscape, svgo, and a community-maintained collection of Bilibili API documentation.

The interesting engineering point is that the same codebase contains both a development server and a userscript target. That is a heavier setup than a typical userscript, and it is what makes the project maintainable rather than a single pasted file.

Built to run alongside Bilibili Evolved and the live purification script

The compatibility section is unusually specific for a project of this kind. The stated design goal is that BLTH, Bilibili Evolved, and the bilibili live purification userscript can all run at the same time, and the documentation says that three scripts running together is the intended state rather than a happy accident.

This matters because the whole category is a collision risk. Each of these scripts injects UI into the same page and hooks the same requests, so two of them fighting over the same DOM nodes is the default failure mode, not the exception. A project that says up front that coexistence is a goal has usually thought about which element it grabs and how it reacts to a script that already rewrote the page.

The project also points at two related tools in its recommendations section, Bilibili Evolved and the live purification script by lzghzr, and at a separate fans medal helper project whose original repository is marked as archived. The recommended path for feedback is the GitHub issue tracker, with a bug report template supplied, and users who installed from GreasyFork are asked to report on GitHub to keep the issues in one place.

The scope of all three recommended tools is worth keeping in mind. They are page-level customisation of a consumer site, not an extension of a published API, so their behaviour is tied to the HTML and XHR shape of bilibili.com at any given moment.

Where a browser-side script is the wrong tool

The constraints of this approach are structural rather than accidental. A userscript runs only when a tab with the target page is open and the script manager is active, so any task that must complete whether or not someone is watching a live room will not complete. The daily task cycle handles repetition, but it does not create presence.

Second, everything runs in the browser with the user's own session, so a failure in the site, a change to the request signing, or an expired cookie surfaces as a task error in the panel or a BLTH line in the console rather than as an exception you can catch in your own code. There is no documented headless mode, no scheduler, and no API surface for the tasks themselves, which is a hard boundary for anyone trying to run this server side or at scale.

Third, the licence situation deserves a read before installing. The code is MIT licensed, and the project additionally asks you to read an end user licence agreement before installing. Those are two separate documents and the MIT notice on the source does not by itself answer what the EULA requires of a user.

On maintenance, the repository is not archived, the last push was on 2026-10-11, and the release cadence in the recent past is steady, with v7.3.8 on 2026-10-11, v7.3.7 on 2026-09-13, and v7.3.6 on 2026-08-27. A changelog is kept in the repository for the full history.

Editorial conclusion

BLTH suits an individual viewer who wants the routine daily live-room chores handled by a script they can inspect, and it suits a contributor who wants to extend a TypeScript codebase that already has a build pipeline and a lint setup. It does not suit a team that needs a contractual, server-side data source or a support process, and its EULA means you should read it before installing. Before adopting, install the minified build from the GitHub release, open one live room, confirm the control panel appears on the left of the player, and check the console output for lines prefixed with BLTH before enabling individual modules.

Frequently asked questions

Official sources

1. andywang425/BLTH on GitHub
2. Issues
3. License: MIT
4. README
5. Releases