What happened
Project account p-e-w released Heretic v2.0.0 on GitHub on November 1, 2026. The release is explicitly a major version with a backwards-compatibility break: configuration files made for Heretic 1.x are not compatible with Heretic 2.0. Users of earlier configurations are directed to a migration guide to make their old setups work. This is not presented as an optional cleanup or a patch-level adjustment; existing users need to account for the configuration transition before upgrading a working workflow.
Heretic is an open-source tool for automatically editing refusal behavior in local language models, described in the supplied material as ablation. The release adds headless operation and end-to-end tests. Headless operation is the operationally consequential change: the tool can be run without an interactive session, giving builders a way to place a model-editing run inside a scripted or otherwise automated process. The release notes establish that the capability and tests were added, but do not specify a reference CI configuration, an access model, or a recommended production deployment pattern.
The second headline addition is a generic plugin system. The changelog also lists modifier plugins and ARA, plus a reproducible property for plugins. Together, these are extension points rather than a claim that a particular set of extensions is bundled or independently validated. The release adds a generic BERT Classifier scorer plugin and a benchmark scorer, and it permits selection of a dataset's specific configuration or subset. It also lets the optimizer disable MLP ablation through a zero max_weight floor. These additions expand how a user can score, configure, and modify an editing run, but the notes do not quantify their effect on model behavior.
Several changes concern evaluation, compatibility, and reproducibility. Heretic 2.0 corrects total trial counts when additional trials are added; resolves a Windows UnicodeEncodeError during model evaluation; validates scorer instance names in configuration; and improves detection of thinking prefixes in responses. The release further supports models whose chat templates reject the system role, supports models with Hyper-Connections, and fixes handling of flattened hyper-connection residual streams. It records that benchmark output skips non-metrics, upload tags can be configured, and Python 3.14 and 3.15 were added to the CI matrix.
The release removes research features from Heretic and names Lophius as the intended replacement. That is a product-boundary change as well as a feature removal: users relying on those functions cannot infer that their workflow continues unchanged in the core project. The supplied material provides no price, hosted tier, usage limit, licensing detail, or security guarantee. Heretic is presented through its GitHub release rather than as a paid hosted service.
What the archive adds
This is a new release on a known topic, rather than a restatement of the earlier community-model report. A community-modified Qwen3.5-4B called Qwen3.5-4B-heretic was reported to sharply reduce refusals with little benchmark drift. Heretic 2.0 is the tool release, not independent evidence about that model's quality, safety, or benchmark results.
The archive also covered a plugin system in Mercury Agent 1.4.0. Both releases expose extension mechanisms, but they concern separate products and very different workflows.
Trend signal
The release weakly supports agent-ready software exposes capabilities. A generic plugin system makes parts of Heretic's scoring and modification workflow extensible rather than requiring every feature to be absorbed into the core project. The support is limited: the release notes do not define a cross-tool protocol, permission model, or governance system for plugins. It is evidence of a single project exposing an extension surface, not evidence that an interoperability layer has emerged.
Why it matters
For a team working with local model derivatives, headless operation changes the shape of the workflow from an operator-led task toward something that can be invoked repeatedly in automation. End-to-end tests are also a useful foundation for checking that a complete run still executes as expected after a tool or environment change. Generic plugins can let teams adapt scoring or modification behavior without waiting for each variation to be built into the core release.
The convenience does not remove the need for review. Editing a refusal profile is a behavioral intervention, not proof that the resulting checkpoint is appropriate for a product, a jurisdiction, or a particular risk boundary. Teams should evaluate the modified model against their own tasks and failure cases, retain the configuration used, and verify any plugin behavior they depend on. Existing users also need to budget for configuration migration. And teams that used Heretic's research features must separately assess Lophius rather than presume the old functions remain available under a new name.
What happens next
- Users with established 1.x workflows will face a migration decision rather than a seamless update. (3 months, 75%). Watch for: revised 2.0-compatible configuration files or migration reports.
- Plugin-based scorers and modifiers will become a focal point for Heretic experimentation. (6 months, 60%). Watch for: additional plugins or reproducible plugin configurations.
Limits and uncertainty
The release notes establish a feature list and a compatibility break, but not performance, reproducibility outcomes, model coverage, or the effect of any plugin on output quality. They do not provide the migration steps themselves or show whether Lophius replaces every removed research workflow. The listed fixes do not demonstrate support for every operating system, model architecture, or chat template. The supplied material states no licensing terms, pricing, hosted access, security safeguards, or distribution controls for modified models. Finally, headless operation enables automation, but it does not itself validate the safety, usefulness, or legality of a changed model.
Skill to build now
If your team maintains a local-model editing workflow, create a small migration test before adopting 2.0. Preserve a 1.x configuration, convert it using the project's migration guidance, then run the same bounded evaluation set through the updated setup. Record the Heretic version, configuration, model, scorer, plugin settings, and resulting metrics. This directly addresses the release's explicit compatibility break and gives reviewers a concrete basis for distinguishing a successful tool migration from an unexamined behavioral change.
Reader takeaway
Heretic 2.0 turns local refusal-editing work into a more automatable and extensible workflow through headless runs and plugins. But it is a breaking transition, not a drop-in update, and it does not establish that altered models are safe or reliable. Migrate configurations deliberately, retain reproducible run details, and evaluate every resulting model for the use case that matters.
Open question
Will Lophius cover the research workflows removed from Heretic closely enough for existing users to migrate without rebuilding their evaluation process?