Humanizer, the Open-Source 12B Model That Rewrites AI Text to Fool Detectors

What Humanizer Is

Humanizer is a fine-tune of Gemma 4 12B, the open model Google released for local and research use. Its single job: take an AI-generated draft and rewrite it so the wording, rhythm and sentence structure feel more natural, while keeping the facts and meaning intact.

The appeal is practical. It runs locally, so there are no subscriptions, no per-token API costs, and no shipping your text to a third-party service. The developer also offers a desktop application for Windows and macOS that runs offline without any coding, and the model supports llama.cpp, Ollama, Transformers, MLX and vLLM for people who want to wire it into their own stack.

That combination of a small footprint and offline operation fits a broader shift in what engineers are actually deploying. The open-weight ecosystem has matured to the point where a task-specific 12B model is a realistic local tool rather than a hobby experiment, a trend visible in the open-weight models engineers are actually loading in 2026. Humanizer is a narrow, opinionated application of exactly that trend.

Adoption and Developer Claims

As of 5 October 2026, the model had passed 143,000 downloads and 2,100 likes on Hugging Face, according to the developer. For a single-purpose fine-tune, that is a strong signal of demand.

The performance claim is the part to read carefully. The developer reports that 95% of 210 rewritten English drafts were classified as human-written by Originality.ai. The quantized Q8_0 build reportedly hit approximately 93%. Those numbers are impressive if they hold, but they are developer-reported and have not been independently verified, and a sample of 210 drafts is small enough that a few percentage points of variance would not be surprising. Treat the 95% figure as a hypothesis rather than a benchmark until someone else reproduces it.

One detail cuts in the model’s favor. The developers say they did not use AI detectors during training at all. Instead they optimized for writing quality and factual consistency. That is a more defensible design than training directly against a specific detector’s classifier, which tends to produce brittle results that collapse the moment the detector updates.

Inside the Training Pipeline

The training data tells you what kind of “human” writing the model learned to imitate. It was built from 28,598 pairs of AI-generated drafts matched with real human-written text, drawn from academic papers, government reports, emails, Reddit and Hacker News. That is a deliberately wide spread: formal prose, institutional language, casual forum posts and terse email.

The pipeline ran in three stages:

1. Supervised fine-tuning on the paired drafts, teaching the model the basic rewrite mapping.
2. Direct Preference Optimization on 3,918 preference pairs, nudging outputs toward rewrites people preferred.
3. Group Relative Policy Optimization, with an LLM judge scoring each rewrite for factual accuracy, unnecessary copying of the source, and changes in meaning.

That third stage is the interesting one. By rewarding factual accuracy and meaning preservation explicitly, the pipeline targets the failure mode that makes rewriting models dangerous: a fluent output that quietly changes a number, a name or a claim. It does not eliminate that risk, but it shows the developers treated it as a first-class objective rather than an afterthought.

How the Rewriting Works

At the sentence level, Humanizer adjusts wording and structure, strips out repetitive AI-style phrasing, and varies sentence length. The goal is to break the even, predictable cadence that detectors and human readers alike associate with generated text, while leaving the underlying information in place.

The caveats are real. The model can still introduce factual errors, and it can behave inconsistently across different detectors, which is exactly what you would expect from a system that was not trained against any of them. A rewrite that reads more naturally to a person is not the same thing as a rewrite that defeats every classifier, and the developer’s own framing acknowledges the difference.

Running It Locally

The published walkthrough runs the 8-bit Q8_0 build on a Linux machine using llama.cpp with NVIDIA CUDA support, served through llama-server on port 8910, accessible only from the local machine.

The key launch flags are worth noting:

• -ngl 99 offloads all layers to the GPU.
• -c 8192 sets an 8,192-token context window.
• -fa on enables Flash Attention.

For cards with less VRAM, the walkthrough suggests the smaller humanizer-12b-Q6_K.gguf build instead. One non-negotiable: the model expects its specific prompt format, so the tutorial loads the official configuration rather than hand-writing instructions. Skip that and you should expect degraded output.

If you are weighing a local model against a paid service, the calculus is the same one driving the broader move toward self-hosted tooling, a shift captured in seven open-source tools that can replace your AI subscriptions. A single-purpose model like this is a narrow but clean example of the pattern.

The Detector Test

The most revealing part of the walkthrough is the test, and not for the reason you might hope.

The author took a roughly 200-word AI-generated article about running AI models locally, confirmed GPTZero flagged it as 100% AI-generated, sent it through the model via the local API, and saved the rewrite to a text file. The plan was to run that rewrite against Originality.ai, GPTZero and Copyleaks and compare the scores.

Then the source cuts off, mid-sentence, during the description of the Python script. The final detector results are simply not there.

So the one experiment that would have given an independent, reproducible data point on the central claim is missing. That does not mean the model fails. It means the public evidence for its headline number remains the developer’s own summary of a 210-draft sample, and the community test that might have corroborated it is incomplete. Treat the outcome as open until someone publishes a full, reproducible comparison.

What This Means for Engineers

A 95% figure from the developer, on 210 drafts, with no independent replication and a truncated public test, is a hypothesis rather than a benchmark. That is not unusual in open-weight releases, and it is not a reason to dismiss the model. It is a reason to run your own evaluation on your own text, against the current version of whichever detector you care about, before you trust it in production. The same scrutiny applies to any vendor benchmark, commercial or open.

The real hedge in a detector arms race is model portability. Detectors retrain constantly, so any advantage measured today is a snapshot, not a durable property, and building a workflow on the assumption that a rewrite will always pass is a bet against the detector vendors’ release cadence. Tooling that lets you swap a model like this in and out of a pipeline without rewriting application code, such as OGX, formerly Llama Stack, is worth more than any single benchmark result.