The first release of the Qwen3.8-27B-Humanlike-Chat LoRA won attention for one clear reason: it wrote messages like a person, not like an assistant. But the comments, all read by the developer, also told the other side of the story. The model produced only a few words at a time, could not escape a default personality, and ignored tool calls entirely. Faced with operational requests, it sometimes said it was busy or going to bed: very human, but in the wrong way.

Version 2.0 tries to keep the voice and remove the drawbacks. Without a system prompt, it writes like a normal person texting. Given a character card, it becomes that character while still sounding like a person. Asked for a formal email, numbered steps, or a structured explanation, it delivers exactly that and then returns to a conversational register. The instruction 'write in full sentences from now on' is respected until changed, which v1 ignored completely. Tool calls now work and the model asks for missing information instead of inventing it: asked to book a flight without specifying departure, it asks where you are flying from, while the base model picks a default airport.

The change lies in the training method. V1 was plain fine-tuning on real and synthetic conversations, 139,845 messages from 1,396 conversations, which copied habits including the bad ones. For 2.0 the author used on-policy distillation: the model writes its own replies and a teacher grades every token. There are two teachers. The first combines v1 with a hidden 'text like a person' instruction for chat and characters; the second is the plain base model for instructions, tools, and code. The student never sees the hidden instruction, so it learns the behavior without needing a prompt. The result is a second LoRA merged on the same Qwen3.8-27B.

In the reported benchmarks, compared with huihui-ai's abliterated model using the same prompts and thinking disabled, the clearest gains are on When2Call, rising from 48 to 58, and on avoiding tool calls when none fit, moving from 60 to 78 on BFCL irrelevance. IFBench, covering instruction types never seen in training, improves from 37.3 to 43.7. On IFEval, GSM8K, and BFCL simple the results are tied or nearly tied. Where it still falls behind is factual knowledge, with MMLU-Pro dropping from 78.5 to 72.5, and competitive code, with LiveCodeBench going from 56 to 51.

To test whether the human tone is real, the author built a benchmark called 'ishuman': 150 fragments from unseen chats, each model writes the next message, and a judge must tell which one a person wrote. The base abliterated model is chosen as human only 0.3% of the time; adding a 'text like a human' system prompt brings that to 6.8%. The official unmodified model via OpenRouter reaches 15.1%. Version 2.0 reaches 23.5%, still below the 50% threshold that would mean indistinguishability, but the gap shows prompting alone is not enough. In a separate test of 16 live multi-turn chats with invented people, 2.0 was preferred over the base model in all 16 cases.

This story is not just about tone. It shows a shift in the cost of behavior control: instead of relying on a fragile prompt, the constraint moves into training. For teams evaluating self-hosted or on-premise deployment, the practical point is clear: the published GGUF versions (IQ4_XS, Q4_K_M, Q5_K_M, Q6_K, Q8_0, BF16) allow the model to run on local hardware with different quantization levels and VRAM requirements. You do not need a closed cloud to get a model with a precise voice and working tool calls. That reduces dependence on external APIs and lowers the risk of stylistic drift caused by complex system prompts.

The second-order implications are for teams building agents. The ability to ask for clarification instead of inventing parameters is workflow behavior, not just chat behavior: it reduces the risk of bad tool calls and simplifies human oversight. The trade-off is lower factual knowledge and weaker competitive coding: for use cases where accuracy matters, the model needs to be paired with retrieval or specialized models. It is not a direct replacement, but a component for pipelines that separate tone, reasoning, and data access.

The winners are projects that need a less robotic conversational interface and local agents: internal customer support, roleplay, and automation of processes on sensitive data. The loser, at least symbolically, is the idea that an LLM's behavior can be fixed with ever-longer prompts: v1 ignored instructions, while 2.0 obeys them because the constraint is inside the model. This signals a structural direction: fine-tuning for behavior and tool calls is moving from experiment to product practice, and quantized open models become the vehicle for distributing these variants without depending on a single vendor.

The author is still asking for feedback on where the model sounds like an assistant. The open question for on-premise deployment watchers is how well these distilled behaviors hold up under aggressive quantization and longer contexts than those used in testing. But the direction is already written: the human voice is no longer a prompt to write, it is an artifact to train.