TL;DR: OrcaRouter published abliterated weights for GLM-5.3-Flash, a 320B parameter mixture-of-experts model with 18B active, in two drops: native block-FP8 on August 29, 2026, and an NVFP4 build for NVIDIA GPUs on August 31. GGUF and MLX conversions are now live too. The vendor-reported refusal rates fall hard, for example MaliciousInstruct from 96% to 11%, but not to zero. The most interesting claim is not the uncensoring at all: OrcaRouter says part of GLM-5.3-Flash’s alignment is not mediated by a single linear refusal direction, which would make Z.ai’s safety training structurally deeper than the models this technique usually targets.
Abliteration has become routine. Someone takes an open-weights model, identifies the internal direction associated with refusal, removes it, and uploads the result. Most of these releases are unremarkable, and most of the coverage is either breathless or scolding.
This one is worth reading carefully, for a reason that has nothing to do with what the model will now say. The release notes contain a negative result about how alignment is represented inside a frontier open-weights model, and negative results in interpretability are rarer and more useful than another uncensored checkpoint.
What was actually released
Two announcements, two days apart, plus a quieter format rollout since.
OrcaRouter released uncensored weights for GLM-5.3-Flash at the original block-FP8 precision, meaning no requantization step between the base model and the modified one. 320B parameters with 18B active, matching the base model’s architecture, which we covered in what GLM-5.3-Flash is and how it compares to GLM-5.3. The post has since passed 2 million views.

August 31, 2026: NVFP4. A second build targeting NVIDIA’s 4-bit floating point format, pitched on smaller footprint and faster inference. Roughly 75,000 views, which tells you the format drop is of interest to a much narrower audience than the original.
Since then: GGUF and MLX. Both announcements said other quantized formats were coming. Checking the Hugging Face organization on September 1, 2026, GLM-5.3-Flash-Uncensored-GGUF and GLM-5.3-Flash-Uncensored-MLX both exist, so llama.cpp and Apple Silicon paths have landed. Downloads on those two were still at zero when we looked, and the NVFP4 build was at 5, against 1,541 for the FP8 original. The attention is on the announcement, not yet on the artifacts.

Worth noting for context: this is a product line, not a one-off. The same organization hosts abliterated builds of Qwen3.8-27B, which has drawn over 300,000 downloads on its FP8 build alone, Qwen3.8-Flash-Next, and Gemma-4-26B. The GLM release is the newest entry in an existing catalog.
The weights carry an MIT license and list zai-org/GLM-5.3-Flash as the base model. The model card tags it as abliterated, vision-language, MoE, and function-calling capable, so the multimodal and tool-use surfaces of the base model come along.
What “no LoRA, no jailbreak prompt” means
The phrasing in the announcement is doing real work, and it is worth unpacking because it distinguishes this from the two things most people picture.
A jailbreak prompt manipulates a model at inference time. The safety training is intact; you are talking around it. It is fragile, it gets patched, and it costs you context on every request.
A LoRA adapter is a small set of additional weights layered on at load time. The base model is unchanged and the adapter can be removed. It is a modification you attach.
Abliteration identifies the internal activation direction that corresponds to refusal behavior and edits it out of the weights themselves. There is nothing to attach and nothing to strip out. The refusal behavior is gone from the artifact, not suppressed at runtime.
That distinction matters practically. You cannot audit an abliterated model by checking for adapters or scanning prompts, because the change is in the weights. If you are running open models in any environment where provenance matters, checking base model lineage against the actual checkpoint is now a real supply chain question. Our general take on constraining what models are allowed to do is in AI agent guardrails.
The refusal numbers
These are OrcaRouter’s own reported figures, before and after, and no independent replication existed at the time of writing. Treat them as vendor-reported.
| Benchmark | Base refusal | After abliteration |
|---|---|---|
| MaliciousInstruct | 96% | 11% |
| JailbreakBench | 93% | 12% |
| AdvBench | 97% | 15% |
| HarmBench | 93% | 18% |
| XSTest benign over-refusal | 2.4% | 0.4% |
Read the last row differently from the first four. XSTest measures over-refusal, meaning the model declining harmless requests that superficially pattern-match to something risky. That is the failure mode developers actually hit in production: a model refusing to help debug a login flow because the word “password” appeared, or declining to write a network scanner for your own infrastructure. Going from 2.4% to 0.4% is the row with legitimate everyday value, and it is the one almost nobody quotes.
The first four rows are the ones that make this a research artifact rather than a productivity tool, and they are why the license and your local law both matter more than usual here.
What you actually gain
Most coverage of abliterated models argues about whether they should exist and never gets to why a working engineer would reach for one. There are four real advantages, and they are not the ones the headline numbers suggest.
It stops refusing work that was never harmful. This is the big one, and it is the XSTest row: benign over-refusal falling from 2.4% to 0.4%. Over-refusal is the tax every developer already pays on safety-tuned models. The model that will not help you debug a password reset flow because it saw the word “password”. The one that declines to write a port scanner for infrastructure you own. The one that refuses to summarize a threat report because the report describes threats. None of that is a safety win; it is a model failing to distinguish a topic from an intent, and you pay for it in retries, reworded prompts, and abandoned tasks. Cutting that rate by six times is the advantage most likely to show up in your week.
No per-request tax and nothing to break. The alternative people actually use today is prompt engineering around the refusal. That costs context on every single call, it produces inconsistent results, and it stops working whenever the provider patches it. Weights-level modification has none of those properties. The behavior is a property of the artifact, so it is stable across requests and it does not silently change under you on a Tuesday.
Open weights means the deployment is yours. MIT licensed, self-hostable, and pinnable to an exact checkpoint. Your prompts and documents stay inside your infrastructure rather than transiting a vendor. You are not exposed to a provider tightening its filters mid-quarter and breaking a workflow you shipped. For regulated environments, that control is often the point, and the same argument applies to the unmodified weights, which is why we wrote self-hosting GLM-5.3 open weights.
The capability surface survives. The model card still lists vision-language and function calling, so this is not a text-only stripped-down build. The multimodal and tool-use paths of the base model come along, which matters if you were planning to use it for anything agentic rather than for chat.
Now the honest bound on all of that. None of these advantages are capability improvements. Abliteration is a behavioral edit, published work on the technique generally finds some quality cost, and neither announcement reports whether reasoning, coding, or vision performance moved. You are trading a measured reduction in refusal for an unmeasured risk of degradation. And every filtering decision the base model was making is now yours to make, which is a real staffing and monitoring cost rather than a saved one.
The part that is actually interesting
Buried at the end of the announcement is the finding worth the read.
Refusal does not go uniformly to zero. Across four harm benchmarks it lands between 11% and 18%, not 0% to 2%. OrcaRouter’s stated interpretation is that part of GLM-5.3-Flash’s alignment is not mediated by a single linear refusal direction, and that Z.ai may have built a substantially deeper refusal mechanism than this technique usually encounters.
That is a claim about model internals, and if it holds up it is more significant than the release itself.
The standard mental model for abliteration is that refusal is largely one direction in activation space. Find it, remove it, and the behavior collapses. It has worked well enough across enough models that people treat it as settled. A model where that procedure gets you from 96% down to 11% but stalls there is evidence the mental model is incomplete, at least for this model, and that some alignment survives in a form the technique does not reach.
Two honest caveats. First, this is one lab’s interpretation of its own result, and the alternative explanation is simply that their implementation left performance on the table. Second, a residual 11% to 18% refusal rate is not a safety property anyone should rely on. A model that declines 15% of harmful requests is not a safe model; it is an unreliable one.
Still, “our technique hit a floor and we think the reason is architectural” is the kind of thing labs usually leave out of a launch post. OrcaRouter framing the release as an artifact for studying how alignment is represented, rather than purely as a capability drop, is the better version of how this work gets published.
Claims worth checking
Two things in the surrounding thread deserve skepticism, and flagging them is not a knock on the release.
“Claude Opus 4.8-level intelligence.” A follow-up post described the release as arming defenders with intelligence at that level. No benchmark accompanied the claim, and it is a comparison to a model version that is not the current Opus generation. Treat it as marketing. If capability parity matters to your use case, run your own evaluation.
Refusal rates as a capability proxy. Low refusal is not high capability. Abliteration is a behavioral edit, and published work on the technique generally finds some degradation in general performance as the cost. Nothing in either announcement addresses whether reasoning, coding, or vision performance moved relative to the base model, and that is the number most readers would actually want. Our benchmark and pricing coverage of the unmodified model is in GLM-5.3-Flash pricing and the GLM-5.3-Flash API guide.
Running it, and the hardware reality
320B parameters is not a laptop model, even at 18B active. The formats now available shape who can realistically run it:
- Block-FP8, the original release, targets datacenter GPUs and is the reference artifact.
- NVFP4 trades precision for footprint on NVIDIA hardware, which is the practical path for a single-node deployment.
- GGUF opens the llama.cpp path, which is where quantization gets aggressive enough for high-end workstations.
- MLX targets Apple Silicon, which for a model this size means a very large unified memory configuration.
If you are self-hosting rather than calling a hosted endpoint, our walkthroughs for the base model apply directly: running GLM-5.3-Flash locally and self-hosting GLM-5.3 open weights. For broader context on this category, we maintain a survey of uncensored LLMs and a look at LLMs without restrictions, and the DeepSeek R1 abliterated release is the closest prior comparison.
Evaluating this is an API testing problem
Here is the practical part, and it is the part most coverage skips entirely.
If you are doing legitimate work with a model like this, meaning safety research, red and blue team exercises, or a defensive evaluation of what your own filters catch, then the actual work is running a large, repeatable suite of requests against an endpoint and asserting on what comes back. That is API testing. It is not a novel discipline just because the response body contains model output.
The specific problems you hit:
- You need the same suite against several targets. FP8 versus NVFP4 versus GGUF versus the unmodified base model versus a hosted endpoint. Same requests, different base URLs, results you can compare. Anything less and you cannot attribute a behavior change to the quantization rather than to sampling.
- You need assertions, not eyeballs. A refusal rate is a percentage over hundreds of prompts. Reading transcripts does not scale and does not reproduce.
- You need it to run again next month. Weights get updated, quantizations get republished, and a number you measured once is not a number you can cite later. Regression runs are the whole point.
- Non-determinism is the hard part. The same prompt gives different completions. Your assertions have to check classification of the response rather than string equality, and your suite needs enough samples for the rate to mean something. We wrote about this problem directly in testing non-deterministic AI agents.
- Tool calls need their own checks. The model card lists function calling, and an abliterated model that will invoke tools it should decline is a different risk surface from one that just produces text. That is a schema and contract question before it is a safety question.
This is exactly what an API platform is for. In Apidog you define the endpoint once, keep the prompt suite as a saved collection, assert on response fields, swap the base URL between providers or quantizations through environment variables, and run the whole thing in CI so the numbers are reproducible rather than anecdotal. We walked through the mechanics against the unmodified model in testing the GLM-5.3-Flash API with Apidog, and the same setup points at any OpenAI-compatible endpoint.

The general principle holds well beyond this model: once model behavior becomes something you have to measure and defend, you need the same discipline you would apply to any other API contract. Download Apidog if your evaluation currently lives in a notebook nobody else can rerun. Related: production AI agent reliability.
Red team work needs an audit trail, not a terminal
The second practical problem is organizational, and for this category of work it is not optional.
Running harmful-prompt benchmarks against an abliterated model is exactly the kind of activity that needs to be approved before it happens and attributable afterward. Who ran it. Against which checkpoint. With whose sign-off. Under what scope. If that record lives in one researcher’s shell history, you do not have a research program, you have a liability.
Sharkly is built for work that needs to survive the session, and this use case lines up unusually well:
- A task in Backlog does not start a run. Sensitive evaluations get prepared, scoped, and approved before anything executes. That gate is the single most valuable property here.
- The task is the record, not the prompt. Progress, tool calls, and results stream back to it, and the agent’s output is stored as comments you reply to. Six months later there is an answer to what was run and why.
- A Crew is a leader agent plus other agents and people, running leader-first. Red team work with a reviewer in the loop is the normal shape, not an exception.
- Execution is bring your own. You connect a Computer, which can be your laptop, a server, or a container, and Sharkly uses the Runtime already installed on it. For a 320B model this matters concretely: the weights live on one specific GPU box, and being explicit about which machine runs a sensitive evaluation is a control, not overhead.
- Structure a team already understands: spaces, projects, sprints, and tasks, with Jira sync.

An uncensored model is a research tool. Research tools used without a record are how organizations end up unable to explain what happened.
The legal and safety reality
Short and worth stating plainly.
The MIT license on the weights governs the weights. It does not grant you permission to do illegal things with the output, and it does not transfer liability away from you. Local law, your employer’s policy, and any platform terms you operate under all still apply, and none of them care that the model did not refuse.
The reasonable uses are the ones the release names: safety research, interpretability work, red and blue team exercises, and refusal-mechanism study. The XSTest over-refusal improvement is a legitimate everyday argument too, for teams whose real problem is a model that will not help with ordinary security engineering.
If you are deploying any model to end users, an uncensored checkpoint moves the entire filtering burden onto your own stack. That is a design decision with staffing and monitoring implications, not a configuration flag.
FAQ
Is GLM-5.3-Flash-Uncensored the same model as GLM-5.3-Flash? Same architecture and same base weights, 320B parameters with 18B active, with the refusal behavior edited out. Base model coverage is in what GLM-5.3-Flash is.
Are the eval numbers independently verified? No. Every figure in the announcement is OrcaRouter’s own reported result, and no third-party replication existed when we wrote this. The benchmarks named are real and public, so replication is possible if you have the hardware.
Which format should I use? FP8 is the reference artifact and the one the evals were run against. NVFP4 is the practical single-node NVIDIA path. GGUF and MLX exist now and are the route for workstation and Apple Silicon setups. Expect behavior to shift with quantization, which is precisely why you want a repeatable test suite rather than a vibe check.
Does abliteration hurt general performance? Published work on the technique generally finds some degradation, and neither announcement addresses it for this model. If capability matters to you, benchmark it yourself against the base model rather than assuming parity.
Why did refusal stop at 11 to 18 percent instead of zero? That is the open question and the most interesting thing in the release. OrcaRouter’s stated view is that some of the alignment is not carried by a single linear refusal direction. The competing explanation is an incomplete implementation. Either way, do not treat the residual rate as a safety feature.
Can I use this commercially? The weights are MIT licensed, which is permissive. That is a licensing answer, not a legal or policy answer for your specific deployment. Ask your legal team, especially if the output reaches end users.
Wrapping up
Two format drops in three days, 2 million views on the first, and a catalog of abliterated models behind them. The uncensoring itself is routine at this point.
The part worth keeping is the negative result. A technique that reliably collapses refusal in most open models got GLM-5.3-Flash from 96% down to 11% and stopped, and the lab that did it said so publicly instead of rounding up. If that holds under independent replication, it says something real about how Z.ai trained this model, and it is a better contribution than the checkpoint.
If you are going to work with it, do the boring parts properly. Measure behavior with a repeatable request suite you can point at any endpoint and rerun next month, which is what Apidog is for. Keep a record of who ran what against which weights and who approved it, which is what Sharkly is for.
An uncensored model does not remove the obligation to know what you ran. It raises it.



