Suite / BitAgent / Compared with bitmagnet
BitAgent and bitmagnet
What the fork adds, and what it owes upstream. Both halves stated plainly.
If you run bitmagnet and are wondering whether a fork is worth it, or you are choosing between the two, this page is the honest comparison — including the parts that favour staying where you are.
The situation, factually
bitmagnet is a self-hosted BitTorrent DHT crawler and Torznab indexer. BitAgent was cut from it in April 2026 at commit 2b9e8ea, which had been the head of upstream main since July 2025 — more than nine months without a commit — and stopped tracking upstream at its rebrand that same month. The upstream remote stays configured, for security-fix surveillance rather than merges.
Upstream has moved since: a dependency fix for its TMDB integration landed in May 2026 and shipped as v0.10.1-beta.1. An earlier version of this page said upstream had not moved since July 2025, which was wrong. How active a project is right now is the fact on this page most likely to have changed by the time you read it, so check upstream's commits for yourself.
A quiet project is not an abandoned one, and this page is not an argument that you should switch. It is the information you need to decide.
What is still upstream's work
This matters more than the list of additions, because it is the part a fork can quietly stop saying. The DHT protocol implementation, metainfo fetching, the CEL classifier engine and the Postgres/GraphQL foundation are bitmagnet's, and they are the reason everything else was possible. BitAgent is MIT-licensed because bitmagnet is, every upstream copyright notice is preserved, and the lineage is stated on the front page of the repository rather than in a footnote.
If you are evaluating the fork, evaluate it as "bitmagnet plus a loop", not as a new indexer.
What the fork adds
A feedback loop from your *arrs
The headline difference. Sonarr, Radarr, Lidarr and Readarr webhooks, a history poller and a qBittorrent poller land every signal in an append-only evidence table, which resolves by explicit precedence into one canonical label per torrent. What you actually grabbed and kept becomes an input to what gets indexed and how results are ranked.
Curation rather than collection
A deterministic content filter — language, lossy-audio-only music, NSFW, blocked extensions and content types, foreign audio — in pure Go with no network or database call per decision, and anime-aware so watchable anime is not dropped on a script heuristic.
Titles that match without an LLM
An anime backbone that reads fansub brackets, absolute episode numbers and romaji season markers, backed by an alias table joining AniDB titles to TMDB mappings, so romaji, kanji, English and fan aliases resolve to one id.
Swarm numbers that are real
A BEP-15 UDP scrape worker refreshes seeders and leechers from public trackers at roughly seventy infohashes per datagram, replacing a one-node estimate that was never refreshed.
Metrics you can act on
A bitagent_* family per subsystem, plus counterfactual would_* metrics so you can read what a rule would have done before you enable it.
An operator console in the same image
Indexer win rate, match rate, grab liveness, evidence per source, a quarantine you can spot-check, and a read-only view of the running configuration — no second deployment.
The LLM stages, and why they are off
Four points in the pipeline can ask a model over any OpenAI-compatible endpoint, hosted or on your own LAN. Every stage runs in shadow mode first so you can compare its verdicts against what you would have done; daily and monthly budgets persist in Postgres; zero means stop; and anything from a private tracker never leaves the house.
They are off by default and should stay off until the shadow numbers convince you, which is the same advice as for any classifier you did not write. The metrics exist precisely so that "it seems better" is not the basis for turning one on.
Reasons to stay on bitmagnet
It already does what you need
If you want a DHT crawler feeding Torznab and nothing more, upstream does that, and a fork is extra surface area for no gain. Quiet is not broken, and upstream still ships fixes.
You prefer the larger project
bitmagnet has more users, more issues answered, and more people who have hit your problem before. A fork maintained by one person does not.
You do not run *arrs
The evidence loop is the reason this fork exists. Without Sonarr, Radarr, Lidarr or Readarr feeding it, most of what was added has nothing to learn from.
What a fork costs
Worth saying, because it is the part comparison pages usually leave out. Forking splits attention and duplicates maintenance: a security fix upstream has to be noticed and carried across by hand, the two projects' schemas have diverged past the point of merging back, and anyone choosing between them now has a decision they did not previously have to make. Against that, the evidence loop needed changes across the classifier, the schema and the indexer at once, which is not a change that lands as one pull request on someone else's project.
The fork was the right call for this use case. It is not automatically the right call for yours.
If you want to try it
Two containers, no accounts and no API keys: copy the example env, set one Postgres password, and bring it up. Metrics climb within a minute and the console is on port 8080. Wiring it to the *arrs is a Torznab endpoint in Prowlarr (or each app directly) plus a webhook back at BitAgent, which is what closes the loop.
Both projects index a public DHT and neither hosts content; what you do with an index is your responsibility and your jurisdiction's. The repository's legal note covers that properly.
- BitAgent — what it does, the dashboard, install
- Improvements over upstream — the itemised list, with the baseline commit to diff against
- bitmagnet — upstream, and the work this is built on