MarkLLM removed its model weights and told you to fetch them, and the changelog then went quiet

The weights were removed, and there is no model directory to put them in

One section of the file is a note rather than documentation, and it explains why a fresh clone does not work.

The stated reason is size. As the toolkit grew, the model weights for the watermarking methods that train their own models made the repository large enough to be a problem, so they were moved to a dedicated model storage repository on a model hub. The weights were then removed from the model folders inside the main repository, and the instruction to users is to download the corresponding models from the hub according to the paths in the config files, and save them into the model directory of the relevant algorithm before running the code.

Two things follow from that instruction. The paths come from configuration rather than from a manifest, so a user has to read each method's config to learn where its weights belong. And the file at the top level of the repository has no model directory at all, so the destination described in the note does not exist until you create it, per algorithm.

Nothing in the note names a download script, a revision, a checksum or a total size. The estimate for the model set is not given either. So the first hour with this toolkit is spent placing files by hand, and a file in the wrong place is diagnosed by whatever the code does next rather than by an installer.

That is a defensible trade for a research repository and a poor one for a reproducibility surface, and the difference is entirely about documentation of the download step.

Fourteen logged changes, and eleven months between the last one and the last commit

The update log is dated and countable, and the dates do not line up with the repository's activity.

Fourteen entries are recorded, in reverse chronological order. The newest is 22 September 2025, adding a semantic-preserving watermark method. Six days earlier another method was added, and three days before that a watermark stealing attack. Two more came on the same day in July 2025, then one in May, one in March, one in February, one in January, and five more spread through the second half of 2024 including a serving-integration example and two additions from a commercial watermarking product's paper.

The repository's last commit is 5 September 2026. So the newest logged addition is roughly eleven and a half months older than the most recent push.

There are only two explanations that do not require a mistake. Either no method or attack was added in that window, in which case the log is accurate and the repository's recent commits were fixes, documentation or maintenance, or the log simply stopped being maintained while work continued.

Nothing in the file distinguishes the two, and the log is the only change record a reader has: there are no releases, and the version is not in the visible text. For a toolkit whose value is its coverage of the literature, a changelog that may be eleven months stale is a real limit on how much of that literature it covers.

Two dependencies pinned to 2023 releases, fourteen unpinned

The dependency list is seventeen lines long, and it is worth reading as two categories rather than one.

Two entries are pinned exactly. The OpenAI client is pinned to a zero-series release with a specific number, and one imaging library is pinned to a 9.4.0 release. Both of those are 2023-era versions.

The other fifteen entries carry no version constraint at all: no lower bound, no upper bound, nothing. Model and dataset libraries, a tokenizer library, an acceleration library, a subword library, a plotting library, a compilation helper, two retrieval and similarity libraries, a network graph library, a translation library, a tokenizer, a machine learning library and a job runner.

So the file constrains precisely the two packages that were most likely to break, probably for good reasons that are not recorded, and leaves everything else to whatever the resolver picks on the day you run it. In a repository whose methods were added across 2024 and 2025 and whose last commit is in 2026, a floating dependency list is a plausible source of the kind of failure that looks like a bug in a watermark detector.

The one exact pin is also the one that dates the file: a zero-series client predates the current generation of that library, while the log's most recent entries include an example integrating the toolkit with a modern serving stack. Those two facts are in tension, and the file does not explain the resolution.

A couple of the unpinned entries are coherent with the group's own research: a translation metric library and a translation package sit alongside a paper asking whether text watermarks survive translation, and a Chinese segmentation library sits alongside a cross-lingual consistency line of work.

A watermarking toolkit that also ships ways to break watermarks

The most unusual thing about the method list is that an attack appears in it.

One logged addition, from September 2025, is a watermark stealing attack, and it was contributed from outside the group like most of the recent entries. An evaluation harness for watermarks that includes an attack against watermarks is a different proposition from one that only measures whether a marker survives, because it forces the same pipeline to run in both directions.

The surrounding research points the same way. Among the group's own papers on the front page is one asking whether a model's watermark can stop unauthorised knowledge distillation, one asking whether users can identify a watermarked model through crafted prompts, one asking whether watermarks survive translation, and one on the radioactivity of a watermark, which is about what a marker implies about the model that produced it.

Those titles are questions, and the framing is a question about limits rather than a demonstration of robustness. Read next to a toolkit that ships a stealing attack, the picture is coherent: the group is as interested in where watermarks fail as in whether they can be added.

That also sets expectations for anyone evaluating the toolkit for a product decision. A detector passing on this harness means it passed against the attacks the harness contains, and the set grows as new attack papers appear.

The first screen is eight paper cards from the same group

Before any documentation, the file presents a bibliography of the group's own work, eight entries long, each with a venue, a full author list and a link to the corresponding code repository.

The venues span two top conferences, a flagship conference, a conference's main track, a findings track, a spotlight, and a computing surveys journal. Several of the entries are the questions described above. One is a survey of text watermarking, which is the closest thing here to a map of the field.

For a reader arriving to evaluate a toolkit, this is a lot of front page spent on citations rather than on what the software does. The documentation starts underneath: notes, updates, an introduction with an overview and a feature list, a section on using the toolkit in your own code divided into four named tasks, more user examples, demo notebooks, and a citation section.

The four named tasks are a reasonable summary of the intended use: set up the environment, invoke the watermarking algorithms, visualise the mechanisms, and apply the evaluation pipelines. A visualisation step as a first-class task is unusual and worth noting, since it implies the toolkit renders what a watermark actually does to the text rather than only scoring it.

The scope boundary is also stated at the top. For watermarking of diffusion models, covering image and video, the file points to a separate toolkit from the same group. This one is text only, and that is the first thing to check if you arrived looking for media watermarking.

The directory names are the architecture, and there is no model directory

There is no architecture section, so the top-level listing is the map, and it is a legible one.

The algorithms live in a single directory named for watermarking, and by the note's account each algorithm has its own model subfolder for weights that are no longer there. Configuration sits in its own directory, which is what the download note points you at for the paths. Evaluation has its own directory, which is where the pipelines the documentation refers to must be assembled. There is a dataset directory, a utilities directory, a test directory and a separate exceptions directory.

Two entries are unexpected and informative. A fonts directory and an images directory sit at the top level, which means the visualizer draws with real text and image assets rather than plotting abstract markers. That is consistent with a mechanism visualisation that shows the marked text as a reader would see it.

Two files at the root are demos. One is a notebook, and the other is a script for integrating the toolkit with a modern serving stack, which matches the logged addition from December 2024 that provided example code for that integration. A hosted notebook link appears in the badge row as well, so there are three routes in: run it locally, run it in a hosted notebook, or fetch the weights from the model hub.

What is not in the listing is the model directory the note tells you to save weights into, which is the clearest single confirmation that the repository is no longer self-contained.

Most of the recent method list came in through pull requests

The update log credits a person on eight of its fourteen entries, and the credits are specific.

Reading them in order: the semantic-preserving method and the shared-embedding method were both contributed by the same person, the adaptive method by another, the morphing method by another, and the gumbel-style alternative implementation by another. The supporting-integrator example and the two methods from a commercial product's paper credit two contributors between them. The pattern is consistent: the group maintains the framework and the evaluation pipeline, and outside researchers supply the methods.

That is a healthy arrangement for a survey-style project, and the file asks for exactly that in a callout near the top: if you have implemented a watermarking algorithm, or want to contribute one, the maintainers would like to include it.

Two details in the log show the maintenance rhythm. Two methods were added on the same day in July 2025, which suggests a batch import rather than a drip. And the three most recent entries fall in an eight-day window in September 2025, after which nothing was logged, while the repository itself was still being pushed to a year later.

The star and fork counts sit at roughly a thousand and about a hundred, with a single open issue. For a research toolkit that is a wide adoption and a very quiet issue tracker, which is consistent with a repository whose users are mostly running the documented four tasks rather than reporting problems.

Editorial conclusion

Read MarkLLM as a survey with an evaluation harness attached, which is what it is: a group that has published a dozen watermark papers, a survey, and a place to run the methods against each other. That framing tells you how to use it and what not to expect. Before you try to run anything, four things to know. That the repository is not self-contained, because the weights for the self-trained methods were moved to a separate model repository and you have to place them by hand following config paths, with no download script and no checksum named. That it is text only, since image and video watermarking is a separate toolkit from the same group. That the dependency list constrains the two packages most likely to have moved on and leaves the other fourteen floating, so an environment you build today is not the environment the code was written against. And that an attack method is included alongside the markers, which is the right design for evaluation and a reminder that a watermark scheme in this family has a published way to break it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. THU-BPM/MarkLLM on GitHub