[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 both domestic and foreign, 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, 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 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 blocks and nowhere in the visible session.)
The authors also detail alignment issues:
The website 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_contentreasoning 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_signatureto a model turn with a<thought>prefill, then use repeated sampling and reconciliation.
This paper was responsibly disclosed, 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 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. Additional context from @jonasgeiping 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, @scaling01, @eliebakouch. A practical corollary: even if labs hide reasoning, tool interfaces may re-expose it; @_can1357 notes that disabling explicit thinking while providing a
deep_thinktool 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 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. In parallel, a separate thread debated AI text watermarking under EU-style compliance pressure. @trq212 said labs are adding watermarking and a text-detection API; critics questioned whether this could bloat outputs or harm code/doc brevity @wightmanr. Others argued the entropy budget is large enough that signatures can be subtle, especially for longer outputs @RyanGreenblatt, @giffmana.
NVIDIA Nemotron 3.5 Lightning and the Small Open Agent Model Push
Nemotron 3.5 Lightning: NVIDIA released Nemotron 3.5 Lightning, 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. 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. 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.
Distribution and downstream tuning: Lightning shipped fast across the stack: Together AI, Ollama, Baseten, vLLM, Perplexity API, and others. A recurring pattern is pairing a cheaper execution model with a stronger planner: @kimmonismus 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. 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 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, @dessaigne.
Model/runtime support keeps improving: The open/local ecosystem also moved quickly on Meta Muse Glimmer 30B and Nemotron. @mervenoyann highlighted DFlash drafter support for Muse Glimmer in llama.cpp and Transformers, claiming 2–4× generation speedup at small memory cost, with simple
llama serveinstructions following shortly @mervenoyann. On the model-analysis side, @rasbt 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, with support for Ubuntu 24.04/26.04, Debian 13, Fedora 43/44, x64 and ARM64 packages @OpenAIDevs. 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. 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, 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, @n2parko, @sjwhitmore. @kimmonismus 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, 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, 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 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 shared work feeding the previous hidden state at decoding time for free gains, while @dair_ai 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 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 says the team reduced ZK overhead by many orders of magnitude from previously impractical levels. The response from @VitalikButerin 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, 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 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, and Together + IBM + NVIDIA announced enterprise inference infrastructure on IBM Cloud @togethercompute.
Top tweets (by engagement)
Reasoning trace vulnerability / hidden CoT extraction: the original disclosure from @kotekjedi_ml and the follow-up privacy findings @kotekjedi_ml were among the day’s most consequential technical posts.
Grok Bot beta: xAI’s agent product launch @bot 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 and agent-workflow import/sync support @OpenAIDevs landed strongly with developer audiences.
Nemotron 3.5 Lightning: Jensen’s post @JensenHuang and NVIDIA’s launch @NVIDIAAI 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
Introducing Muse Glimmer: an open-weight model optimized for always-on local agent workflows (Activity: 2435): Meta announced Muse Glimmer, a permissively licensed Apache 2.0 open-weight
30Bdense 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-bitquantization reduces the LM to <20 GB, enabling operation in24–32 GBmemory envelopes alongside KV cache, perception encoder, and a DFlash-based speculative decoding drafter with “identical output quality”; weights/resources are linked on Hugging Face, the research blog, and developer docs. A technical comment points to Alexandr Wang saying an open-weight Muse Spark 1.2 release is coming soon on X. 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.”A commenter cites Alexandr Wang on X stating that an open-weight version of
Muse Spark 1.2will 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.
Meta releases Muse Glimmer 30B - a new open model (Activity: 450): The image 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, andSciCode, and advertises that it can run on18GBRAM/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.
Muse Glimmer ACTUALLY fits on a single RTX 3090 (Activity: 640): A user reports Meta Muse Glimmer 30B
Q4_K_XLGGUF runs on a single RTX 3090 24GB with262144context, DFlash speculative draft,mmproj, FlashAttention, and F16 KV cache, using only ~22–23GBVRAM—unlike their testedQ4_K_XLQwen3.6-27B and Gemma-4-31B, which hit VRAM limits at ~70k/52ktokens with F16 KV or125k/81kwith Q8 KV. They measured ~64–124 tok/sgeneration under DFlash, ~1400 tok/sprompt processing, and passed a two-needle retrieval test at ~150ktokens, suggesting the model is not effectively capped at128k; a commenter notes the official Muse-Glimmer-30B-GGUF releases already target24GB/32GBVRAM, and another reports very compact KV usage: ~1.8 GiBfor131kF16 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
131kcontext withF16KV uses only about1.8 GiB, making long-context operation feasible on a single RTX 3090.A commenter noted that the official Meta GGUF builds already target
24GBand32GBVRAM configurations, including DFlash support, so Unsloth GGUFs may not be required. The referenced official repository is meta-models/Muse-Glimmer-30B-GGUF.Another technical report claims
256kcontext + DFlash + mmproj fits in roughly22–23GBVRAM on an RTX 3090, with observed throughput around64–124 tok/s. They also noted that a150kneedle test reportedly holds up, but questioned how performance and retrieval quality behave once the context is filled closer to200k+.
1 Day in and I feel okay saying Muse-Glimmer-30B finally beats 3.6-27B for the size in some use-cases (Activity: 709): 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_xxsreportedly 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 very well? Share your experiences. (Activity: 354): 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 about14GBRAM: image. In the Reddit discussion, users question whether14GBis 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_XLon 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 a14GB“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
fp16toq8_0resembles 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.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
Qwen 3.8-27b coming this week (Activity: 2791): The image is a screenshot of the official Qwen / Alibaba_Qwen X account confirming that
Qwen3.8-27Bopen weights are landing this week, matching the post title’s claim. Comments point to a ModelScope listing forQwen3.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-A95Bwith a countdown of roughly1 day 9 hours, treating it as a credible signal because ModelScope is Alibaba-owned: https://modelscope.cn/models/Qwen/Qwen3.8-2.4T-A95B and 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 that35BA3Bperforms “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
122Brelease, saying the currentQwen 3.5 122Bfeels outdated; this reflects interest in very large local models that can plausibly run on high-memory AMD APU platforms.
inclusionAI/Ling-3.0-tiny · 8B A1.3B MoE· Hugging Face (Activity: 427): inclusionAI released
Ling-3.0-tiny, an8B-parameter MoE with ~1.3Bactive parameters, positioned by the OP between4Band8–12BQwen/Gemma-class dense models. The model card reports FP8 throughput of ~100–105 tok/son DGX Spark and86–90 tok/son an M4 Pro MacBook, with ~8.34 GiBpeak memory at8Kcontext; commenters also highlight a256Kcontext window and an AA Bench score of25from a shared benchmark image. One commenter compared it favorably against recent LFM small models:IFBench 63.61,Multi-IF 83.15, andBFCL-v4 62.72, beatingLFM2.5-8B-A1BandLFM2.5-2.6Bon 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 replaceLing-Mini-2.0locally. There was interest in larger15–50BLing releases and speculation that speculative decoding could push throughput toward diffusion-model-like responsiveness.Users highlighted Ling-3.0-tiny as an
8BMoE model with roughlyA1.3Bactive parameters, making it attractive for low-memory, mobile, and edge deployments due to expected faster tokens/sec versus denser models. One commenter noted it scores25on 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.61vs56.47for LFM2.5-8B-A1B,Multi-IF 83.15vs79.93, andBFCL-v4 function calling 62.72vs49.73. The same commenter emphasized its256kcontext window on an8B/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.