OpenBiliClaw: a local-first content discovery agent that profiles you before it searches

The middleman problem OpenBiliClaw is aimed at

The README makes an argument rather than a feature list. Platform recommenders, it says, weigh a dozen objectives at once: click-through, completion rate, like and coin probability, dwell time, retention, creator ecosystem health, ad revenue. Those weights are set by the platform, and user satisfaction enters the formula as a means to retention and monetization. The README's own summary is blunt: you think you are picking content, but the middleman decides what you can see.

The second half of the argument is about fragmentation. Watch mechanical keyboards on Bilibili for three years and Xiaohongshu knows nothing about it. Your interests sit in separate databases with no one joining them. OpenBiliClaw's answer is to move the matching step onto your machine: build a profile from your behavior, feedback and conversations, then search outward from that profile. The target reader is someone who already uses several of these platforms and is willing to run a local service to get one merged view. This is not a tool for someone who wants a better Bilibili feed and nothing else.

How the profile, sources and feedback loop fit together

The architecture visible in the repository is three pieces. A Python backend in src/ owns storage, the profile and source adapters. A browser extension in extension/ supplies account-state signals, because platforms such as Bilibili, Xiaohongshu, Douyin, YouTube, X, Zhihu, Reddit, Weibo and GitHub need a logged-in browser. A web UI is served by the backend itself at http://127.0.0.1:8420/web, with a mobile layout at /m/.

The README divides sources by how they are reached. Linux.do, Bangumi, V2EX, Weibo and GitHub can be discovered publicly; GitHub is read through the official REST API anonymously, and a public username can seed the profile with starred repositories, with a PAT as an optional way to raise rate limits and verify identity. Everything account-bound reuses the installed extension. Data defaults to a local SQLite file, which is the concrete meaning of local-first here.

The learning loop is the part worth scrutinizing. Likes, dislikes and chat feedback are stated to change later recommendations, and the README describes the profile deepening continuously from cross-platform usage. The mechanism is described at the level of intent, not as a published ranking formula. There is no documented explanation of how a single dislike is weighted against a long watch history, so treat the feedback loop as a behavior you can observe rather than a parameter you can tune. The extension talks to the backend over runtime-stream WebSockets, which pyproject.toml lists as a core API used by both the extension and the web UI.

Installing OpenBiliClaw and getting a first recommendation

The README's quick start is four steps and assumes a normal user, not a developer. Step one is the Chrome extension, either from the Chrome Web Store or from a zip on the Latest Release page. The README notes the store build may lag the release by a few days, so the zip is where new functionality lands first.

Step two is the backend. Desktop installers for macOS (.dmg) and Windows (.exe) live on the same release page, and each platform ships two variants: a slim build that downloads the bge-m3 embedding model on first launch, and a -with-embedding build that already contains bge-m3 (~1.1GB) for offline use. Pick the full build if your network to the model host is poor.

Step three is connecting a source. Log in to Bilibili in the browser that has the extension; Bilibili is the default initialization source. You can switch to Xiaohongshu, Douyin, YouTube, X, Zhihu, Reddit, Linux.do, V2EX, Weibo or GitHub instead.

Step four is opening the interface:

http://127.0.0.1:8420/web

For a phone on the same LAN, the README points at the QR code in the extension, which opens http://<your-computer-LAN-IP>:8420/m/; saving that to the home screen gives an app-like entry point. A separate Flutter client in the OpenBiliClaw-mobile repository connects to the same backend after you enter the backend address in its settings.

If you would rather change source or customize deeply, the README offers a different path: paste a prepared instruction into an AI coding assistant such as Claude Code, Codex CLI or Cursor. The instruction tells the assistant to deploy the backend from a specific raw documentation URL and warns it to use Bash curl rather than WebFetch, because WebFetch drops key instructions.

请按照 https://raw.githubusercontent.com/whiteguo233/OpenBiliClaw/main/docs/agent-install.md 的说明帮我部署 OpenBiliClaw 后端(务必用 Bash 的 curl 下载这个文档,不要用 WebFetch — 会丢关键指令)

There is also a container path. docker-compose.yml defines an ollama sidecar whose image bakes bge-m3 at build time and seeds it before serving, so the container reaches embedding-ready without a network pull, plus an openbiliclaw-backend service built from the repository Dockerfile. The Dockerfile targets python:3.11-slim, which is published for linux/amd64, linux/arm64, linux/arm/v7 and linux/386, so the same file builds on Apple Silicon, x86_64 Linux, Raspberry Pi 4/5 and Windows with Docker Desktop. The Ollama healthcheck greps for bge-m3 in ollama list; if the baked seed is missing or corrupt the container fails its healthcheck rather than silently degrading, unless you set OPENBILICLAW_OLLAMA_ALLOW_PULL=1 to opt into a runtime pull.

Remote access, Tailscale and the credentials it does not store

Cross-device access is handled by an in-app Tailnet rather than by exposing the backend. The desktop installers bundle a helper; on a source install you build it yourself, then enable it:

openbiliclaw tailnet build-helper
openbiliclaw tailnet enable

The README states the helper build needs Go 1.26.6, and that the machine does not need a system-wide Tailscale installation. The entry point is off by default and visible only inside the tailnet; Funnel and Serve are not enabled. Credentials can be a web login, a tskey-auth-... key, or a tskey-client-... OAuth client secret with a device tag. They are held privately on the machine until the next start and are stated not to enter config.toml, API responses or logs. The README recommends turning on the app password at the same time, which a source install can set with openbiliclaw set-password.

One boundary is stated plainly: the Android and iOS builds of the separate Flutter client embed tsnet, and the desktop app can join the same tailnet, but the Web, Linux, macOS and Windows Flutter clients are outside that capability. If your plan is a Linux Flutter client over Tailscale, that path is not offered.

Where OpenBiliClaw is the wrong tool

The most important limitation is in pyproject.toml, not the README: the classifier reads Development Status :: 2 - Pre-Alpha. Version numbers in the 0.3.x line, with three separate release artifacts (openbiliclaw, extension, desktop) that must stay in step, are consistent with that label. Anyone who needs a stable plugin API or a long support window should read the version history before committing.

There is a second, structural cost. The extension is the mechanism for account-state sources, so OpenBiliClaw's coverage of Bilibili, Xiaohongshu, Douyin, YouTube, X, Zhihu, Reddit and Weibo depends on a browser session and on those sites' pages continuing to behave as the adapters expect. Public discovery for Linux.do, Bangumi, V2EX, Weibo and GitHub is less exposed to that, but it is also a narrower signal. A user who wants pure API-based discovery with no browser in the loop will find the account-bound half of the platform list unavailable.

Resource use is the third constraint. The embedding model is roughly 1.1GB, and the slim installer downloads it on first launch. On a metered or restricted connection that download is the difference between a working install and a stalled one, which is exactly why the -with-embedding variant exists. Finally, this is a discovery agent, not a downloader or a media library. Nothing in the repository suggests it replaces a tool whose job is fetching or archiving content.

How it differs from yt-dlp and from a platform recommender

The nearest familiar tool is yt-dlp, which appears in OpenBiliClaw's own dependency list. The difference in approach is the direction of the query. yt-dlp takes a URL or a search term you already decided on and fetches it; it has no model of you and no opinion about what you should watch next. OpenBiliClaw inverts that: the profile is the input, and the agent decides what to search for. It uses yt-dlp as plumbing rather than as the product.

Against a platform recommender, the difference is who owns the objective function. A platform ranks items to serve its own weighted goals across all users. OpenBiliClaw ranks for one person and stores the evidence locally in SQLite. That is a real trade: you lose the platform's enormous behavioral dataset and its freshness, and you gain a profile you can inspect and a search that crosses platform boundaries. The README also lists scrapetube, bilibili-api-python, twitter-cli and rdt-cli as dependencies, so steady-state discovery for X and Reddit can run through those console tools rather than through the browser, which keeps the default install working for [sources.twitter] and [sources.reddit].

One more difference is packaging. OpenBiliClaw ships a DeepSeek Harness client plugin from a separate repository, dsh-openbiliclaw, which adds a persistent fourth column in the DSH interface (recommendations, library, chat, profile, settings) and registers 22 Agent Bridge tools so an agent inside DSH can read recommendations, answer probes and close the learning loop. That integration has no equivalent in a plain downloader or in a platform feed.

Licence, upgrade cost and what the repository shows about maintenance

The licence is MIT, declared in LICENSE and in pyproject.toml as license = { text = "MIT" }. That permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are kept. THIRD_PARTY_NOTICES.md exists at the repository root, and the dependency list is long and includes yt-dlp, which has its own licensing history; if you redistribute a bundled build rather than running it yourself, read that file rather than assuming MIT covers everything in the image. This is not legal advice.

Upgrade cost is shaped by three artifacts released together: openbiliclaw-v0.3.220, extension-v0.3.220 and desktop-v0.3.220 all appeared on 2026-09-09. The backend and extension versions are meant to match, and the README warns that the Chrome Web Store build can trail the release zip. The Dockerfile is written to keep rebuilds cheap: it copies pyproject.toml alone into a cached layer and installs dependencies from a generated requirements file before copying src/, so a source edit does not force a full dependency reinstall.

The repository is not archived, and the last push was on 2026-09-09. That is recent, but the pre-alpha classifier and the 0.3.x numbering are what should set expectations about interface stability.

Editorial conclusion

Adopt OpenBiliClaw if you want your recommendation signal to live in a SQLite file you control and you are comfortable with a project that labels itself pre-alpha. Skip it if you need a stable API, a managed service, or a single-platform Bilibili client. Before trusting it with real history, verify that the desktop build starts, that the extension connects, and that a fresh account can reach the web UI at 127.0.0.1:8420/web.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. whiteguo233/OpenBiliClaw on GitHub