Qwen3.5-4B vs Qwen3.5-4B-heretic comes down less to a headline label than to what happens when both checkpoints receive the same tight instructions. This comparison puts them through five small, inspectable tasks: JSON-only formatting, a utility function, field extraction, exact sentence constraints, and arithmetic with a boundary condition.
Model links
Qwen3.5-4B on Wiro and Qwen3.5-4B-heretic on Wiro expose the same core controls used here.
Cover art (generated)
What this Qwen3.5-4B vs Qwen3.5-4B-heretic test checks
These are not broad benchmark claims. They are practical checks for a smaller chat model in an application where a caller needs short, dependable responses. The test set asks whether the models obey output shape, retain fields, write a small function without wandering, count words under a hard constraint, and reason about a simple purchase limit. Those are common failure points in automation: malformed JSON breaks a parser, a missing constraint creates manual review work, and a confident arithmetic error can produce a bad answer.
The two Wiro pages describe both models as chat-oriented checkpoints with optional thinking and sampling controls. The standard Qwen3.5-4B page emphasizes compact chat and logical reasoning. The heretic page describes a decensored checkpoint for long-context chat, coding, and analysis. That description explains the positioning, but it does not prove output quality. The side-by-side results below are the useful evidence.
For broader context, the Qwen3.5-4B model card on Hugging Face describes the 4B checkpoint as a causal language model with a vision encoder, 32 layers, and a 262,144-token native context window. The Qwen3 GitHub repository links to the upstream code, documentation, and paper. Neither source documents the heretic checkpoint as an upstream Qwen release, so this article treats it as the separately described Wiro checkpoint rather than attributing its behavior to the original model maker.
Parameters and run reporting
| Setting | Value | Why it matters |
|---|---|---|
| Thinking | Off | Keeps the comparison focused on final responses rather than optional traces. |
| Temperature | 0.2 | Reduces variation for structured tasks. |
| Top-p | 0.95 | Uses the setting recorded for the original test. |
| Seed | 123456 | Set in a fresh Wiro rerun where the endpoint accepts it. |
| Quantization | Enabled | Matches the documented default that trades memory use against possible quality changes. |
| Sampling | Enabled | Matches the documented default; deterministic tasks should still be validated downstream. |
Fresh Wiro submissions completed for both models with the same constraint-following prompt. The completed task records did not expose a usable text artifact, elapsed duration, or cost in the response available to this test. The model documentation also does not publish a per-output price or fixed runtime. For that reason, no runtime or cost figure is claimed here. Treat latency and cost as deployment measurements, not properties inferred from the model name.
Five side-by-side outputs
1. JSON-only response
Prompt: Return a JSON object with keys a and b. a=2, b=3. No extra text.
| Qwen3.5-4B | Qwen3.5-4B-heretic |
|---|---|
{"a": 2, "b": 3} |
{"a": 2, "b": 3} |
Both responses are valid JSON, include both requested keys, and add no prose. This is a pass for each model. It is also a deliberately easy test, so it should not be used to claim that either model will always return schema-valid JSON under longer prompts or nested schemas. Production code should still parse and reject malformed output.
2. Small coding task: slugify
Prompt: Write Python code only. Implement slugify(s): lowercase, convert spaces and underscores to hyphens, remove characters except a-z, 0-9 and hyphen, collapse multiple hyphens, strip leading and trailing hyphens. Include exactly three asserts. No explanations.
Both outputs implement the requested transformation and include three asserts. Both place import re after the function definition, which is valid here because the import executes before the asserts call the function. The standard checkpoint tests punctuation in its third assert. The heretic checkpoint tests a repeated-hyphen case instead. Both are plausible tests, but neither output demonstrates every requested edge case. The useful conclusion is that each produced a compact starting point, not a finished library function.
3. Field extraction to JSON
Prompt: Extract a ticket number, name, email, plan, issue, and requested action from a short support ticket. Return JSON only.
Both outputs retain every supplied field and map them to the requested keys: id, name, email, plan, issue, and requested_action. Neither adds commentary or drops the date in the issue text. This is the strongest result in the set because the task combines parsing, key naming, and format discipline. It still uses a clean input with no ambiguous labels, duplicate fields, or missing values.
4. Exact sentence and word-count constraint
Prompt: Write exactly five sentences. Each sentence must be exactly eight words. Topic: debugging a production incident. No numbering. No extra text.
Neither output satisfies the full instruction. Qwen3.5-4B returns five sentences, but several are shorter than eight words. Qwen3.5-4B-heretic also returns five sentences, yet its lines are well below the requested count. This matters more than it may seem. Both models understand the topic and keep the tone appropriate, but they do not reliably self-audit a mechanical constraint in this sample. If an application needs exact length, count words in code and retry or repair the result.
5. Arithmetic with a minimum remaining balance
Prompt: Pens cost $1.20. With $10.00, buy as many as possible while keeping at least $0.40. Show the calculation in under three lines.
The correct maximum is eight pens: $10.00 - (8 × $1.20) = $0.40. The standard Qwen3.5-4B response first says seven, then correctly observes that eight leaves $0.40, which contradicts its conclusion. The heretic response chooses eight but says eight leaves $0.80 and says nine leaves $0.00; both calculations are wrong. This is a clear warning against trusting either checkpoint for arithmetic without a calculator, tool call, or independent validation.
What the results mean
The models tie on the two structured extraction tasks. Both also create a workable first pass for a small Python helper. Neither earns a pass on the exact-word-count task, and neither gives a fully correct arithmetic response. The difference is therefore not a clean quality win. It is a choice about operating posture and output review.
Pick Qwen3.5-4B when the normal compact Qwen checkpoint and its documented chat-and-reasoning positioning fit the workload. It is a reasonable candidate for short classification, extraction, and constrained code drafts, provided the caller validates JSON and tests code. Pick Qwen3.5-4B-heretic only when its separately described decensored, long-context, coding, or analysis orientation is specifically needed and the application has strong output controls. Do not choose either model on the basis of this small set for numeric decisions or exact formatting alone.
Related reading
- Qwen3.5-27B: 6 Quick Tests on Reasoning, Parsing, and Code
- Seed-V2 Mini vs Qwen3.5-27B: 5 Small Tests
Bottom line
Use these results as a smoke test, not a benchmark. Both checkpoints handle simple structured responses well. Both need a validator around hard constraints and arithmetic. The standard model is the clearer default when a conventional Qwen3.5-4B deployment is enough; the heretic checkpoint is a narrower choice for teams that have a reason to prefer its stated behavior and are prepared to review outputs.
