Mediary Scout: Agent-Driven Acquisition for Chinese Cloud Drives
Agent-driven media library for your cloud drives (Quark 夸克 / 115 / 光鸭 GuangYa / 123网盘 / 天翼 Tianyi)
At a glance
- What is it?
- Mediary Scout turns media acquisition into a tracked state problem across Quark, 115, GuangYa, 123 and Tianyi, with an LLM agent choosing and verifying transfers. It is a strong fit for self-hosters already inside that drive ecosystem, and the wrong tool for anyone expecting local downloads or Western indexers.
- Who is it for?
- Adopt Mediary Scout if you already hold a 115, Quark, GuangYa, 123 or Tianyi account and want acquisition tracked as state rather than performed by hand. Skip it if your library lives on local disks, if you rely on Western indexers, or if you need a 光鸭 share-link path that v1 does not provide.
- Can I use it commercially?
- Yes. 0BSD is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Mediary Scout targets: acquisition as state, not as a one-off search
The README states the problem directly: most media automation either searches well but does not know what you are missing, or moves files without verifying what landed. Mediary Scout is built for the second half of that sentence. You ask for a movie, show or anime, an LLM agent scouts your indexers, transfers the best match into your own 115, Quark or 光鸭 drive, verifies what landed, and keeps tracking what is still missing. The audience is narrow and specific: self-hosters who already pay for one of the five supported Chinese cloud drives and who want a library view with missing and airing badges rather than a folder of files they check manually. The repository topics (ai-agent, docker, media-automation, self-hosted, typescript) describe that audience accurately. This is not a downloader and not a media server. It is the acquisition layer between indexers and a cloud drive you already own.
How the agent loop actually works: search, select, transfer, verify, sweep
The mechanism described in the README is a state machine with an agent inside it. Search results come from Prowlarr and PanSou, both listed as settings categories alongside drives, quality, language and the LLM endpoint. The agent reads real search results and picks by quality preference, Chinese-subtitle needs and de-duplication, then verifies the transfer after it happens. Two design details matter more than the marketing line. First, selection is evidence-based: the agent acts on returned results rather than on a guessed title match, which is where de-duplication and subtitle preference have to be resolved. Second, verification is a separate step from transfer, so a share that fails server-side does not silently count as acquired. On top of that sits a season-level state machine. A scheduled sweep returns only for shows that still have missing episodes, which is the part that distinguishes this from a one-shot grab tool. The README also notes that the transfer is cloud-native: shares and magnets go straight into your drive via 秒传 or save, and nothing downloads to a local disk.
Drive support is uneven by design, and the differences decide your use case
Five drives are supported, and the README orders them by how many PanSou resources each can consume. 115 and 123 are dual-path: they accept both own share links and magnets. Quark is share-link only, with no magnet web API, but the README calls it the largest share pool on PanSou by far. 光鸭 GuangYaPan is magnet and offline-download only in v1, transferring magnet, ed2k and BT through its offline-task API, and it does not transfer share links. Tianyi is share-link transfer only and the README is blunt that its share pool is the smallest on PanSou today, weak for movies but workable for shows and anime. That ordering is the most useful thing in the repository for a prospective user, because it maps directly onto what you can actually acquire. A 光鸭-only user cannot consume Quark share links. A Tianyi-only movie collector will find thin results. The README also describes the account model as a tree: one account, many drives, each brand a first-class workspace, with a new drive brand treated as a contained plugin.
Getting it running: two install paths and the one env var that picks your database
The desktop path is the documented default. Download the macOS DMG (Apple Silicon, signed and notarized) or the Windows x64 EXE installer, which is unsigned and will trigger a SmartScreen prompt, then open the app, go to Settings, connect a drive, add an LLM endpoint, search a title and hit 获取. The README states the app bundles its own SQLite data layer and runs the full engine inside an Electron shell, with no Docker, Postgres or terminal required. The Docker path is three lines: copy .env.example to .env (optional, since most config can be set in the UI), run docker compose up -d, then open http://<host>:3000 and configure in Settings. The one config key worth understanding before you choose a path is MEDIA_TRACK_SQLITE_PATH. The README states the data layer is selected by that env var rather than by the process shell: desktop sets it automatically, Docker defaults to Postgres, and SQLite can be forced in Docker by setting it. The Docker path is also the only one with always-on patrol and multi-user support.
Where it breaks down: local-first users, Western indexers, and the 光鸭 share gap
Three limitations are stated or strongly implied in the material. The desktop app does not run always-on patrol; it works when the app is open, so the scheduled gap-fill that defines the product only runs continuously under Docker. The drive matrix has real holes: 光鸭 cannot transfer share links in v1, Quark cannot use magnets, and Tianyi has the smallest share pool, which the README itself flags as weak for movies. Anyone whose collection depends on a transfer type their drive does not support will hit that wall on day one, not at scale. The third constraint is subtler. Because transfers are server-side into a cloud drive, there is no local copy and no local playback pipeline described here. If your workflow is a local media server reading local files, Mediary Scout is the wrong layer, and no amount of configuration changes that. The README also does not describe what happens when a verification fails repeatedly, or how the agent resolves a magnet that never completes, so treat those as unverified until you observe them yourself.
The real alternative: a conventional *arr stack plus a cloud-drive bridge
The obvious comparison is the Sonarr and Radarr family driving a download client, with a separate tool to sync finished files into cloud storage. The difference in approach is architectural, not cosmetic. An *arr stack tracks episodes and movies against local files on disk, and its state model assumes a filesystem it can scan, import into and report on. Mediary Scout inverts this: the drive is the destination, the transfer is server-side, and the tracked state is what exists in the cloud account. That means it does not need a download client, a completed-downloads folder or an import step, and it cannot offer the local file management that an *arr stack provides. The trade is legibility. An *arr stack is well understood, widely documented and independent of any LLM. Mediary Scout's selection quality depends on the LLM endpoint you supply, and the README's BYO-key framing means that cost and quality are yours to manage. If you already run Prowlarr, Mediary Scout can sit on top of it, since Prowlarr appears as a settings category.
Licence, releases and upgrade cost
The licence is 0BSD, which is a permissive licence with no attribution requirement. That is unusually permissive for a project of this scope and removes most of the usual licence review work, though it also means the project makes no reciprocal demand on forks, and nothing here is legal advice. On releases, the cadence visible in the material is roughly one release every one to three weeks: v1.3.2 on 2026-07-23, v1.4.0 on 2026-08-01, v1.4.1 on 2026-08-06, with the last push to main on 2026-09-04. v1.4.0 is titled Mediary Connect 付费远程访问上线, which introduces a paid remote-access feature. That is worth noting as a commercial direction: the core is 0BSD, but at least one capability is sold. The README also documents a CI gate that installs the freshly built Windows package on a clean runner and requires an HTTP 200 health response, while the macOS build must pass native-ABI verification, signing and notarization, with both platforms published together so a failing gate blocks both assets. That is a release discipline claim from the README, not an independent measurement. Upgrade cost for the Docker path is a pull and restart; for desktop it is a reinstall, and the data layer choice means a Postgres-backed Docker deployment and a SQLite desktop install do not share a database file by default.
Editorial conclusion
Adopt Mediary Scout if you already hold a 115, Quark, GuangYa, 123 or Tianyi account and want acquisition tracked as state rather than performed by hand. Skip it if your library lives on local disks, if you rely on Western indexers, or if you need a 光鸭 share-link path that v1 does not provide. Before committing, verify three things: that your chosen drive's transfer path (share link, magnet, or both) matches the title types you collect, that you have an LLM endpoint you are willing to pay for, and that your Docker host can reach the registry, since the deploy guide documents a mirror workaround for mainland China.
Community notes