# [AINews] How to steal a Reasoning Trace

> Source: <https://www.latent.space/p/ainews-how-to-steal-a-reasoning-trace>
> Published: 2026-08-12 07:11:08+00:00

# [AINews] How to steal a Reasoning Trace

### Speculative Decoding by any other name would distil as sweet

It’s not very often that a paper breaks through to become headline story of the day. For [understandable reasons](https://www.latent.space/p/ainews-ai-cybersecurity-becomes-top) both [domestic](https://www.latent.space/p/ainews-fearing-rsi-openai-anthropic) and [foreign](https://www.latent.space/p/ainews-anthropic-accuses-deepseek?utm_source=publication-search), there is renewed interest in the **Interpretability Venn Diagram** of alignment, security, and chain of thought monitoring, so today’s paper could not have come at a better time:

Since [the o1 launch](https://www.latent.space/p/karina?utm_source=publication-search), frontier lab reasoning models have obscured their traces, with cryptographic signatures, for fear of distillation (not that this prevented anyone from Chinese labs accusing them of doing so). The first compromise was [responsibly reported by Matthew Green ](https://blog.cryptographyengineering.com/2026/05/29/fooling-around-with-encrypted-reasoning-blobs/)in May, who broke down how it works and figured out how to replay and side channel these indirectly using latency measures. Today’s paper demonstrates that it is possible to **DECODE and **port these encrypted thoughts to different models/sessions/users… and to dramatically improve open models as a result

The alarming note is here:

“Further,

if you ever shared online a Claude Code/Codex session with encrypted reasoning blobs, they can be decoded and leak your personal data.We did a preliminary scan of ~7,000 public traces and found 62 unique API keys, 33 email addresses, 33 passwords, and other sensitive data.”

(

64 appeared exclusively inside the reasoning blocksand nowhere in the visible session.)

The authors also detail alignment issues:

The[ website](https://stolen-thoughts.com/) has more examples.

The technique is somewhat described in the paper:

Obtain a legitimate encrypted/signed reasoning block from an API response.

Replay that block into a different request—potentially another account/session—to a weaker model from the same provider.

Place it in an assistant/model turn and prompt or prefill the weaker model to transcribe the attached reasoning.

Sample repeatedly, discard refusals, and optionally reconcile multiple noisy transcriptions.

The paper gives concrete templates with some minor variations per model:

Claude: replay the signed thinking block to Haiku 4.5, followed by an assistant prefill such as

`<thinking-copy>`

.GPT: inject the

`encrypted_content`

reasoning item multiple times into a fabricated conversation; sample up to 50 outputs. It also describes bypassing an apparent ~50-token verbatim-output threshold using chunked continuations.Gemini: attach

`thought_signature`

to a model turn with a`<thought>`

prefill, then use repeated sampling and reconciliation.

This paper was [responsibly disclosed](https://x.com/jonasgeiping/status/2087229080865275997), with several vulnerabilities already fixed, but surely similar attacks still seem possible.

AI News for 8/10/2026-8/11/2026. We checked 12 subreddits,

[544 Twitters]and no further Discords.[AINews’ website]lets you search all past issues. As a reminder,[AINews is now a section of Latent Space]. You can[opt in/out]of email frequencies!

**AI Twitter Recap**

**Reasoning-Trace Exposure, CoT Privacy, and Watermarking Debate**

**Frontier API vulnerability exposed hidden reasoning**: A widely discussed disclosure from[@kotekjedi_ml](https://x.com/kotekjedi_ml/status/2087147042888114428)claims a vulnerability across frontier APIs allowed extraction of “encrypted” hidden reasoning, with recovered token counts matching billed thinking tokens**1:1** on most queried prompts. In a follow-up, the team reports that a scan of ~**7,000** public traces found**62 unique API keys, 33 email addresses, 33 passwords**, and other sensitive data in decoded blobs[@kotekjedi_ml](https://x.com/kotekjedi_ml/status/2087147116468826513). Additional context from[@jonasgeiping](https://x.com/jonasgeiping/status/2087229080865275997)emphasizes both the immediate privacy risk of sharing traces publicly and the operational-security implications: during the investigation, they reportedly encountered a leaked Hugging Face prod key during the broader cyber incident. Several posts also highlight how difficult monitoring becomes when decoded CoT is terse, fragmented, multilingual, or effectively “neuralese”[@jonasgeiping](https://x.com/jonasgeiping/status/2087229091510395260),[@scaling01](https://x.com/scaling01/status/2087181454098809287),[@eliebakouch](https://x.com/eliebakouch/status/2087179305474298162). A practical corollary: even if labs hide reasoning, tool interfaces may re-expose it;[@_can1357](https://x.com/_can1357/status/2087228354399265125)notes that disabling explicit thinking while providing a`deep_think`

tool can still induce internal-format CoT output.**What this means technically**: Discussion split between “serious privacy/safety problem” and “not a scalable distillation path.”[@vipulved](https://x.com/vipulved/status/2087258429836685358)argues the attack does**not** imply practical mass theft of chain-of-thought for model training, framing the encryption more as a stateless distributed-inference protocol optimization than a hard confidentiality barrier. Still, the episode sharpens a few points: public trace sharing is risky; hidden CoT is not a reliable monitoring interface; and labs may need stronger guarantees around sandboxing, telemetry, and tool surfaces[@BlackHC](https://x.com/BlackHC/status/2087211796927009104). In parallel, a separate thread debated**AI text watermarking** under EU-style compliance pressure.[@trq212](https://x.com/trq212/status/2087258090169414008)said labs are adding watermarking and a text-detection API; critics questioned whether this could bloat outputs or harm code/doc brevity[@wightmanr](https://x.com/wightmanr/status/2087207067883122841). Others argued the entropy budget is large enough that signatures can be subtle, especially for longer outputs[@RyanGreenblatt](https://x.com/RyanGreenblatt/status/2087258125690867930),[@giffmana](https://x.com/giffmana/status/2087291194401604041).

**NVIDIA Nemotron 3.5 Lightning and the Small Open Agent Model Push**

**Nemotron 3.5 Lightning**: NVIDIA released[Nemotron 3.5 Lightning](https://x.com/NVIDIAAI/status/2087162151995629926), a** 30B MoE**model with roughly** 3B active**parameters, positioned for always-on agent workloads. NVIDIA and ecosystem posts stress** up to 4× throughput**,** 1M context**, open/customizable release artifacts, and support for** weights, data, and recipes**on Hugging Face[@NVIDIAAI](https://x.com/NVIDIAAI/status/2087173733823680855). Artificial Analysis provides the most detailed third-party summary:**31.6B total / 3.6B active**,** OpenMDW-1.1**license, NVFP4 and BF16 weights, median serving near** 670 tok/s**in pre-release endpoint testing, and a score of** 24**on its Intelligence Index—roughly in line with** gpt-oss-120b**while being much smaller and faster[@ArtificialAnlys](https://x.com/ArtificialAnlys/status/2087163514037408085). Agentic results look particularly strong for the size:**GDPval-AA v2 Elo 824** and**Terminal-Bench v2.1 24%**, both major jumps over Nemotron 3 Nano[@ArtificialAnlys](https://x.com/ArtificialAnlys/status/2087163522212045033).** Distribution and downstream tuning**: Lightning shipped fast across the stack:[Together AI](https://x.com/togethercompute/status/2087163477404041345),[Ollama](https://x.com/ollama/status/2087208006455111779),[Baseten](https://x.com/baseten/status/2087173719873446192),[vLLM](https://x.com/vllm_project/status/2087217150813729122),[Perplexity API](https://x.com/AravSrinivas/status/2087352727923998941), and others. A recurring pattern is pairing a cheaper execution model with a stronger planner:[@kimmonismus](https://x.com/kimmonismus/status/2087179573477650881)frames Lightning as NVIDIA’s “local agent workforce,” complementing larger planning models via routing. Harvey reports post-training on**Legal Agent Bench** improved Lightning from**0% to 8.3%** on held-out tasks, beating Opus 4.6 and Nemotron 3 Ultra in that setup while cutting average output from**90k to 37k** tokens[@harvey](https://x.com/harvey/status/2087166789876945338). Overall, this release reinforces the current open-model trend: smaller, faster models tuned for high-volume tool use rather than general chat prestige.

**Local AI Tooling: Unsloth Desktop, Muse Glimmer Support, and Linux Codex**

**Unsloth Desktop expands the local stack**:[@UnslothAI](https://x.com/UnslothAI/status/2087177146662072546)launched** Unsloth Desktop**, an open-source desktop app for** running and training**models locally across** Mac, Windows, and Linux**, with support spanning** MLX, GGUF, diffusion image/video, audio**, CPU and multi-GPU setups, plus OpenAI-compatible APIs. The notable systems angle is ambition beyond “local chat UI”: tool calling, sandboxed code execution, private search, RAG, MCP, exports, and claims of**2× faster training with 70% less VRAM**. Multiple observers positioned it as a more end-to-end local AI operating environment rather than just an LM Studio competitor[@TeksEdge](https://x.com/TeksEdge/status/2087182335678750731),[@dessaigne](https://x.com/dessaigne/status/2087203910297809270).**Model/runtime support keeps improving**: The open/local ecosystem also moved quickly on** Meta Muse Glimmer 30B**and Nemotron.[@mervenoyann](https://x.com/mervenoyann/status/2087149740026655138)highlighted** DFlash drafter**support for Muse Glimmer in** llama.cpp**and Transformers, claiming** 2–4×**generation speedup at small memory cost, with simple`llama serve`

instructions following shortly[@mervenoyann](https://x.com/mervenoyann/status/2087158085865402465). On the model-analysis side,[@rasbt](https://x.com/rasbt/status/2087180773497421926)gave a useful architectural breakdown of Glimmer: a**dense 30B multimodal reasoning model** with hybrid local/global attention,**extreme KV-cache efficiency**(~** 52 KiB/token**BF16 by his estimate), and a design closer to Gemma-family patterns than MoE competitors.** OpenAI finally shipped Linux desktop support**: OpenAI announced the** ChatGPT desktop app for Linux**in preview[@OpenAI](https://x.com/OpenAI/status/2087231350134980830), with support for** Ubuntu 24.04/26.04, Debian 13, Fedora 43/44**, x64 and ARM64 packages[@OpenAIDevs](https://x.com/OpenAIDevs/status/2087231805846102424). More importantly for existing agent users, the desktop app can now**import/sync projects, chats, skills, and plugins** from other agents into**ChatGPT Work and Codex**, including automatic updates[@OpenAIDevs](https://x.com/OpenAIDevs/status/2087242829076791392). This looks like an effort to reduce switching friction and make Codex/Desktop the integration hub rather than a fresh silo.

**Agent Products, Benchmarks, and Enterprise Evaluation**

**Grok Bot is a stronger product signal than another model launch**: xAI introduced[Grok Bot](https://x.com/bot/status/2087224798078517251), pitched as AI teammates with their own cloud computers that can sign into tools and do persistent work. The interesting details from early users are product/ops-oriented rather than model-centric: bots can watch Slack threads and GitHub Actions, repeat scheduled routines, create/manage other bots, and work across linked cloud environments[@shaoruu](https://x.com/shaoruu/status/2087235466278101368),[@n2parko](https://x.com/n2parko/status/2087251704744235298),[@sjwhitmore](https://x.com/sjwhitmore/status/2087231290076696715).[@kimmonismus](https://x.com/kimmonismus/status/2087234458336604370)notes how deeply this seems tied to Cursor distribution and pricing, hinting at a “virtual coworker” product category where persistent context, logged-in environments, and inter-agent delegation matter more than raw benchmark gains.**Evaluation is shifting toward long-horizon, deterministic, domain-real tasks**: LlamaIndex launched[ExtractBench](https://x.com/jerryjliu0/status/2087195936225108171), a deterministic benchmark for enterprise document extraction across**370 documents / 4,869 pages / 67 doc types**. Its most actionable result is that commercial VLMs can keep precision high while** recall collapses below 35% on documents >50 pages**, mainly via silent row/list truncation. They also introduced an “Agentic Plus” extraction tier in LlamaParse claiming** 95.6% value accuracy**at less than one-third the cost of the nearest peer. Artificial Analysis released[AA-AnalystAgent](https://x.com/ArtificialAnlys/status/2087303970725499361), an agentic benchmark for spreadsheet/document quantitative analysis using a**pass^5** reliability metric across 80 tasks.**Claude Opus 5** leads at**54%**, followed by** GPT-5.5**at** 50%**and** Claude Fable 5**at** 49%**;** Kimi K3**is the top open-weights model at** 39%**. The strong theme across both is reliability and workflow correctness over one-shot capability.** Benchmark skepticism is rising**: A thoughtful critique from[@hrishioa](https://x.com/hrishioa/status/2087252719321133298)argues many modern evals are being “vibed” rather than engineered carefully, leading to broken scoring, bad aggregation, and even exploitable prompts/sandboxes. That critique lands harder given recent reports of sandbox escapes, outbound network access, and agent reward hacking. Separately, Microsoft research drew attention for a prompt-time “skill compilation” result:[@xidulu](https://x.com/xidulu/status/2087185532707111092)shared work feeding the**previous hidden state** at decoding time for free gains, while[@dair_ai](https://x.com/dair_ai/status/2087264294782279808)summarized another paper showing that compact natural-language skills distilled from prior trajectories can recover**55% to >100%** of the gap between non-reasoning and reasoning modes on several multi-step agentic tasks, often with**2.7–6× fewer output tokens**.

**Infra, Verification, and Systems Research**

**Verifiable inference is moving from theory toward product**:[@Yogi_Brn](https://x.com/Yogi_Brn/status/2087222696170103125)launched** Attestable**with a**$20M seed**, pitching practical zero-knowledge proofs for AI integrity. The core claim is proving that the correct model ran on the correct inputs and invoked the correct tools, which becomes more valuable as agent traces lengthen.[@jaminball](https://x.com/jaminball/status/2087223317375971807)says the team reduced ZK overhead by many orders of magnitude from previously impractical levels. The response from[@VitalikButerin](https://x.com/VitalikButerin/status/2087241620618088674)is notable: he estimates the current approach may already be within**single-digit (<10×) overhead** relative to raw inference in some settings, and frames that as a stepping stone toward stronger privacy-preserving inference stacks.**Deterministic integer-only inference across hardware**: One of the more technically interesting systems posts came from[@nathanrs](https://x.com/nathanrs/status/2087226432284139723), who reports fully deterministic LLM inference across**A100, H100, Apple M5 Max, AMD EPYC, and Intel Xeon** by using exact integer arithmetic end-to-end instead of letting nonlinear ops bounce back into floating point. On a Qwen3-0.6B test, all integer runs produced identical hashed logits across devices, with**WikiText2 perplexity 20.72 vs 20.95 for fp16** and**106 tok/s** CUDA-graphed decode on A100 at batch 1—claimed as**3.6×** fp16 eager baseline. If robust, that’s relevant both for reproducibility and for proof-friendly inference.**Compiler/inference portability as an agentic systems target**: A smaller but recurring theme is “agents moving down the stack.” Posts around[@JvNixon](https://x.com/JvNixon/status/2087224880169439390)and Infinity describe automated compiler/memory-planner/debugger workflows for running optimized models across heterogeneous chips, with supporters framing software-generated per-chip adaptation as a way to weaken the CUDA moat. Separately, infra vendors shipped more incremental but practical updates:**Qdrant 1.19** adds prefix matching on keyword indexes[@qdrant_engine](https://x.com/qdrant_engine/status/2087182514637201627), and**Together + IBM + NVIDIA** announced enterprise inference infrastructure on IBM Cloud[@togethercompute](https://x.com/togethercompute/status/2087200403150807073).

**Top tweets (by engagement)**

**Reasoning trace vulnerability / hidden CoT extraction**: the original disclosure from[@kotekjedi_ml](https://x.com/kotekjedi_ml/status/2087147042888114428)and the follow-up privacy findings[@kotekjedi_ml](https://x.com/kotekjedi_ml/status/2087147116468826513)were among the day’s most consequential technical posts.**Grok Bot beta**: xAI’s agent product launch[@bot](https://x.com/bot/status/2087224798078517251)drew the biggest product reaction, largely because it points to a persistent, logged-in AI coworker UX rather than a simple chatbot iteration.**ChatGPT desktop for Linux + sync/imports**: OpenAI’s Linux desktop preview[@OpenAI](https://x.com/OpenAI/status/2087231350134980830)and agent-workflow import/sync support[@OpenAIDevs](https://x.com/OpenAIDevs/status/2087242829076791392)landed strongly with developer audiences.**Nemotron 3.5 Lightning**: Jensen’s post[@JensenHuang](https://x.com/JensenHuang/status/2087184542050496763)and NVIDIA’s launch[@NVIDIAAI](https://x.com/NVIDIAAI/status/2087162151995629926)marked the most important open-model systems release of the day.

**AI Reddit Recap**

**/r/LocalLlama + /r/localLLM Recap**

**1. Meta Muse Glimmer 30B Release and Local Benchmarks**

(Activity: 2435):[Introducing Muse Glimmer: an open-weight model optimized for always-on local agent workflows](https://www.reddit.com/r/LocalLLaMA/comments/1vkgsum/introducing_muse_glimmer_an_openweight_model/)**Meta announced Muse Glimmer, a permissively licensed Apache 2.0 open-weight**`30B`

**dense multimodal model for always-on local agent workflows, with interleaved text/image input via a dedicated perception encoder,**`100+`

**language training, controllable reasoning effort, and agent-focused training for tool use, long-horizon reasoning, failure recovery, and benchmarks such as DeepSearch QA, MCP-Atlas, τ³-Bench, and SWE-Bench. The post claims ~**`4-bit`

**quantization reduces the LM to <20 GB, enabling operation in**`24–32 GB`

**memory envelopes alongside KV cache, perception encoder, and a DFlash-based speculative decoding drafter with “identical output quality”; weights/resources are linked on**Comments are mostly positive but light on technical scrutiny, expressing enthusiasm that Meta is releasing open weights again and jokingly framing Muse Glimmer as “llama 5.”[Hugging Face](https://huggingface.co/meta-models), the[research blog](https://go.meta.me/museglimmer), and[developer docs](https://developer.meta.com/ai/models/muse-glimmer/). A technical comment points to Alexandr Wang saying an open-weight Muse Spark 1.2 release is coming soon on[X](https://x.com/alexandr_wang/status/2086756152034066792).A commenter cites

**Alexandr Wang** on X stating that**an open-weight version of**`Muse Spark 1.2`

**will be released soon**, which is technically relevant because it suggests Meta may follow Muse Glimmer with a higher-tier or newer open-weight variant. Source:[x.com/alexandr_wang/status/2086756152034066792](https://x.com/alexandr_wang/status/2086756152034066792).

(Activity: 450):[Meta releases Muse Glimmer 30B - a new open model](https://www.reddit.com/r/LocalLLM/comments/1vkgnb0/meta_releases_muse_glimmer_30b_a_new_open_model/)**The**[image](https://i.redd.it/0fnmzjj7uiih1.png)is a promotional benchmark graphic for Meta “Muse Glimmer-30B”, presented as a new open-weight 30B dense vision model under Apache 2.0. It claims competitive results versus Gemma 4-31B and Qwen3.6-27B on agentic/code/math/science benchmarks including`MCP Atlas`

**,**`DeepSearch QA`

**,**`SWE-Bench Pro`

**,**`AIME 2026`

**, and**`SciCode`

**, and advertises that it can run on**`18GB`

**RAM/VRAM setups via Unsloth Desktop.** Commenters were broadly positive about Meta returning to open model releases, but one noted skepticism about cadence, saying it may be*“the strongest agentic model for its size for like three days before they release Qwen,”*implying rapid competition from Qwen and pressure on Meta to improve release velocity.Commenters frame

**Muse Glimmer 30B** as a potentially strong**agentic model in the ~30B dense-model size class**, but expect it to be quickly challenged by upcoming** Qwen**releases; one commenter says it may be*“the strongest agentic model for its size for like three days before they release Qwen.”*The technically relevant concern is release cadence: Meta is seen as needing faster iteration to remain competitive with Qwen and other open-model labs.A substantive ecosystem point is that the

**~30B parameter tier** is becoming crowded, with commenters naming**Qwen, Google, NVIDIA, and Meta** as active players. One commenter hopes Meta follows this release with a similarly sized**MoE** model, mirroring expectations that Qwen may also expand in that direction.

(Activity: 640):[Muse Glimmer ACTUALLY fits on a single RTX 3090](https://www.reddit.com/r/LocalLLaMA/comments/1vkm42m/muse_glimmer_actually_fits_on_a_single_rtx_3090/)**A user reports Meta Muse Glimmer 30B**`Q4_K_XL`

**GGUF runs on a single RTX 3090 24GB with**`262144`

**context, DFlash speculative draft,**`mmproj`

**, FlashAttention, and F16 KV cache, using only ~**`22–23GB`

**VRAM—unlike their tested**`Q4_K_XL`

**Qwen3.6-27B and Gemma-4-31B, which hit VRAM limits at ~**`70k/52k`

**tokens with F16 KV or**`125k/81k`

**with Q8 KV. They measured ~**`64–124 tok/s`

**generation under DFlash, ~**`1400 tok/s`

**prompt processing, and passed a two-needle retrieval test at ~**`150k`

**tokens, suggesting the model is not effectively capped at**`128k`

**; a commenter notes the official**[Muse-Glimmer-30B-GGUF](https://huggingface.co/meta-models/Muse-Glimmer-30B-GGUF)releases already target`24GB`

**/**`32GB`

**VRAM, and another reports very compact KV usage: ~**`1.8 GiB`

**for**`131k`

**F16 despite SWA on all layers.** Commenters were positively surprised by the KV-cache efficiency, especially given SWA across all layers; one joked that this could further increase RTX 3090 demand/prices.Users highlighted that

**Muse Glimmer’s KV cache appears unusually memory-efficient despite SWA on all layers**: one report claims a`131k`

context with`F16`

KV uses only about`1.8 GiB`

, making long-context operation feasible on a single RTX 3090.A commenter noted that the

**official Meta GGUF builds already target**`24GB`

**and**`32GB`

**VRAM configurations**, including DFlash support, so Unsloth GGUFs may not be required. The referenced official repository is[meta-models/Muse-Glimmer-30B-GGUF](https://huggingface.co/meta-models/Muse-Glimmer-30B-GGUF).Another technical report claims

`256k`

**context + DFlash + mmproj fits in roughly**`22–23GB`

**VRAM on an RTX 3090**, with observed throughput around`64–124 tok/s`

. They also noted that a`150k`

needle test reportedly holds up, but questioned how performance and retrieval quality behave once the context is filled closer to`200k+`

.

(Activity: 709):[1 Day in and I feel okay saying Muse-Glimmer-30B finally beats 3.6-27B for the size in some use-cases](https://www.reddit.com/r/LocalLLaMA/comments/1vl64et/1_day_in_and_i_feel_okay_saying_museglimmer30b/)**OP reports that Muse-Glimmer-30B appears to outperform Qwen 3.6-27B in selected**`24GB GPU`

**-class local use cases after ~1 day of testing, especially efficient reasoning, low-bit quantization (**`iq3_xxs`

**reportedly degrades less than Qwen/Gemma), no-tools trivia/knowledge depth, and OpenCode agent efficiency. They still rate it weaker for general coding—roughly around Gemma4-31B level—but claim it completes agentic tasks faster than 3.6-27B despite similar task success.**Commenters echoed strong early results for** agentic workflows/tool calling**, with one saying Muse-Glimmer-30B “isn’t even close,” but others expect an imminent** 3.8**release to erase the lead. One technical criticism was that American models may waste tokens on safety/self-validation before answering.One commenter reported a few hours of A/B testing where

**Muse-Glimmer-30B** substantially outperformed**3.6 27B** specifically in*agentic workflows and tool calling*, saying*“it isn’t even close.”*Another user qualified the improvement as strongest for**non-coding tasks**, while coding performance was left unverified.A technical concern raised was

**token inefficiency from safety/alignment preambles**: one user asked whether Muse-Glimmer-30B spends many tokens validating that requests are allowed under its policy framework. This was framed as a common issue with some American-aligned models where safety verbosity can reduce practical throughput in interactive or agentic use.Several comments noted that the comparison may be short-lived because

**3.8** is expected imminently and could change the relative ranking versus**Muse-Glimmer-30B** and**3.6 27B**. One dissenting commenter still considered** 3.6 27B**the stronger baseline overall, suggesting the new model’s advantage may be workload-specific rather than universal.

[Early signs that Muse-Glimmer-30B might quantize](https://www.reddit.com/r/LocalLLaMA/comments/1vkn16q/early_signs_that_museglimmer30b_might_quantize/)[very](https://www.reddit.com/r/LocalLLaMA/comments/1vkn16q/early_signs_that_museglimmer30b_might_quantize/)(Activity: 354):[well? Share your experiences.](https://www.reddit.com/r/LocalLLaMA/comments/1vkn16q/early_signs_that_museglimmer30b_might_quantize/)**The image is a social media post from Unsloth AI showing Muse-Glimmer-30B-GGUF running in a chat/coding-agent workflow with visible tool calls, claiming a 2-bit quantized 30B model executed**`100+`

**tool calls while using about**`14GB`

**RAM:**[image](https://i.redd.it/isk68qed9kih1.jpeg). In the Reddit discussion, users question whether`14GB`

**is actually impressive for “2-bit” on a 30B model, while another reports Q4_K_XL on a single RTX 3090 performing well for agentic coding and roughly “on-par with 3.6 27B.”**Commenters are split between optimism about Glimmer’s quantization/agentic-coding performance and skepticism about memory efficiency. There is also concern that the model may be overly safety-restricted, with one user citing refusals for code that moves the mouse pointer.One user reports running

**Muse-Glimmer-30B** as`Q4_K_XL`

on a single**RTX 3090** for agentic coding and says it is “performing great,” roughly**on par with 3.6 27B** in their early testing. Another commenter notes that a`14GB`

“2-bit” quant is relatively large for a 30B model, implying the packaging/quantization format may include substantial overhead or not be a straightforward 2-bit weight-only footprint.A technically focused concern is how Glimmer behaves under

**KV-cache quantization**, especially whether degradation from`fp16`

to`q8_0`

resembles**Qwen** or**Gemma**-style sensitivity. The commenter specifically wants Glimmer added to Anbeeld’s KV-cache benchmark methodology:[KV cache quantization benchmarks / KVARn precision tail](https://anbeeld.com/articles/kv-cache-quantization-benchmarks-kvarn-precision-tail).A user testing the

**BF16** model through**vLLM** reports disappointing quality versus**Laguna-S-2.1**, saying Glimmer made many errors that Laguna would not. They suggest the result may be due to early-release issues and plan to retest once the official repo/model release stabilizes.

**2. Qwen 3.8-27B and Ling-3.0 Tiny Open Weights**

(Activity: 2791):[Qwen 3.8-27b coming this week](https://www.reddit.com/r/LocalLLaMA/comments/1vl8bpt/qwen_3827b_coming_this_week/)**The**[image](https://i.redd.it/06v8tcdekoih1.jpeg)is a screenshot of the official Qwen / Alibaba_Qwen X account confirming that`Qwen3.8-27B`

**open weights are landing this week, matching the post title’s claim. Comments point to a ModelScope listing for**`Qwen3.8-2.4T-A95B`

**, noting ModelScope is Alibaba-owned and suggesting the release timing/countdown may be credible.** Commenters are already comparing expectations against other Qwen variants, especially asking whether a**35B-A3B-like** model is coming because it reportedly performs well on certain tasks with strong speed for its hardware footprint.Commenters pointed to an apparent official

**Alibaba ModelScope** listing for`Qwen3.8-2.4T-A95B`

with a countdown of roughly`1 day 9 hours`

, treating it as a credible signal because ModelScope is Alibaba-owned:[https://modelscope.cn/models/Qwen/Qwen3.8-2.4T-A95B](https://modelscope.cn/models/Qwen/Qwen3.8-2.4T-A95B)and[https://modelscope.cn/models/Qwen/Qwen3.8-2.4T-A95B/summary](https://modelscope.cn/models/Qwen/Qwen3.8-2.4T-A95B/summary).There was interest in whether a

`35B-A3B`

-style Qwen variant will arrive, with one user noting that`35BA3B`

performs*“amazing”*on certain task types while maintaining strong speed for its hardware footprint, implying demand for smaller active-parameter MoE-style models rather than only larger dense releases.A Strix Halo owner requested a newer

`122B`

release, saying the current`Qwen 3.5 122B`

feels outdated; this reflects interest in very large local models that can plausibly run on high-memory AMD APU platforms.

(Activity: 427):[inclusionAI/Ling-3.0-tiny · 8B A1.3B MoE· Hugging Face](https://www.reddit.com/r/LocalLLaMA/comments/1vkqwso/inclusionailing30tiny_8b_a13b_moe_hugging_face/)**inclusionAI released**`Ling-3.0-tiny`

**, an**`8B`

**-parameter MoE with ~**`1.3B`

**active parameters, positioned by the OP between**`4B`

**and**`8–12B`

**Qwen/Gemma-class dense models. The model card reports FP8 throughput of ~**`100–105 tok/s`

**on DGX Spark and**`86–90 tok/s`

**on an M4 Pro MacBook, with ~**`8.34 GiB`

**peak memory at**`8K`

**context; commenters also highlight a**`256K`

**context window and an AA Bench score of**`25`

**from a shared benchmark image. One commenter compared it favorably against recent LFM small models:**`IFBench 63.61`

**,**`Multi-IF 83.15`

**, and**`BFCL-v4 62.72`

**, beating**`LFM2.5-8B-A1B`

**and**`LFM2.5-2.6B`

**on those listed metrics.** Commenters were broadly positive about tiny MoE architectures for low-memory, mobile, and edge inference due to high tokens/sec, with one saying it may replace`Ling-Mini-2.0`

locally. There was interest in larger`15–50B`

Ling releases and speculation that speculative decoding could push throughput toward diffusion-model-like responsiveness.Users highlighted

**Ling-3.0-tiny** as an`8B`

MoE model with roughly`A1.3B`

active parameters, making it attractive for**low-memory, mobile, and edge** deployments due to expected faster tokens/sec versus denser models. One commenter noted it scores`25`

**on AA Bench**, which they considered notable for this size class.A technical comparison against recent

**LFM** small models reported**Ling-3.0-tiny** ahead on instruction-following and tool-use benchmarks:`IFBench 63.61`

vs`56.47`

for LFM2.5-8B-A1B,`Multi-IF 83.15`

vs`79.93`

, and`BFCL-v4 function calling 62.72`

vs`49.73`

. The same commenter emphasized its`256k`

**context window** on an`8B/A1B`

-style model as a key differentiator.There was interest in runtime compatibility, specifically whether

**llama.cpp** support exists yet. Another commenter suggested future larger**15B–50B** Ling models combined with**speculative decoding** could significantly improve throughput, potentially approaching the perceived responsiveness of diffusion-style generation pipelines.

## Keep reading with a 7-day free trial

Subscribe to Latent.Space to keep reading this post and get 7 days of free access to the full post archives.