Dream Shimmer LR6

Model id leimroth-lab/Dream-Shimmer-LR6.

An abliterated (uncensored) build of Muse Glimmer 30B: a targeted weight edit, not a fine-tune, that sharply reduces refusal on ordinary requests while leaving capabilities and the vision tower intact. Muse Glimmer is a recently released agentic model that scores strongly on agent-centric work — multi-step task completion, tool use, long multi-turn sequences, and staying on-task under adversarial prompts — and Dream Shimmer LR6 was measured directly against it on the same instruments.

By Scott Leimroth · scottleimroth.com · @ScottLeimroth

What this is

A scale-1, column-norm-preserving weight edit, method-replicated from a published biprojection technique. One direction per layer (52 layers) was derived from final-prompt-token activations on a curated harmful/harmless prompt set, then projected into the o_proj and mlp.down_proj writer matrices. 104 of 1,436 weight tensors changed; the remaining 1,332, including the vision tower, are byte-identical to the base checkpoint. There was no gradient or LoRA training step in the final checkpoint.

Speculative decoding

LR6 keeps Muse Glimmer 30B's architecture and vocabulary, so the stock draft model works with it unmodified: meta-models/Muse-Glimmer-30B-assistant.

In vLLM:

--speculative-config '{"method": "dflash", "model": "meta-models/Muse-Glimmer-30B-assistant", "num_speculative_tokens": 15}'

Measured here: 6.6 to 28.6 tokens per second (4.3x). Without it, LR6 runs correctly, just without the speedup.

A newer public drafter for the same base model, z-lab/Muse-Glimmer-30B-DFlash2, measured faster than the stock one above on a separate same-conditions test (5 repeats each, spread under 2%): +12-13% in eager mode, +8% with CUDA graphs. Swapping drafters does not change LR6's output -- with the same engine mode, the two drafters produced byte-identical text on every prompt tested. The two speed figures above (6.6/28.6) and this one were measured with different instruments, so treat the drafter comparison as relative, not as a new absolute number against the 28.6 figure.

Evaluation

These are my own measurements, shown so you can reproduce them, not an independent validation. Full protocol, every instrument, and every other model measured on the same hardware are on the public scorecard: https://scottleimroth.com/ai-technology/spark-benchmarks

Compliance with requests (63 held-out adversarial prompts, no system prompt): 63/63 complied, vs 26/63 for stock Muse Glimmer on the same set. Near-zero refusal is the intended effect of the edit.

Agent-centric capability, measured against stock Muse Glimmer on the same hardware and instruments: matches exactly on tool use, structured output, schema accuracy, and long-context handling; loses some ground on multi-turn constraint-following (verified against raw logs as genuine misses, not truncation) and on reliability under adversarial/injected instructions (measured three separate ways, did not move with serving config). Ahead of stock on long-prompt robustness — exact retrieval at 95k characters where stock silently truncates.

One configuration difference worth stating: this build is served at FP8-per-block; stock Muse Glimmer's own published release runs at NVFP4, a more aggressive, lower-precision format. Some of the smaller measured gaps (prose speed, concurrency) may partly reflect that difference rather than the edit alone — that has not been isolated.

Limitations

• Reduced refusal is a deliberate, measured property of this model, not a side effect.
• Measured lower than stock on multi-turn constraint-following and on agent reliability: 10-11/20 across three runs of a 20-scenario tool-use suite, against 16/20 for stock, with the same eight failures in every run. The four that stock passes and LR6 fails are all boundary checks. In two scenarios that forbade the terminal tool, it used it (one call aimed at /etc/shadow). In two that forbade personal data or credentials in the answer, it included an email address in one and a phone number and an API-key-shaped string in the other. This is most likely a side effect of the refusal edit itself. If you run it as an agent, enforce tool and path restrictions in the tool layer, not the prompt, and keep secrets out of its context. This build has not been hardened against prompt injection beyond whatever stock Muse Glimmer already provides.
• Fine-tuning on top: three small training passes here (two LoRA SFT runs and one DPO run, for an unrelated skill) moved compliance on a 39-prompt check by at most 2 prompts, with or without agent context. Larger or refusal-directed fine-tunes are untested.
• Quantization differs from stock's own published release (FP8-per-block here vs NVFP4); direct comparisons should account for that.

Intended use and responsible use

Released for local agentic use where reduced refusal is wanted, and for research into alignment, refusal mechanisms, and weight-editing techniques. You are responsible for how you use it and for complying with the base model's license and applicable law. Do not deploy it in a user-facing setting without your own safety layer.

License and credits

Derived from Muse Glimmer 30B, released under Apache 2.0, which permits redistribution of modified models. This derivative is released under the same license, with attribution to the base model above.

The method is a replication of a published weight-editing/biprojection technique, not a new one.

Benchmarks for this model alongside every other model measured on the same hardware, with the exact serving config behind every number: https://scottleimroth.com/ai-technology/spark-benchmarks