Qwen3.8-27B-honey 🍯

A LoRA adapter that makes Qwen/Qwen3.8-27B answer in Honey-terse style natively: the same correct answer in substantially fewer output tokens, with no system prompt and no per-call overhead. Style source: Green-PT/honey-for-devs (MIT). Sibling model: GreenPT/Qwen3.5-9B-honey.

Headline (official three-arm bench): −37% total token bill vs base, at equal code correctness (10/10) and 92–96% meaning preservation.

What to expect, by task type

Aggregated across every evaluation run against this adapter (two independent harnesses, greedy and sampled decoding — raw data linked below):

Task type	vs base	Notes
Explanations & QA	−44% to −78%	The big win: base derives at length, honey answers
Code, thinking mode on	−51%	Reasoning phase shortens dramatically; still 10/10 correct
Realistic code work (fix, refactor, extend)	−5% to −12%	Equal pass rates; no runaway generations
Bare snippet prompts, thinking off	+6% to +35%	Known regression, see below

The one regression: on bare "write function X" prompts with thinking off, this base already answers with only a code block, while the adapter writes ~12% tighter code but appends How it works / Examples sections — so those prompts run longer, not shorter (+6.2% on the official bench's code set; up to +35% on deliberately trivial one-liners). A training-data artifact of the style corpus's code examples. If you serve mostly snippet generation, use the base or add a system prompt suppressing explanations; for typical dev-assistant work the adapter is neutral to cheaper on code and much cheaper everywhere else.

Official bench: three ways to get a terse 27B

The GreenPT/honey-bench suite (25 explanation cases + 10 code tasks, thinking off and on) compares the adapter against injecting the full honey SKILL.md as a system prompt. Run 2026-08-28 (GLM-5.2-FP8 meaning juror) and re-run 2026-08-30 (Claude juror); greedy sections reproduced token-for-token, confirming the results.

arm	explanations	code, think off	code, think on	total bill	meaning	code tests
Base Qwen3.8-27B	—	—	—	—	—	10/10
+ honey SKILL.md prompt (~3,700 tok/call)	−71.8%	−52.9%	+6.7%	+719%	25/25	10/10
this LoRA	−43.9%	+6.2%	−51.2%	−37.1%	24/25	10/10

The skill-prompt arm is the terseness ceiling but re-sends its system prompt every call — 8× the total bill. The LoRA gets most of the output saving with zero input overhead.

Note on +719%: that is a raw token count, not a dollar figure. Input tokens are typically priced 4–10× cheaper than output tokens, and a static system prompt is exactly what prompt caching discounts most — so the skill-prompt arm's real cost premium is much smaller than 8× on providers with caching. It still never beats the LoRA, which pays no per-call overhead at all and skips the ~3,700-token prefill latency.

The LoRA's single meaning miss was an arithmetic slip under sampling (60 × 2.5 computed as 375); both arms pass the classic traps (100°C→212°F, bat-and-ball→$0.05).

What terse looks like

"What is the time complexity of binary search on a sorted array of n elements?" — greedy, both correct:

• base (454 tokens): a ### Logical Deduction walkthrough of the algorithm's mechanism, the halving recurrence, and its solution.
• honey (28 tokens): O(log n) — each comparison halves the search space, so at most ⌈log₂ n⌉ comparisons.

Usage

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

ADAPTER = "GreenPT/Qwen3.8-27B-honey"

tok = AutoTokenizer.from_pretrained(ADAPTER)
model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen3.8-27B", torch_dtype=torch.bfloat16, device_map="auto"
)
model = PeftModel.from_pretrained(model, ADAPTER)
# for serving, merge to remove the adapter's per-token overhead:
# model = model.merge_and_unload()

messages = [{"role": "user", "content": "Explain what a race condition is."}]
inputs = tok.apply_chat_template(
    messages, add_generation_prompt=True, enable_thinking=False,
    return_tensors="pt", return_dict=True,
).to(model.device)
out = model.generate(**inputs, max_new_tokens=512)
print(tok.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))

The base repo's generation_config.json already stops on both <|im_end|> (248046) and <|endoftext|> (248044), and this adapter ends every turn cleanly on <|im_end|> — no extra stop-token configuration is needed. If your serving stack takes EOS from config.json instead, set eos_token_id=[248046, 248044] explicitly.

Training

• LoRA r=16, α=32, on all attention, linear-attention, and MLP projections (12 module types, 992 tensors, 467MB).
• 3 epochs on the same ~3.9M-token Honey-style dataset as the 9B sibling.
• Final eval: loss 0.726, mean token accuracy 0.804.

adapter_model.safetensors uses the text-only module tree (model.layers…) so the standard AutoModelForCausalLM + PEFT snippet above works as-is. (The trainer originally saved model.language_model.layers… keys from Qwen3_5ForConditionalGeneration; loading a checkpoint with mismatched keys makes PEFT silently drop every tensor — if you swap loading class or checkpoint, verify the adapter changes the logits.)

Evaluation data

• evals/results.json — 26-prompt greedy paired suite (QA / code / explanations, adapter toggled on one loaded model)
• evals/code_recheck.json — 16 bare snippet prompts × greedy + 2 sampled seeds (the regression, quantified)
• evals/code_realistic.json — 10 realistic code tasks (bugfix / refactor / extend / implement), executed against tests
• GreenPT/honey-bench — official three-arm bench: results_27b_fullskill/, results_27b_fullskill_rerun/, reports

Limitations

• Style transfer only — factual ability is the base model's; terse phrasing can drop hedges and caveats the base would include, and one sampled run produced an arithmetic slip (see bench).
• Bare snippet-style code prompts run longer than base (see the regression note above).
• Eval suites are small (26–45 prompts per harness), text-only, single-turn.
• Not additionally safety-tuned beyond the base model.